kubernetes "n" independent pods with identity 1 to n

4/19/2018

Requirement 1 (routes): I need to be able to route to "n" independent Kubernetes deployments. Such as:

  1. http://building-1-building
  2. http://building-2-building
  3. http://building-3-building
  4. ... n ...

Each building is receiving traffic that is independent of the others.

Requirement 2 (independence): If pod for building-2-deployment dies, I would like only building-2-deployment to be restarted and the other n-1 deployments to be not affected.

Requirement 3 (kill then replace): If pod for building-2-deployment is unhealthy, I would like it to be killed then a new one created. Not a replacement created, then the sick is killed.

When I update the image and issue a "kubectl apply -f building.yaml", I would like each deployment to be shut down then a new one started with the new SW. In other words, not create a second then kill the first.

Requirement 4 (yaml): This application is created and updated with a yaml file so that it's repeatable and archivable.

  • kubectl create -f building.yaml
  • kubectl apply -f building.yaml

Partial Solution: The following yaml creates routes (requirement 1), operates each deployment independently (requirement 2), but fails on to kill before starting a replacement (requirement 3).

This partial solution is a little verbose as each deployment is replicated "n" time where only the "n" is changed.

I would appreciate a suggested to solve all 3 requirements.

apiVersion: v1
kind: Service
metadata:
  name:  building-1-service # http://building-1-service
spec:
  ports:
  - port: 80
    targetPort: 80
  type: NodePort 
  selector:
    app: building-1-pod #matches name of pod being created by deployment
---
apiVersion: v1
kind: Service
metadata:
  name:  building-2-service # http://building-2-service
spec:
  ports:
  - port: 80
    targetPort: 80
  type: NodePort 
  selector:
    app: building-2-pod #matches name of pod being created by deployment
---
apiVersion: apps/v1beta2 
kind: Deployment
metadata:
  name: building-1-deployment # name of the deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: building-1-pod # matches name of pod being created
  template:
    metadata:
      labels:
        app: building-1-pod # name of pod, matches name in deployment and route "location /building_1/" in nginx.conf
    spec:
      containers:
      - name: building-container # name of docker container
        image: us.gcr.io//proj-12345/building:2018_03_19_19_45
        resources:
          limits:
            cpu: "1"
          requests:
            cpu: "10m"
        ports:
        - containerPort: 80
---
apiVersion: apps/v1beta2 
kind: Deployment
metadata:
  name: building-2-deployment # name of the deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: building-2-pod # matches name of pod being created
  template:
    metadata:
      labels:
        app: building-2-pod # name of pod, matches name in deployment and route "location /building_2/" in nginx.conf
    spec:
      containers:
      - name: building-container # name of docker container
        image: us.gcr.io//proj-12345/building:2018_03_19_19_45
        resources:
          limits:
            cpu: "1"
          requests:
            cpu: "10m"
        ports:
        - containerPort: 80
-- grabbag
kubernetes

1 Answer

4/19/2018

You are in the luck. This is exactly what StatefulSets are for.

-- Janos Lenart
Source: StackOverflow