Оглавление
3. Пауза — базовый контейнер в Pod.
4. Почему Kubernetes проектирует Pod таким образом?
2. Поды, управляемые контроллером
6. Классификация Pod-контейнеров
2. Инициализировать контейнеры (initcontainers)
3. Контейнер приложений (Maincontainer)
7. Политика получения изображений (imagePullPolicy)
1. Введение в Pod
Pod — это самый маленький компонент управления ресурсами в Kubernetes. Pod также является объектом ресурса, который сводит к минимуму запуск контейнерных приложений. Под представляет собой процесс, работающий в кластере. Большинство других компонентов в kubernetes вращаются вокруг модулей Pod для поддержки и расширения функций Pod. Например, объекты контроллера, такие как StatefulSet и Deployment, используются для управления запуском Pod, объекты Service и Ingress используются для предоставления приложений Pod и предоставления услуг для Pod. хранимый PersistentVolume хранит объекты ресурсов и т. д.
2. Как использовать Под
- Контейнер работает в Pod. Модель «один контейнер в каждом поде» является наиболее распространенным применением; в этом случае вы можете думать о поде как о инкапсуляции одного контейнера, и kuberentes управляет подом вместо непосредственного управления контейнером.
- Запускайте несколько контейнеров одновременно в модуле. Под также может инкапсулировать несколько контейнеров, которые должны быть тесно связаны и взаимодействовать друг с другом, а также совместно использовать ресурсы между ними. Эти контейнеры в одном модуле могут взаимодействовать друг с другом, образуя сервисную единицу, например, один контейнер совместно использует файлы, а другой «дополнительный» контейнер обновляет эти файлы. Pod управляет ресурсами хранения этих контейнеров как единого целого.
Контейнеры пода должны работать на одном узле. Современная технология контейнеров рекомендует, чтобы контейнер запускал только один процесс.Номер процесса в пространстве имен PID контейнера равен 1, что позволяет напрямую получать и обрабатывать сигналы.Когда процесс завершается, жизненный цикл контейнера заканчивается.
Если вы хотите запустить несколько процессов в контейнере, вам нужен процесс управления и контроля, аналогичный процессу инициализации операционной системы Linux, чтобы завершить управление жизненным циклом нескольких процессов в древовидной структуре. Процессы, работающие в соответствующих контейнерах, не могут напрямую осуществлять сетевое взаимодействие. Это связано с механизмом изоляции между контейнерами. Абстракция ресурсов Pod в k8s решает эту проблему. Объект Pod представляет собой набор контейнеров, которые совместно используют пространство имен NET, MNT, UTS и IPC. , поэтому имеют одинаковое доменное имя, имя хоста и сетевой интерфейс и могут взаимодействовать напрямую через IPC.
3. Пауза — базовый контейнер в Pod.
Базовая базовая пауза контейнера в ресурсах Pod обеспечивает сетевое пространство имен и другие механизмы совместного использования для каждого контейнера. Пауза базового контейнера (также называемая родительским контейнером) предназначена для управления операциями совместного использования между контейнерами Pod. Этот родительский контейнер должен иметь возможность точно знать, как Создавать контейнеры, которые совместно используют операционную среду, и управлять жизненным циклом этих контейнеров.
Чтобы реализовать идею этого родительского контейнера, в kubernetes контейнер паузы используется как родительский контейнер всех контейнеров в поде. Этот контейнер паузы имеет две основные функции:
- Во-первых, он обеспечивает основу для всего пространства имен Linux Pod.
- Второй — включить пространство имен PID, которое действует как процесс с PID, равным 1 (процесс инициализации), в каждом модуле и перезапускает процессы-зомби.
Контейнер паузы позволяет всем контейнерам в поде совместно использовать два ресурса :
- Сеть: каждому поду будет присвоен уникальный IP-адрес. Все контейнеры в Pod совместно используют сетевое пространство, включая IP-адреса и порты. Контейнеры внутри пода могут взаимодействовать друг с другом, используя localhost. Когда контейнер в модуле взаимодействует с внешним миром, он должен выделить общие сетевые ресурсы (например, используя сопоставление портов хоста).
- Хранилище: модуль может указать несколько общих томов. Все контейнеры в модуле имеют доступ к общему тому. Том также можно использовать для сохранения ресурсов хранилища в модулях, чтобы предотвратить потерю файлов после перезапуска контейнера.
Каждый модуль имеет специальный контейнер Pause, называемый «базовым контейнером». Образ, соответствующий контейнеру Pause, является частью платформы Kubernetes. Помимо контейнера Pause каждый под также содержит один или несколько тесно связанных контейнеров пользовательских приложений.
Контейнер паузы в Kubernetes в основном предоставляет следующие функции для каждого контейнера :
- Служить основой для совместного использования пространств имен Linux (например, пространств сетевых команд) в модулях;
- Включите пространство имен PID и запустите процесс инициализации.
4. Почему Kubernetes проектирует Pod таким образом?
- Причина 1. Когда группа контейнеров рассматривается как единое целое, трудно просто судить и эффективно действовать в отношении всего контейнера. Например, если контейнер умирает, считается ли весь контейнер неисправным? Затем введите в качестве базового контейнера пода контейнер Pause, который не имеет никакого отношения к бизнесу, и его статус представляет собой статус всей группы контейнеров, так что эту проблему можно решить.
- Причина вторая: несколько контейнеров приложений в модуле используют общий IP-адрес контейнера Pause и том, смонтированный контейнером Pause. Это упрощает проблему связи между контейнерами приложений, а также решает проблему совместного использования файлов между контейнерами.
5. Классификация капсул
1. Автономный модуль
Этот тип пода сам по себе не может самовосстанавливаться.Когда под создается (независимо от того, создан ли он непосредственно вами или другим контроллером), Kuberentes планирует его размещение на узле кластера. Под будет оставаться на этом узле до тех пор, пока процесс пода не завершится, не будет удален, не будет выселен из-за нехватки ресурсов или пока узел не выйдет из строя. Капсулы не исцеляются сами по себе. Если узел, на котором запущен под, выйдет из строя или произойдет сбой самого планировщика, под будет удален. Аналогичным образом, если узлу, на котором расположен модуль, не хватает ресурсов или модуль находится в состоянии обслуживания, модуль также будет удален.
2. Поды, управляемые контроллером
Kubernetes использует уровень абстракции более высокого уровня, называемый Controller, для управления экземплярами Pod. Контроллер может создавать и управлять несколькими модулями, обеспечивая управление копированием, последовательные обновления и возможности самовосстановления на уровне кластера. Например, в случае сбоя узла контроллер может автоматически запланировать поды на узле для других исправных узлов. Хотя поды можно использовать напрямую, для управления подами в Kubernetes обычно используются контроллеры.
3. Статический модуль
Статические поды управляются непосредственно процессом kubelet на определенном узле, а не через API-сервер на главном узле. Его нельзя связать с контроллером Deployment или DaemonSet. Он контролируется самим процессом kubelet. При сбое модуля он перезапускается, и kubelet не может выполнить проверку его работоспособности. Статические поды всегда привязаны к определенному кубелету и всегда выполняются на одном и том же узле. Kubelet автоматически создаст зеркальный под (Mirror Pod) для каждого статического пода на апи-сервере Kubernetes, поэтому мы можем запросить под в апи-сервере, но им нельзя управлять через апи-сервер (например, его нельзя удалить).
#查看kubelet配置文件 /var/lib/kubelet/config.yaml
cat /var/lib/kubelet/config.yaml | grep staticPodPath
staticPodPath: /etc/kubernetes/manifests
#也可以通过下面命令找到kubelet对应的启动配置文件，修改node节点的kubelet配置文件，添加静态Pod的环境变量配置 --pod-manifest-path 参数
systemctl status kubelet
/usr/lib/systemd/system/kubelet.service.d
└─10-kubeadm.conf
vim /usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf
Environment="KUBELET_SYSTEM_PODS_ARGS=--pod-manifest-path=/etc/kubernetes/manifests --allowprivileged=true"
systemctl daemon-reload
systemctl restart kubelet
#在静态Pod文件的管理目录下准备 Pod 的 Json 或者 Yaml 文件
vim /etc/kubernetes/manifests/static-web.yaml
apiVersion: v1
kind: Pod
metadata:
name: static-web
labels:
app: static
spec:
containers:
- name: web
image: nginx
ports:
- name: web
containerPort: 80
运行中的 kubelet 周期扫描配置的目录下文件的变化，当这个目录中有文件出现或消失时创建或删除 pods。
在 Master 节点同样也可以看到该 Pod，如果执行 kubectl delete pod static-web-node01 命令删除该 Pod 发现，并不能删除。6. Классификация Pod-контейнеров
1. инфраструктурный контейнер
- Поддерживать всю сеть Pod и место для хранения данных
- операция узла в узле
- При запуске пода k8s автоматически запускает базовый контейнер.
cat /opt/kubernetes/cfg/kubelet
......
--pod-infra-container-image=registry.cn-hangzhou.aliyuncs.com/google-containers/pause-amd64:3.0"
#每次创建 Pod 时候就会创建，运行的每一个Pod都有一个 pause-amd64 的基础容器自动会运行，对于用户是透明的
docker ps -a
registry.cn-hangzhou.aliyuncs.com/google-containers/pause-amd64:3.0 "/pause"2. Инициализировать контейнеры (initcontainers)
Контейнер Init должен завершиться до запуска контейнера приложения, а контейнер приложения работает параллельно, поэтому контейнер Init может предоставить простой метод для блокировки или задержки запуска контейнера приложения.
Контейнеры Init очень похожи на обычные контейнеры, за исключением следующих двух моментов:
- Контейнеры инициализации всегда выполняются до успешного завершения.
- Каждый контейнер Init должен успешно завершить запуск и выйти, прежде чем сможет запуститься следующий контейнер Init.
Если контейнер инициализации пода выходит из строя, k8s будет постоянно перезапускать под, пока контейнер инициализации не завершится успешно. Однако если соответствующая политика перезапуска (restartPolicy) модуля — «Никогда», он не будет перезапущен.
Контейнерная функция Init:
Поскольку контейнер инициализации имеет отдельный образ от контейнера приложения, его код, связанный с запуском, имеет следующие преимущества:
- Контейнер инициализации может содержать некоторый код утилиты или персонализации, которого нет в контейнере приложения во время установки. Например, нет необходимости ИЗ образа для создания нового образа просто использовать такие инструменты, как sed, awk, python или dig в процессе установки.
- Контейнеры инициализации могут безопасно запускать эти инструменты, чтобы эти инструменты не снижали безопасность образа приложения.
- Создатели и развертыватели образов приложений могут работать независимо, без необходимости совместного создания единого образа приложения.
- Контейнеры инициализации могут работать с другим представлением файловой системы, чем контейнеры приложений внутри модуля. Таким образом, контейнер Init может иметь доступ к секретам, а контейнер приложения — нет.
- Поскольку контейнер Init должен завершиться до запуска контейнера приложения, контейнер Init предоставляет механизм для блокировки или задержки запуска контейнера приложения.
до тех пор, пока не будет выполнен ряд предварительных условий. Как только предварительные условия будут выполнены, все контейнеры приложений в модуле будут запущены параллельно.
3. Контейнер приложений (Maincontainer)
Пример официального сайта: https://kubernetes.io/docs/concepts/workloads/pods/init-containers/
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
labels:
app: myapp
spec:
containers:
- name: myapp-container
image: busybox:1.28
command: ['sh', '-c', 'echo The app is running! && sleep 3600']
initContainers:
- name: init-myservice
image: busybox:1.28
command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
- name: init-mydb
image: busybox:1.28
command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']
这个例子是定义了一个具有 2 个 Init 容器的简单 Pod。 第一个等待 myservice 启动， 第二个等待 mydb 启动。 一旦这两个 Init容器都启动完成，Pod 将启动 spec 中的应用容器。
kubectl describe pod myapp-pod
#查看init-mysvc日志，查看问题所在
kubectl logs myapp-pod -c init-mysvc
kubectl create svc clusterip mysvc --tcp=80
kubectl create svc clusterip mydb --tcp=80
Специальная записка:
- Во время запуска Pod контейнеры Init запускаются последовательно после инициализации сети и тома данных. Каждый контейнер должен успешно завершиться, прежде чем сможет запуститься следующий контейнер.
- Если контейнер завершает работу из-за времени выполнения или сбоя, из-за чего контейнер не запускается, он повторяет попытку в соответствии с политикой, указанной в перезапуске Policy пода. Однако если для параметра restartPolicy модуля установлено значение Always, политика RestartPolicy будет использоваться в случае сбоя контейнера Init.
- Под не перейдет в состояние готовности до тех пор, пока все контейнеры инициализации не завершатся успешно. Порт контейнера Init не будет агрегирован в Сервисе. Инициализируемый модуль находится в состоянии ожидания, но для состояния инициализации должно быть установлено значение true.
- Если Pod перезапускается, все контейнеры Init должны быть выполнены повторно.
- Изменения спецификации контейнера Init ограничиваются полем изображения контейнера, а изменения в других полях не вступят в силу. Изменение поля изображения контейнера Init эквивалентно перезапуску модуля.
- Контейнер инициализации имеет все поля контейнера приложения. За исключением readinessProbe, поскольку контейнер Init не может определять другие состояния, кроме готовности, кроме завершения. Это применяется во время проверки.
- Каждое приложение и контейнер инициализации в модуле должны иметь уникальное имя; использование одного и того же имени с любым другим контейнером приведет к ошибке во время проверки.
7. Политика получения изображений (imagePullPolicy)
Ядром Pod является запуск контейнера. Необходимо указать движок контейнера, например Docker. При запуске контейнера необходимо извлечь образ. Стратегию извлечения образа k8s может указать пользователь:
- IfNotPresent: если образ уже существует, kubelet больше не будет извлекать образ. Он будет извлекать его из хранилища только в том случае, если он отсутствует локально. Стратегия получения зеркала по умолчанию
- Всегда: каждый раз при создании модуля изображение будет извлекаться снова;
- Никогда: модуль не будет активно извлекать этот образ и будет использовать только локальный образ.
Примечание. Для файлов изображений с меткой «:latest» политика получения изображений по умолчанию — «Всегда»; для изображений с другими метками политика по умолчанию — «IfNotPresent».
官方示例：
https://kubernetes.io/docs/concepts/containers/images
kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
name: private-image-test-1
spec:
containers:
- name: uses-private-image
image: $PRIVATE_IMAGE_NAME
imagePullPolicy: Always #每次创建重新拉取镜像
command: [ "echo", "SUCCESS" ]
EOF