Демо-пример контроллера Kubernetes Pod

Контроллер стручка

Концепция контроллера
k8s имеет встроенное множество контроллеров (контроллеров), которые эквивалентны конечному автомату и используются для управления конкретным состоянием и поведением Pod.

Различная классификация жизненного цикла

• Автономный модуль: модуль выходит, этот тип модуля не создается.

• Pod, управляемый контроллером: в течение жизненного цикла контроллера количество копий Pod должно всегда поддерживаться.

Тип контроллера

• ReplicationController 和 ReplicaSet
• Развертывание
• DaemonSet
• StateFulSet
• Работа / ConJob
• Автоматическое масштабирование горизонтального модуля

❤Подробнее см. В предыдущих статьях.
Тип управления подом

Экземпляр контроллера

1. RS и RC связаны с Deployment RC (ReplicationController)

Основная функция заключается в обеспечении того, чтобы количество копий приложения-контейнера всегда оставалось на уровне, определяемом пользователем. То есть, если контейнер выходит из строя ненормально, новый Pod будет автоматически создан для его замены; и если аномально дополнительный контейнер также автоматически перерабатывается

Kubernetes официально рекомендует использовать RS (ReplicaSet) вместо RC (ReplicationController) для развертывания. RS существенно не отличается от RC, но имеет другое название, а RS поддерживает коллективные селекторы.

Просмотреть полную информацию о шаблоне RS: kubectl объяснять rs
vim rs.yaml

apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
  name: frontend
spec: 
  replicas: 3  # 3个副本
  selector: # 选择标签
    matchLabels: # 匹配标签，匹配上就是rs的
      tier: frontend  # keys:values
  template: # 模板，后面是pod属性
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: myapp
        image: hub.atguigu.com/library/myapp:v1
        env: # 注入环境变量
        - name: GET_HOSTS_FROM
          value: dns
        ports:
        - containerPort: 80

kubectl delete pod --all
kubectl create -f rs.yaml
kubectl get pod
kubectl get pod --show-labels
kubectl label pod frontend-2q74g tier = frontend1 --overwrite = True
kubectl get pod --show-labels
найдет четыре Один, четвертый - это предыдущие 3, потому что количество копий rs равно 3, и сопоставление меток может соответствовать только внешнему интерфейсу, потому что их всего два, и необходимо создать новый rvckj, чтобы соответствовать ожидаемому значению 3.

Затем удалите rs и обнаружите, что существует
kubectl, которым не управляет rs. Delete rs --all
kubectl get pod --show-labels

 

2. Связь между RS и развертыванием

Развертывание предоставляет декларативный метод для Pod и ReplicaSet, заменяющий предыдущий ReplicationController, чтобы упростить управление приложениями. Типичные сценарии применения включают:

• Определите развертывание для создания Pod и ReplicaSet
• Прокатное обновление и откат
• Расширение и сжатие приложений
• Приостановить и возобновить развертывание

★ Разверните простое приложение Nginx

1创建 创建
vim deployment.yaml
kubectl apply -f deployment.yaml --record

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: myapp
        image: hub.atguigu.com/library/myapp:v1
        ports:
        - containerPort: 80

kubectl create -f https://kubernetes.io/docs/user-guide/nginx-deployment.yaml --record ## --record параметр может записывать команду, мы можем легко проверить изменения каждой ревизии

Создание развертывания создаст соответствующий rs, который определяется 7bb4cb8f64 и метками.

2. Расширение
kubectl scale deployment nginx-deployment --replicas 10
Расширение и сокращение без сохранения состояния

3. Если кластер поддерживает горизонтальное автомасштабирование подов, вы также можете установить автоматическое расширение
kubectl autoscale deployment nginx-deployment --min = 10 – max = 15 – cpu-percent = 80 для Deployment

4. Обновить образ также относительно просто:
kubectl set image deployment / nginx-deployment myapp (имя контейнера) =
wangyanglinux / myapp: v2
. Модификация образа kubectl get rs вызовет создание rs, как упоминалось ранее. Операции обновления и отката будут выполняться в альтернативном процессе модуля.

5. Откат
развертывания kubectl. Отменить развертывание /
обновление nginx-deployment и операции отката будут в альтернативном процессе модуля.

3. Развертывание обновлений

Стратегия обновления развертывания

• Развертывание может гарантировать, что во время обновления будет отключено только определенное количество модулей. По умолчанию он гарантирует, что хотя бы на один модуль меньше ожидаемого (не более одного недоступно).
• Развертывание также может гарантировать, что будет создано только определенное количество модулей, превышающее ожидаемое количество. По умолчанию он гарантирует, что количество модулей будет не больше, чем на один модуль больше ожидаемого (не более 1 всплеска).
• В будущей версии Kuberentes он изменится с 1-1 до 25% -25%.

развертывание kubectl descirbe

Ролловер (несколько параллельных развертываний)

Предположим, вы создаете развертывание с 5 репликами nginx: 1.7.9, но когда созданы только 3 реплики nginx: 1.7.9, вы начинаете обновлять развертывание с 5 репликами nginx: 1.9.1. В этом случае развертывание немедленно уничтожит 3 созданных модуля nginx: 1.7.9 и начнет создавать модули nginx: 1.9.1 . Он не будет ждать, пока будут созданы все 5 модулей nginx: 1.7.9, прежде чем начинать изменять курс.

回 退 Развертывание

kubectl set image deployment/nginx-deployment nginx=nginx:1.91

查看当前的回滚状态：kubectl rollout status deployments nginx-deployment

查看历史版本：kubectl rollout history deployment/nginx-deployment

如果创建的时候加了record，那么CHANGE-CAUSE才会记录

kubectl rollout undo deployment/nginx-deployment

可以使用 --revision参数指定某个历史版本：kubectl rollout undo deployment/nginx-deployment --to-revision=2

暂停 deployment 的更新：kubectl rollout pause deployment/nginx-deployment   

Вы можете использовать команду kubectl rollout status, чтобы проверить, завершено ли развертывание. Если развертывание успешно завершено, kubectl rolloutstatus вернет код выхода 0.

kubectl rollout status deployments nginx-deployment
echo $?

Политика очистки

Вы можете установить элемент .spec.revisonHistoryLimit, чтобы указать максимальное количество записей истории изменений, которые хранятся при развертывании. По умолчанию все версии будут сохранены; если для этого элемента установлено значение 0, развертывание не позволит откат

 

4 、 DaemonSet

daemonset.yaml

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: daemonset-example  # 对应1 与对应2 要一致
  labels:
    app: daemonset
spec:
  selector:
    matchLabels:
      name: daemonset-example  # 对应2  pod
  template:
    metadata:
      labels:
        name: daemonset-example
    spec:
      containers:
      - name: daemonset-example
        image: wangyanglinux/myapp:v1
        # 模板可以复杂点，init C,start stop,readiness等

kubectl create -f daemonset.yaml
kubectl get pod -o wide
главный узел не будет создан по умолчанию

kubectl удалить pod daemonset-example-t5fzc

 

5. Работа и CronJob

vim job.yaml

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    metadata:
      name: pi
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]  # 圆周率计算小数点
      restartPolicy: Never

kubectl create -f job.yaml
kubectl describe pod pi-9vt9h Просмотр статуса выполнения

kubectl get job # взгляд на текущую задачу

Проверить результат, получить 2000 цифр Пи, исправить

 

6 、 CronJob

Развертывание управляет модулем путем создания rs, в то время как
CronJob управляет путем создания модуля для управления заданиями на основе времени, а именно:

• Выполнить только один раз в определенный момент времени
• Запускать периодически в определенный момент времени
• Предпосылки для использования: используемый в данный момент кластер Kubernetes, версия> = 1.8 (для CronJob). Для предыдущей версии кластера, версии <1.8, при запуске сервера API передайте параметр -runtime-config = batch / v2alpha1 = true, чтобы включить пакет / v2alpha1API

Типичное использование выглядит следующим образом:

• Запланировать запуск задания в определенный момент времени
• Создайте задание, которое периодически запускается, например: резервное копирование базы данных, отправка электронной почты

vim cronjob.yaml

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"  # 调度的时间
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            args:
            - /bin/sh
            - -c
            - date;echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure

kubectl apply -f cronjob.yaml
kubectl get cronjob
kubectl get jobs,
а затем проверьте журнал на предмет проверки.

[root@k8s-master01 ~]# vim cronjob.yaml
[root@k8s-master01 ~]# kubectl apply -f cronjob.yaml 
cronjob.batch/hello created
[root@k8s-master01 ~]# kubectl get cronjob
NAME    SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
hello   */1 * * * *   False     0        <none>          15s
[root@k8s-master01 ~]# kubectl get job
NAME               COMPLETIONS   DURATION   AGE
hello-1601467260   1/1           9s         90s
hello-1601467320   1/1           10s        30s
[root@k8s-master01 ~]# kubectl get pod
NAME                     READY   STATUS      RESTARTS   AGE
hello-1601467260-466fs   0/1     Completed   0          108s
hello-1601467320-c5b5b   0/1     Completed   0          48s
[root@k8s-master01 ~]# kubectl log hello-1601467260-466fs
log is DEPRECATED and will be removed in a future version. Use logs instead.
Wed Sep 30 12:01:13 UTC 2020
Hello from the Kubernetes cluster
[root@k8s-master01 ~]# kubectl log hello-1601467320-c5b5b
log is DEPRECATED and will be removed in a future version. Use logs instead.
Wed Sep 30 12:02:14 UTC 2020
[root@k8s-master01 ~]# kubectl delete cronjob --all
cronjob.batch "hello" deleted

Некоторые ограничения самого CrondJob: операция создания задания должна быть идемпотентной.
Успех CrondJob нелегко судить, он будет отвечать только за создание задания, но об успехе задания можно судить.

StateFullSet и HPA, временных знаний недостаточно для поддержки, увидимся позже