Hybrid Deployment on Kubernetes

Kubernetes supports hybrid deployment of multiple architectures without modifying code. In addition, the Docker registry supports multi-architecture image pulling. You can pull required service images, such as Nginx, Tomcat, and BusyBox, from Docker Hub based on your architecture. For details about the Kubernetes architecture and components, see Architecture.

Figure 1 Hybrid deployment 1

Kubernetes provides the flexible Label+nodeSelector mechanism to support directional scheduling of pods based on specific labels. You can use the architecture-aware labels provided by Kubernetes and the nodeSelector field to implement directional scheduling of an architecture.

Figure 2 Hybrid deployment 2

Scale-out Scenario

In this scenario, Arm servers are added to the current x86 cluster to expand the cluster capacity.

Figure 3 Scale-out scenario

Main features in scale-out scenarios:

• Arm nodes can be added to a cluster.
• Arm images can be provisioned to Arm nodes.
• On an Arm node, containers in the same pod can communicate with each other.
• Containers in different pods on the same Arm node can communicate with each other.
• Containers in different pods on different Arm nodes can communicate with each other.
• On an Arm node, the communication between pods and services is normal.
• On an Arm node, services can be accessed from outside the cluster.
• Containers on Arm nodes can read and write volumes of the HostPath type.
• Containers on Arm nodes can read and write persistent volumes of the Ceph type.

New Deployment Scenario

Create a cluster and select an Arm server as the master node.

Figure 4 New deployment scenario

Main features in new deployment scenarios:

• Arm and x86 nodes can be added to a cluster.
• x86 images can be provisioned to x86 nodes.
• Arm images can be provisioned to Arm nodes.
• On an Arm node, containers in the same pod can communicate with each other.
• Containers in different pods on the same Arm node can communicate with each other.
• Containers in different pods on different Arm nodes can communicate with each other.
• On an Arm node, the communication between pods and services is normal.
• On an Arm node, services can be accessed from outside the cluster.
• Containers on Arm nodes can read and write volumes of the HostPath type.
• Containers on Arm nodes can read and write persistent volumes of the Ceph type.