Заметки Kubernetes (6) — Список конфигураций POD

задняя часть Kubernetes
Заметки Kubernetes (6) — Список конфигураций POD

Это 9-й день моего участия в Gengwen Challenge.Подробности мероприятия смотрите:Обновить вызов

Список конфигурации шести POD

6.1 pods.metadata Метаданные POD

6.1.1 этикетки

  • labels определяют метки, метки, состоящие из пар ключ-значение
  labels:
    app: myapp
    tier: frontend

6.2 Спецификация pods.spec

6.2.1 nodeName работающий узел

  • При использовании манифеста ресурса для определения модуля используйте nodeName для прямой привязки узла, на котором выполняется объект ресурса, на каком модуле.
apiVersion: v1
kind: Pod
metadata:
  name: pod-deme
  namespace: default
  labels:
    app: myapp
    tier: frontend
spec:
  nodeName: node2                           # 直接指定 POD 运行的节点
  containers:
  - name: myapp
    image: ikubernetes/myapp:v1
    imagePullPolicy: IfNotPresent

6.2.2 Выбор узла nodeSelector

  • При определении модуля с манифестом ресурса используйте поле nodeSelector (селектор метки узла), чтобы определить предпочтение узла.
apiVersion: v1
kind: Pod
metadata:
  name: pod-deme
  namespace: default
  labels:
    app: myapp
    tier: frontend
spec:
  nodeSelector:                            # 在 spec 中定义这个 POD 的节点倾向性
  	disktype: ssd                         # 这个 POD 最终会运行在拥有 disktype 标签且值为 ssd 的 nodes 上
  containers:
  - name: myapp
    image: ikubernetes/myapp:v1
    imagePullPolicy: IfNotPresent
    ports:
  • Запустите модуль из файла, наблюдайте за узлом, на котором работает модуль, и вы обнаружите, что он уже работает на помеченном узле node.
kubectl create -f pod-demo.yaml

kubectl get pods -o wide

NAME       READY   STATUS    RESTARTS   AGE   IP            NODE    NOMINATED NODE   READINESS GATES
pod-demo   1/1     Running   0          21s   10.244.2.29   node3   <none>           <none>

6.2.3 restartPolicy Политика перезапуска POD

Всегда: когда контейнер зависает, он всегда перезапускается.Политика перезапуска k8s в два раза превышает 30 секунд, пока он не будет ждать 300 секунд для перезапуска.

OnFailure: перезапустите его, только если его статус ложный

Никогда: никогда не перезапускать, повесить трубку, если повесили трубку.

一旦某个 POD 被调度到某个节点上，只要这个节点在，那么它就不会被重新调度，只能被重启，除非 POD 被删除才会被重新调度，或者 node 挂了，才会被重新调度，否则只要 node 在，那么 POD 就不会被重新调度，如果 POD 启动失败，那么将不断的重启 POD。

当需要终止 POD ，k8s 发送 kill -15 信号，让容器平滑的终止，等待 30 秒的宽限期，如果没有终止，那么则发送 kill 信号

6.2.4 сетевое пространство узла hostNetwork

Используйте логическое значение, чтобы указать, разрешить ли POD использовать сетевое пространство имен хоста.

6.2.5 Хост PID HostPID PID

Используйте логическое значение, чтобы указать, разрешить ли POD использовать пространство имен PID хоста.

6.2.6 Конфигурация контейнера

kubectl explain pods.spec.containers

Опишите контейнер, работающий в POD. Синтаксис: containers , указывающий, что его значение является массивом. Объект используется в массиве для описания контейнера. Объект может иметь следующие параметры:

  • Доступные параметры
параметр эффект
args
command
env Передать переменные среды в контейнер
envFrom
image
imagePullPolicy
lifecycle
livenessProbe
name
ports
readinessProbe
resources
securityContext
stdin
stdinOnce
terminationMessagePath
terminationMessagePolicy
tty
volumeDevices
volumeMounts
workingDir
  • Пример конфигурации
apiVersion: v1
kind: Pod
metadata:
  name: pod-deme                     # pod 的名称
  namespace: default
  labels:
    app: myapp
    tier: frontend
spec:
  containers:
    - name: myapp                      # 运行的容器名称
      image: ikubernetes/myapp:v1      # 容器的镜像
      imagePullPolicy: IfNotPresent    # 从仓库获取镜像的策略
      ports:                           # 定义容器暴漏的端口
    - name: busybox
      image: busybox:latest
      command:
        - "/bin/sh"
        - "-c"
        - "sleep 10"

6.2.6.1 Политика загрузки imagePullPolicy

  • imagePullPolicy Политика получения изображений, см.:kubectl explain pods.spec.containers 
Always            # 总是从仓库下载
Never             # 从不下载，本地有就用，没有就失败
IfNotPresent      # 如果本地存在就直接使用，如果不存在就下载

Если тег последний, всегда загружайте из репозитория.

6.2.6.2 порты Информация о портах

  • порты определяют, какие контейнеры гарантированно выставляются, см.:kubectl explain pods.spec.containers.ports

Представленный здесь порт предоставляет системе информацию о сетевых подключениях контейнера, но в основном носит информационный характер, отсутствие указания порта здесь не препятствует тому, чтобы контейнер открывал порт, любой в контейнере, прослушивающий адрес 0.0.0.0. Порты доступны из сеть

    ports:                    # 定义两个端口对象一个 http 一个 https
    - name: http              # 定义这个端口的名称，方便别的对象取引用
      containerPort: 80       # 端口号
    - name: https             # 方便引用的名称
      containerPort: 443      # 这个端口号仅仅是起到信息的作用，方便查看和使用名称引用

6.2.6.3 env передает переменные среды

  • Use Pod fields
      env:
        - name: MY_NODE_NAME
          valueFrom:
            fieldRef:
              fieldPath: spec.nodeName
        - name: MY_POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        - name: MY_POD_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        - name: MY_POD_IP
          valueFrom:
            fieldRef:
              fieldPath: status.podIP
        - name: MY_POD_SERVICE_ACCOUNT
          valueFrom:
            fieldRef:
              fieldPath: spec.serviceAccountName
  • Use Container fields
      env:
        - name: MY_CPU_REQUEST
          valueFrom:
            resourceFieldRef:
              containerName: test-container
              resource: requests.cpu
        - name: MY_CPU_LIMIT
          valueFrom:
            resourceFieldRef:
              containerName: test-container
              resource: limits.cpu
        - name: MY_MEM_REQUEST
          valueFrom:
            resourceFieldRef:
              containerName: test-container
              resource: requests.memory
        - name: MY_MEM_LIMIT
          valueFrom:
            resourceFieldRef:
              containerName: test-container
              resource: limits.memory

在容器中获取 POD 的信息

可以使用环境变量
可以使用 downwardAPI
https://kubernetes.io/zh/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/

6.2.6.4 command ENTRYPOINT

  • команда определяет программу, которую запускает контейнер, см.:

Что особенного.IO/docs/tasks/…

Массив точек входа и программа, запускаемая по команде, не будет запускаться в оболочке.Если вы хотите запустить в оболочке, вам нужно заполнить ее самостоятельно.Если эта команда не указана, то будет запущена ENTRYPOINT в образе докера .

Image Entrypoint Image Cmd Container command Container args Command run
[/ep-1] [foo bar] [ep-1 foo bar]
[/ep-1] [foo bar] [/ep-2] [ep-2]
[/ep-1] [foo bar] [zoo boo] [ep-1 zoo boo]
[/ep-1] [foo bar] [/ep-2] [zoo boo] [ep-2 zoo boo]

6.2.6.5 args CMD

  • args передает аргументы команде

Если вы не определяете аргументы и в образе есть инструкции ENTRYPOINT и инструкции CMD, то собственная CMD изображения будет передана в качестве аргумента для ENTRYPOINT. Если аргументы указаны вручную, поля CMD в изображении больше не передаются в качестве аргументов.

Если в args есть ссылка на переменную, вам нужно использовать $(VAR_NAME) для ссылки на переменную. Если вы не хотите делать подстановку команд здесь, вы можете использовать $$(VAR_NAME), экранировать его и использовать внутри контейнер.

env:
- name: MESSAGE
  value: "hello kaliarch"
command: ["/bin/echo"]
args: ["$(MESSAGE)"]

6.2.6.6 Информация аннотаций Annotations

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

apiVersion: v1
kind: Pod
metadata:
  name: pod-deme
  namespace: default
  labels:
    app: myapp
    tier: frontend
  annotations:                                      # 注解关键字
    kaliarch/created-by: "xuel"                     # 添加键值对的资源注解
spec:
  containers:
  - name: myapp
    image: ikubernetes/myapp:v1
    imagePullPolicy: IfNotPresent

6.2.6.7 Жизненный цикл POD

  • общее состояние
Pending：已经创建但是没有适合运行它的节点，已经调度，但是尚未完成
Running：运行状态
Failed： 启动失败
Succeed：成功，这个状态很短
Unkown： 未知的状态，如果 Apiserver 与 kubelet 通信失败则会处于这个状态
  • Создать этап POD

Запрос на создание пользователя отправляется на apiserver, и apiserver сохранит целевое состояние запроса в etcd, а затем apiserver запросит расписание для планирования и обновит результат планирования в состоянии pod в etcd, а затем один раз сохраняется в etcd, и после завершения обновления расписания кублет целевого узла будет знать, что есть новая задача для себя, из изменения статуса etcd, поэтому он получит целевой статус списка ресурсов, желаемый пользователем в на этот раз и запустить POD на текущем узле согласно списку.Если создание прошло успешно или не удалось, результат отправляется обратно на аписервер, который снова сохраняется в etcd.

6.2.6.8 livenessProbe зонд живучести

Подробнее см.: kubectl, объяснение pods.spec.containers.livenessProbe.

  • livenessProbe/readinessProbe — это два жизненных цикла k8s, оба из которых могут определять зонды для определения статуса контейнера и реагировать по-разному.
livenessProbe     # 指示容器是否正在运行。如果存活探测失败，则依据 restartPolicy 策略来进行重启
readinessProbe    # 指示容器是否准备好服务请求。如果就绪探测失败端点控制器将从与 Pod 匹配的所有 Service 的端点中删除该 Pod 的 IP 地址
  • LivenessProbe/readinessProbe Доступные зонды и функции зонда, зонд может определять только один тип, например: HTTPGetAction
exec          # 在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。
tcpSocket     # 对指定端口上的容器的 IP 地址进行 TCP 检查。如果端口打开，则诊断被认为是成功的。
httpGet       # HTTP GET 请求指定端口和路径上的容器。如果响应码大于等于200 且小于 400，则诊断被认为是成功的。

failureThreshold    # 探测几次才判定为探测失败，默认为 3 次。
periodSeconds       # 每次探测周期的间隔时长。
timeoutSeconds      # 每次探测发出后等待结果的超时时间，默认为 1 秒。
initalDelaySeconds  # 在容器启动后延迟多久去进行探测，默认为启动容器后立即探测。
  • При использовании зонда exec экспериментальный результат должен заключаться в том, что POD отображает ERROR через 39 секунд, но не перезапускает POD автоматически.
apiVersion: v1
kind: Pod
metadata:
  name: execlive
  namespace: default
  labels:
    app: myapp
    tier: frontend
spec:
  containers:
    - name: busybox
      image: busybox
      command:
        - "/bin/sh"
        - "-c"
        - "touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 3600"    # 创建一个文件等待 30 秒，这个时间探针应该是成功的，30 秒后则失败
      livenessProbe:                                   # 容器的存活性检测，如果失败则按照 restartPolicy 策略来重启 POD
        exec:                                          # exec 类型探针，进入容器执行一条命令
          command: ["test", "-e" ,"/tmp/healthy"]      # 执行的命令为测试文件存在性
        initialDelaySeconds: 2                         # 容器启动后延迟多久进行探测
        periodSeconds: 3                               # 每次探测周期的间隔时长为 3 秒
        failureThreshold: 3                            # 3 次失败后则判定为容器探测存活性失败
  restartPolicy: Never                                 # 当探测到容器失败是否重启 POD
  • При использовании зонда httpGet экспериментальные результаты должны быть примерно через 40 секунд после сбоя определения живучести, POD перезапускается автоматически, первый перезапуск произойдет немедленно, а затем 2 раза по 30 секунд до 300 секунд.
apiVersion: v1
kind: Pod
metadata:
  name: httpgetlive
  namespace: default
  labels:
    app: myapp
    tier: frontend
spec:
  containers:
    - name: nginx
      image: ikubernetes/myapp:v1
      ports:
        - name: http
          containerPort: 80
        - name: https
          containerPort: 443
      livenessProbe:                   # 容器的存活性检测，如果失败则按照 restartPolicy 策略来重启 POD
        httpGet:                       # httpget 探针
          path: /error.html            # 探测的页面，为了效果这个页面不存在
          port: http                   # 探测的端口，使用名称引用容器的端口
          httpHeaders:                 # httpget 时候设置请求头
            - name: X-Custom-Header
              value: Awesome
        initialDelaySeconds: 15        # 容器启动后延迟多久进行探测
        timeoutSeconds: 1              # 每次探测发出等待结果的时长
  restartPolicy: Always                # 当探测到容器失败是否重启 POD

6.2.6.9 Обнаружение готовности readinessProbe

Например, если в контейнере работает tomcat, а tomcat расширяет пакет war, развертывание может занять много времени.По умолчанию k8s будет помечен как прочитанный при запуске контейнера, а запрос планирования сервис будет получен, но запуск контейнера не означает, что tomcat прошел успешно, он запущен, поэтому для определения готовности требуется readinessProbe, чтобы определить, может ли он получить доступ к сервису.

  • Зонды, доступные в livenessProbe/readinessProbe, в основном такие же, как и функции зонда.Зонд может определять только один тип, например: HTTPGetAction.
livenessProbe     # 指示容器是否正在运行。如果存活探测失败，则依据 restartPolicy 策略来进行重启
readinessProbe    # 指示容器是否准备好服务请求。如果就绪探测失败端点控制器将从与 Pod 匹配的所有 Service 的端点中删除该 Pod 的 IP 地址
  • При использовании зонда httpGet экспериментальные результаты должны быть примерно через 40 секунд после сбоя определения живучести, POD перезапускается автоматически, первый перезапуск произойдет немедленно, а затем 2 раза по 30 секунд до 300 секунд.
apiVersion: v1
kind: Pod
metadata:
  name: httpgetread
  namespace: default
  labels:
    app: myapp
    tier: frontend
spec:
  containers:
    - name: nginx
      image: ikubernetes/myapp:v1
      ports:
        - name: http
          containerPort: 80
        - name: https
          containerPort: 443
      livenessProbe:                   # 容器的存活性检测，如果失败则按照 restartPolicy 策略来重启 POD
        httpGet:                       # httpget 探针
          path: /error.html            # 探测的页面，为了效果这个页面不存在
          port: http                   # 探测的端口，使用名称引用容器的端口
          httpHeaders:                 # httpget 时候设置请求头
            - name: X-Custom-Header
              value: Awesome
        initialDelaySeconds: 15        # 容器启动后延迟多久进行探测
        timeoutSeconds: 1              # 每次探测发出等待结果的时长
  restartPolicy: Always                # 当探测到容器失败是否重启 POD
  • Вручную введите контейнер, удалите index.html, чтобы вызвать обнаружение проверки готовности.
kubectl exec -it httpgetread -- /bin/sh
$ rm -f /usr/share/nginx/html/index.html
  • В результате состояние READY POD стало неготовым, и служба больше не будет планироваться на этом узле.
[root@node1 ~]# kubectl get pods -w
NAME                            READY   STATUS    RESTARTS   AGE
httpgetread                     0/1     Running   0          2m50s
  • Создайте еще один файл внутри контейнера, чтобы вызвать проверку готовности.
kubectl exec -it httpgetread -- /bin/sh
$ echo "hello worlld" >>/usr/share/nginx/html/index.html
  • В результате было запрограммировано состояние READY POD, и служба будет назначена на этот узел в это время.
[root@node1 ~]# kubectl get pods -w
NAME                            READY   STATUS    RESTARTS   AGE
httpgetread                     1/1     Running   0          8m15s

6.2.6.10 крючки жизненного цикла жизненного цикла

См.: kubectl объясните pods.spec.containers.lifecycle.

postStart           # 在容器启动后立即执行的命令，如果这个操作失败了，那么容器会终止，且根据 restartPolicy 来决定是否重启
preStop             # 在容器终止前立即执行的命令
  • Базовое использование postStart/preStop
apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: lifecycle-demo-container
    image: nginx

    lifecycle:
      postStart:
        exec:
          command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]
      preStop:
        exec:
          command: ["/usr/sbin/nginx","-s","quit"]

POD-контроллер

POD, управляемый контроллером, может быть реализован, и количество копий POD может поддерживаться автоматически.Он может реализовать расширение и сжатие POD, но не может реализовать расширенные функции, такие как последовательное обновление.

название эффект
ReplicationController Оказывается, у k8s есть только такой контроллер, и сейчас он близок к тому, чтобы его забросили.
ReplicaSet Он создает определенное количество реплик POD от имени пользователей, а также поддерживает расширение и сжатие.Это называется ReplicationController нового поколения. В основном он состоит из 3 индикаторов: 1. Копия POD, желаемая пользователем, 2. Селектор меток, чтобы определить, управляется ли POD сам по себе, 3. Если копии POD недостаточно, какой шаблон POD используется для создания POD, но обычно мы не используем ReplicaSet напрямую.
Deployment Развертывание реализует функции, управляя ReplicaSet. Помимо поддержки расширения и сжатия ReplicaSet, оно также поддерживает последовательное обновление и откат и т. д. Оно также обеспечивает декларативную конфигурацию, которую мы используем чаще всего каждый день. Он используется для управления приложениями без сохранения состояния.
DaemonSet Он используется для обеспечения того, чтобы на каждом узле в кластере работал только один указанный POD.Если есть новый узел, этот POD будет запущен автоматически, поэтому контроллеру не нужно определять количество запускаемых POD, а нужно только для определения селектора меток и шаблона POD. Таким образом, можно запустить только одну копию POD на узле, выбранном в соответствии с селектором меток.
Job Выполните однократное задание, такое как резервное копирование базы данных, и нормально завершите работу после завершения задания, POD не будет запущен снова, если только задание не завершится аварийно.
CronJob выполнять некоторые периодические задачи
StatefulSet Управляйте POD с отслеживанием состояния, но вам нужно написать свои собственные сценарии для каждого отдельного приложения с отслеживанием состояния, чтобы завершить управление службами с отслеживанием состояния.Чтобы решить проблему, связанную с тем, что StatefulSet неудобно писать управление приложениями с отслеживанием состояния. k8s также предоставляет yum-подобный способ helm, который удобен для пользователей, чтобы установить приложение с отслеживанием состояния из helm market.

разное

Публикуйте свои заметки по адресу:GitHub.com/RedHat Series/Арвин…Добро пожаловать в один клик

Категории