controller

Controllers follow a common choreography pattern in k8s projects: control loops

Follow the following pseudocode:

for {
  Actual state := Get objects in the cluster X Actual state of( Actual State)
  Expected state := Get objects in the cluster X Expected state of( Desired State)
  if Actual state == Expected state{
    Don't do anything?
  } else {
    Execute the orchestration action to adjust the actual state to the desired state
  }
}

Actual status: it can be actively collected through heartbeat reporting, monitoring system and controller

Expected status: half from YAML files submitted by users

[the external chain picture transfer fails, and the source station may have an anti-theft chain mechanism. It is recommended to save the picture and upload it directly (img-mizigh8b-164640247545) (D: \ application \ study \ program \ Zheng zetao's learning records \ in-depth analysis k8s \ Chapter 5 \ pic .png)]

Deployment

apiVersion: apps/v1 # Version number
kind: Deployment # type       
metadata: # metadata
  name: # rs name 
  namespace: # Namespace 
  labels: #label
    controller: deploy
spec: # Detailed description
  replicas: 3 # Number of copies
  revisionHistoryLimit: 3 # Keep historical version
  paused: false # Pause deployment. The default is false
  progressDeadlineSeconds: 600 # Deployment timeout (s), the default is 600
  strategy: # strategy
    type: RollingUpdate # Rolling update strategy
    rollingUpdate: # Rolling update
      maxSurge: 30% # The maximum number of copies that can exist, either as a percentage or as an integer
      maxUnavailable: 30% # The maximum value of the Pod in the maximum unavailable state, which can be either a percentage or an integer
  selector: # Selector, which specifies which pod s the controller manages
    matchLabels:      # Labels matching rule
      app: nginx-pod
    matchExpressions: # Expressions matching rule
      - {key: app, operator: In, values: [nginx-pod]}
  template: # Template. When the number of copies is insufficient, a pod copy will be created according to the following template
    metadata:
      labels:
        app: nginx-pod
    spec:
      containers:
      - name: nginx
        image: nginx:1.17.1
        ports:
        - containerPort: 80

ReplicaSet

The actual operation object of the Deployment controller is replicaset, which controls Pod (kubectl get rs)

Deployment controls ReplicaSet (version), while ReplicaSet controls Pod (number of replicas)

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: nginx-set
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9

Analyze the following Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

kubectl scale

Horizontal expansion and contraction can be realized through kubectl scale

kubectl scale deployment nginx-deployment --replicas=4
deployment.apps/nginx-deployment scaled

View the status information after nginx deployment is created

​ NAME READY UP-TO-DATE AVAILABLE AGE

nginx-deployment 4/4 4 4 81s

1. Specified: the number of Pod copies expected by the user (the value of spec.replicas);
2. CURRENT: the number of pods currently in Running status;
3. UP-TO-DATE: the number of pods currently in the latest version. The so-called latest version refers to that the Spec part of the Pod is completely consistent with that defined in the Pod template in the Deployment;
4. AVAILABLE: the number of currently AVAILABLE pods, that is, the number of pods in Running status, the latest version and Ready status.

kubectl rollout status

kubectl rollout status can view the status changes of the Deployment object in real time

kubectl edit

If the Pod template in the Deployment is modified, the rolling update will be triggered.

Modified by kubectl edit

kubectl edit deployment nginx-deployment

The Deployment controller actually controls the number of replicasets and the properties of each ReplicaSet

kubectl rollout undo

Roll back the Deployment to the previous version

Kubectl rollback undo deployment / nginx deployment -- to revision = 2 / / return to the specified version

kubectl rollout history

View the version corresponding to each Deployment change

Kubectl rollout history deployment / nginx deployment -- revision = 2 / / View Details

The Kubernetes project also provides an instruction that enables us to update the Deployment multiple times, and finally only generate a ReplicaSet

kubectl rollout pause

Put the Deployment into the "suspended" state. All modifications to the Deployment will not trigger a new "rolling update" or create a new ReplicaSet

After modifying the Deployment, you only need to execute another kubectl rollback resume instruction to "recover" the Deployment

spec.revisionHistoryLimit

In the "pause" state, all modifications to the Deployment will not trigger a new "rolling update" or create a new ReplicaSet

After modifying the Deployment, you only need to execute another kubectl rollback resume instruction to "recover" the Deployment

spec.revisionHistoryLimit

The Deployment object has a field called spec.revisionHistoryLimit, which is the number of "historical versions" reserved by Kubernetes for Deployment. If it is set to 0, the rollback operation cannot be performed.