Azure Kubernetes - 每个节点仅实施一个部署？

Question

I'm currently creating a Kubernetes cluster in Azure Kubernetes for a production environment. In my cluster, I will have 2 nodes in the node pool - pool1.

Now, I want to deploy 2 applications however both the application will use the container port 5000 and I will not be able to change the ports due to some reasons.

For simplicity, I kept the same manifest for both deployments except the name of the deployment

Deployment manifest - 1:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment-1
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.16.1
        ports:
        - containerPort: 5000

Deployment manifest - 2:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment-2
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.16.1
        ports:
        - containerPort: 5000

As both the deployments uses the same containerPort, the 2nd deployment fails as it is deployed on the same node where 1st app is deployed.

I want to enforce a policy where only one deployment (but not restricting other pods like proxy, sidecar) is allowed per node in Azure Kubernetes.

At the end, deployment-1 should go to node-x and deployment-2 goes to node-y, please suggest.

Answer 1

What you could use in your case is the nodeSelector :

nodeSelector is the simplest recommended form of node selection constraint. nodeSelector is a field of PodSpec . It specifies a map of key-value pairs. For the pod to be eligible to run on a node, the node must have each of the indicated key-value pairs as labels (it can have additional labels as well). The most common usage is one key-value pair.

nodeSelector is one of the forms of node selection constraint. nodeSelector is a field of PodSpec. This is a simple Pod scheduling feature that allows scheduling a Pod onto a node whose labels match the nodeSelector labels specified by the user.

There are also Affinity and anti-affinity as well as Inter-pod affinity and anti-affinity that you could consider using. Notice the More Practical Use-cases as it should fit your requirements:

Interpod Affinity and AntiAffinity can be even more useful when they are used with higher level collections such as ReplicaSets, StatefulSets, Deployments , etc. One can easily configure that a set of workloads should be co-located in the same defined topology, eg., the same node.

You can find more details and examples in the linked documentation.