Pod [Nativo de la nube] en detalle

1. Conceptos básicos de Pod

• Pod es el componente de gestión de recursos más pequeño de Kubernetes y también es el objeto de recurso que minimiza la ejecución de aplicaciones en contenedores. Un Pod representa un proceso que se ejecuta en el clúster. La mayoría de los demás componentes de Kubernetes giran en torno a Pods para admitir y ampliar las funciones de Pod. Por ejemplo, los objetos de controlador como StatefulSet y Deployment se utilizan para gestionar la ejecución de Pods, los objetos Service e Ingress se utilizan para exponer aplicaciones Pod y proporcionar servicios para Pods. El PersistentVolume almacenado almacena objetos de recursos, etc.

1.1//En el clúster de Kubrenes, Pod se puede utilizar de las dos formas siguientes:

●Un contenedor se ejecuta en un Pod. El modelo "un contenedor en cada Pod" es el uso más común; en este uso, puede pensar en el Pod como una encapsulación de un único contenedor, y kuberentes administra el Pod en lugar de administrar directamente el contenedor.

●Ejecute varios contenedores simultáneamente en un Pod. Un Pod también puede encapsular varios contenedores que deben estar estrechamente acoplados, cooperar entre sí y compartir recursos entre ellos. Estos contenedores en el mismo Pod pueden cooperar entre sí para formar una unidad de servicio, como un contenedor que comparte archivos y otro contenedor "sidecar" que actualiza estos archivos. Pod gestiona los recursos de almacenamiento de estos contenedores como una entidad.

Los contenedores bajo un Pod deben ejecutarse en el mismo nodo. La tecnología de contenedores moderna recomienda que un contenedor solo ejecute un proceso. El número de proceso en el espacio de nombres PID del contenedor es 1, que puede recibir y procesar señales directamente. Cuando finaliza el proceso, finaliza el ciclo de vida del contenedor. Si desea ejecutar múltiples procesos en un contenedor, necesita un proceso de administración y control similar al proceso de inicio del sistema operativo Linux para completar la administración del ciclo de vida de múltiples procesos en una estructura de árbol. Los procesos que se ejecutan en sus respectivos contenedores no pueden completar directamente la comunicación de red. Esto se debe al mecanismo de aislamiento entre contenedores. La abstracción de recursos Pod en k8s resuelve este problema. El objeto Pod es una colección de contenedores que comparten espacios de nombres NET, MNT, UTS e IPC. Por lo tanto, tienen el mismo nombre de dominio, nombre de host e interfaz de red y pueden comunicarse directamente a través de IPC.

La pausa del contenedor básico subyacente en los recursos Pod proporciona un espacio de nombres de red y otros mecanismos para compartir para cada contenedor. La pausa del contenedor básico (también llamado contenedor principal) es para gestionar las operaciones compartidas entre contenedores Pod. Este contenedor principal debe poder saber exactamente cómo Crear contenedores que compartan un entorno de ejecución y gestionar los ciclos de vida de estos contenedores. Para hacer realidad la idea de este contenedor principal, en Kubernetes, el contenedor de pausa se utiliza como contenedor principal de todos los contenedores en un Pod. Este contenedor de pausa tiene dos funciones principales: una es que proporciona la base para todo el espacio de nombres de Linux del Pod. En segundo lugar, habilite el espacio de nombres PID, que actúa como un proceso con PID 1 (proceso de inicio) en cada Pod y recicla procesos zombie.

El contenedor 1.2pause permite que todos los contenedores del Pod compartan dos recursos: red y almacenamiento.

●Red:

A cada Pod se le asignará una dirección IP única. Todos los contenedores de un Pod comparten espacio de red, incluidas direcciones IP y puertos. Los contenedores dentro de un Pod pueden comunicarse entre sí mediante localhost. Cuando el contenedor en el Pod se comunica con el mundo exterior, debe asignar recursos de red compartidos (como usar el mapeo de puertos del host).

●Almacenamiento :

El pod puede especificar varios volúmenes compartidos. Todos los contenedores de un Pod pueden acceder al Volumen compartido. El volumen también se puede utilizar para conservar los recursos de almacenamiento en Pods para evitar la pérdida de archivos después de reiniciar el contenedor.

1.3 El contenedor de pausa en Kubernetes proporciona principalmente las siguientes funciones para cada contenedor:

●Sirve como base para compartir el espacio de nombres de Linux (como el espacio de comandos de red) en el pod;
●Habilita el espacio de nombres PID e inicia el proceso de inicio.

1.4¿Cuál es el propósito de Kubernetes al diseñar dicho concepto de Pod y una estructura de composición especial? ? ? ? ?

●Razón 1: Cuando un grupo de contenedores se trata como una unidad, es difícil juzgar simplemente y actuar eficazmente sobre todo el contenedor. Por ejemplo, si un contenedor muere, ¿se considera que todo el contenedor está caído? Luego introduzca un contenedor de Pausa que no tenga nada que ver con el negocio como el contenedor básico del Pod, y su estado representa el estado de todo el grupo de contenedores, para que este problema se pueda resolver.

●Razón 2: Varios contenedores de aplicaciones en el Pod comparten la IP del contenedor de pausa y el volumen montado por el contenedor de pausa, lo que simplifica el problema de comunicación entre contenedores de aplicaciones y también resuelve el problema de compartir archivos entre contenedores.

1.5 Los pods suelen dividirse en las siguientes categorías:

●Pod autónomo

Este tipo de Pod en sí no puede repararse por sí solo. Cuando se crea un Pod (ya sea creado directamente por usted o por otro Controlador), Kuberentes lo programará en el Nodo del clúster. El Pod permanecerá en ese Nodo hasta que el proceso del Pod finalice, se elimine, se desaloje por falta de recursos o el Nodo falle. Las vainas no se curarán solas. Si falla el nodo que ejecuta un pod, o el propio programador falla, el pod se eliminará. De manera similar, si el Nodo donde se encuentra el Pod carece de recursos o el Pod está en estado de mantenimiento, el Pod también será desalojado.

●Pods administrados por el controlador

Kubernetes utiliza una capa de abstracción de nivel superior llamada Controlador para administrar instancias de Pod. El controlador puede crear y administrar múltiples Pods, proporcionando administración de copias, actualizaciones continuas y capacidades de autorreparación a nivel de clúster. Por ejemplo, si un nodo falla, el controlador puede programar automáticamente los pods del nodo para otros nodos en buen estado. Aunque los Pods se pueden usar directamente, los Controladores generalmente se usan para administrar Pods en Kubernetes.

●Pod estático

Los pods estáticos son administrados directamente por el proceso kubelet en un nodo específico, no a través del apiserver en el nodo maestro. No se puede asociar con la implementación del controlador o DaemonSet. Es monitoreado por el proceso de kubelet. Cuando el pod falla, el pod se reinicia y kubelet no puede realizar comprobaciones de estado en ellos. Los pods estáticos siempre están vinculados a un determinado kubelet y siempre se ejecutan en el mismo nodo. Kubelet creará automáticamente un Pod espejo (Mirror Pod) para cada pod estático en el apiserver de Kubernetes, por lo que podemos consultar el pod en el apiserver, pero no se puede controlar a través del apiserver (por ejemplo, no se puede eliminar).

Ver archivo de configuración de kubelet

/var/lib/kubelet/config.yaml
cat /var/lib/kubelet/config.yaml | grep staticPodPath
staticPodPath: /etc/kubernetes/manifests

También puede usar el siguiente comando para encontrar el archivo de configuración de inicio correspondiente a kubelet, modificar el archivo de configuración de kubelet del nodo y agregar la configuración de la variable de entorno del parámetro estático 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

Prepare el archivo Json o Yaml del Pod en el directorio de administración del archivo Pod estático

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

• El kubelet en ejecución escanea periódicamente el directorio configurado en busca de cambios de archivos y crea o elimina pods cuando un archivo aparece o desaparece en este directorio.
• El Pod también se puede ver en el nodo maestro. Si ejecuta el comando kubectl delete pod static-web-node01 para eliminar el Pod, encontrará que no se puede eliminar.

1.6 Clasificación de contenedores Pod:

1. Contenedor de infraestructura

• Mantener toda la red Pod y el espacio de almacenamiento
• operación de nodo en nodo
• Al iniciar un Pod, k8s iniciará automáticamente un contenedor básico

cat /opt/kubernetes/cfg/kubelet
......
--pod-infra-container-image=registry.cn-hangzhou.aliyuncs.com/google-containers/pause-amd64:3.0"

• Se creará cada vez que se cree un Pod. Cada Pod en ejecución tiene un contenedor básico pausa-amd64 que se ejecutará automáticamente y es transparente para los usuarios.

docker ps -a
registry.cn-hangzhou.aliyuncs.com/google-containers/pause-amd64:3.0   "/pause"

2. Inicializar contenedores (initcontainers)

• El contenedor de inicio debe ejecutarse hasta su finalización antes de que se inicie el contenedor de la aplicación, y el contenedor de la aplicación se ejecuta en paralelo, por lo que el contenedor de inicio puede proporcionar un método simple para bloquear o retrasar el inicio del contenedor de la aplicación.
  Los contenedores de inicio son muy similares a los contenedores normales, excepto por los dos puntos siguientes:

●El contenedor de inicio siempre se ejecuta hasta completarse exitosamente.

●Cada contenedor Init debe completar con éxito el inicio y salir antes de que se inicie el siguiente contenedor Init.
Si el contenedor Init de un Pod falla, k8s reiniciará continuamente el Pod hasta que el contenedor Init tenga éxito. Sin embargo, si la política de reinicio correspondiente (restartPolicy) del Pod es Nunca, no se reiniciará.

El papel contenedor de Init

• Debido a que el contenedor de inicio tiene una imagen separada del contenedor de la aplicación, su código relacionado con el inicio tiene las siguientes ventajas:

●El contenedor de inicio puede contener algunas utilidades o códigos de personalización que no están presentes en el contenedor de la aplicación durante la instalación. Por ejemplo, no es necesario DESDE una imagen para generar una nueva imagen, solo para usar herramientas como sed, awk, python o dig durante el proceso de instalación.

●El contenedor Init puede ejecutar estas herramientas de forma segura para evitar que reduzcan la seguridad de la imagen de la aplicación.

●Los creadores e implementadores de imágenes de aplicaciones pueden trabajar de forma independiente sin tener que crear conjuntamente una imagen de aplicación independiente.

●El contenedor Init puede ejecutarse con una vista del sistema de archivos diferente a la del contenedor de la aplicación dentro del Pod. Por lo tanto, el contenedor de inicio puede tener acceso a los secretos, pero el contenedor de la aplicación no.

●Debido a que el contenedor Init debe ejecutarse hasta su finalización antes de que se inicie el contenedor de la aplicación, el contenedor Init proporciona un mecanismo para bloquear o retrasar el inicio del contenedor de la aplicación hasta que se
cumpla un conjunto de requisitos previos. Una vez que se cumplan las condiciones previas, todos los contenedores de aplicaciones en el Pod se iniciarán en paralelo.

3. Contenedor de aplicaciones (contenedor principal)

• inicio paralelo

Ejemplo de sitio web oficial:

https://kubernetes.io/docs/concepts/workloads/pods/init-containers/

a

piVersion: 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;']

• Este ejemplo define un Pod simple con 2 contenedores Init. El primero espera a que se inicie myservice y el segundo espera a que se inicie mydb. Una vez que se inician ambos contenedores Init, el Pod iniciará el contenedor de la aplicación en la especificación.

k

ubectl describe pod myapp-pod

kubectl logs myapp-pod -c init-myservice

vim myservice.yaml
apiVersion: v1
kind: Service
metadata:
  name: myservice
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376
	
kubectl create -f myservice.yaml

kubectl get svc

kubectl get pods -n kube-system

kubectl get pods

vim mydb.yaml
apiVersion: v1
kind: Service
metadata:
  name: mydb
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9377
	
kubectl create -f mydb.yaml

kubectl get pods

Nota especial

●Durante el proceso de inicio del Pod, el contenedor Init se iniciará en secuencia después de que se inicialicen la red y los volúmenes de datos. Cada contenedor debe salir exitosamente antes de que se pueda iniciar el siguiente contenedor.
●Si el contenedor no se inicia debido al tiempo de ejecución o a una salida fallida, lo volverá a intentar de acuerdo con la política especificada por la política de reinicio del Pod. Sin embargo, si la política de reinicio del pod está configurada en Siempre, la política de reinicio se utilizará cuando falle el contenedor de inicio.
●El Pod no estará listo hasta que todos los contenedores de inicio tengan éxito. El puerto del contenedor Init no se agregará al Servicio. El Pod que se está inicializando está en estado Pendiente, pero el estado Inicializando debe establecerse en verdadero.
●Si se reinicia el Pod, se deben volver a ejecutar todos los contenedores de inicio.
●Las modificaciones a la especificación del contenedor Init se limitan al campo de imagen del contenedor y las modificaciones a otros campos no tendrán efecto. Cambiar el campo de imagen del contenedor Init equivale a reiniciar el Pod.
●El contenedor de inicio tiene todos los campos del contenedor de aplicación. Excepto readinessProbe, porque el contenedor Init no puede definir otros estados además de la preparación además de la finalización. Esto se aplica durante el proceso de validación.
●El nombre de cada aplicación y contenedor de inicio en un Pod debe ser único; compartir el mismo nombre con cualquier otro contenedor generará un error durante la verificación.

1.7 Política de extracción de imágenes (imagePullPolicy)

• El núcleo de Pod es ejecutar el contenedor. Se debe especificar el motor del contenedor, como Docker. Al iniciar el contenedor, se debe extraer la imagen. La estrategia de extracción de imágenes de k8s puede ser especificada por el usuario:
  • 1. IfNotPresent: cuando la imagen ya existe, kubelet ya no la extraerá. Solo la extraerá del almacén cuando falte localmente. La estrategia de extracción de imágenes predeterminada
  • 2. Siempre: cada vez que se crea un Pod, la imagen se extraerá nuevamente;
  • 3. Nunca: Pod no extraerá activamente esta imagen y solo utilizará imágenes locales.
    Nota: Para archivos de imagen con la etiqueta ":latest", la política de adquisición de imágenes predeterminada es "Siempre"; para imágenes con otras etiquetas, la política predeterminada es "IfNotPresent".

Ejemplo oficial:

https://kubernetes.io/docs/concepts/containers/images

a

bectl 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


//master01 上操作
kubectl edit deployment/nginx-deployment
......
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.15.4
        imagePullPolicy: IfNotPresent							#镜像拉取策略为 IfNotPresent
        name: nginx
        ports:
        - containerPort: 80
          protocol: TCP
        resources: {
    
    }
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always										#Pod的重启策略为 Always，默认值
      schedulerName: default-scheduler
      securityContext: {
    
    }
      terminationGracePeriodSeconds: 30
......

//Crear caso de prueba

mkdir /opt/demo
cd /opt/demo

vim pod1.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-test1
spec:
  containers:
    - name: nginx
      image: nginx
      imagePullPolicy: Always
      command: [ "echo", "SUCCESS" ]


kubectl create -f pod1.yaml

kubectl get pods -o wide
pod-test1                         0/1     CrashLoopBackOff   4          3m33s

// El estado del Pod es anormal en este momento, la razón es que el proceso de eco finaliza después de la ejecución y el ciclo de vida del contenedor también finaliza.

kubectl describe pod pod-test1
......
Events:
  Type     Reason     Age                 From                    Message
  ----     ------     ----                ----                    -------
  Normal   Scheduled  2m10s               default-scheduler       Successfully assigned default/pod-test1 to 192.168.80.11
  Normal   Pulled     46s (x4 over 119s)  kubelet, 192.168.80.11  Successfully pulled image "nginx"
  Normal   Created    46s (x4 over 119s)  kubelet, 192.168.80.11  Created container
  Normal   Started    46s (x4 over 119s)  kubelet, 192.168.80.11  Started container
  Warning  BackOff    19s (x7 over 107s)  kubelet, 192.168.80.11  Back-off restarting failed container
  Normal   Pulling    5s (x5 over 2m8s)   kubelet, 192.168.80.11  pulling image "nginx"
//可以发现 Pod 中的容器在生命周期结束后，由于 Pod 的重启策略为 Always，容器再次重启了，并且又重新开始拉取镜像

//修改 pod1.yaml 文件
cd /opt/demo
vim pod1.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-test1
spec:
  containers:
    - name: nginx
      image: nginx:1.14							#修改 nginx 镜像版本
      imagePullPolicy: Always
      #command: [ "echo", "SUCCESS" ]			#删除

//删除原有的资源
kubectl delete -f pod1.yaml 

//更新资源
kubectl apply -f pod1.yaml 

//查看 Pod 状态
kubectl get pods -o wide
NAME                              READY   STATUS    RESTARTS   AGE   IP            NODE            NOMINATED NODE
pod-test1                         1/1     Running   0          33s   172.17.36.4   192.168.80.11   <none>

//在任意 node 节点上使用 curl 查看头部信息
curl -I http://172.17.36.4
HTTP/1.1 200 OK
Server: nginx/1.14.2
......

1.8 Implementar puerto y crear un proyecto privado

//Operar en el nodo del puerto Docker (192.168.80.30)

systemctl stop firewalld.service
systemctl disable firewalld.service
setenforce 0

yum install -y yum-utils device-mapper-persistent-data lvm2 
yum-config-manager --add-repo https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo 
yum install -y docker-ce
systemctl start docker.service
systemctl enable docker.service
docker version
//上传 docker-compose 和 harbor-offline-installer-v1.2.2.tgz 到 /opt 目录中
cd /opt
chmod +x docker-compose
mv docker-compose /usr/local/bin/

//部署 Harbor 服务
tar zxvf harbor-offline-installer-v1.2.2.tgz -C /usr/local/
vim /usr/local/harbor/harbor.cfg
--5行--修改，设置为Harbor服务器的IP地址或者域名
hostname = 192.168.80.30

cd /usr/local/harbor/
./install.sh

Crear un nuevo proyecto en Harbour

(1) Acceso al navegador: http://192.168.80.10 Inicie sesión en la interfaz WEB UI de Harbor. El nombre de usuario y la contraseña predeterminados del administrador son admin/Harbor12345
(2) Después de ingresar el nombre de usuario y la contraseña para iniciar sesión en la interfaz, puede crear un nuevo proyecto. Haga clic en el botón "+ Proyecto"
(3) complete el nombre del proyecto como "kgc-project", haga clic en el botón "Aceptar" para crear un nuevo proyecto

//Configurar la conexión al almacén privado en cada nodo (tenga en cuenta la coma después de cada línea)

cat > /etc/docker/daemon.json <<EOF
{
  "registry-mirrors": ["https://6ijb8ubo.mirror.aliyuncs.com"],
  "insecure-registries":["192.168.80.30"]
}
EOF

systemctl daemon-reload
systemctl restart docker

//在每个 node 节点登录 harbor 私有仓库
docker login -u admin -p harbor12345 http://192.168.80.30

//在一个 node 节点下载 Tomcat 镜像进行推送
docker pull tomcat:8.0.52
docker images

docker tag tomcat:8.0.52 192.168.80.30/kgc-project/tomcat:v1
docker images

docker push 192.168.80.30/kgc-project/tomcat:v1


//查看登陆凭据
cat /root/.docker/config.json | base64 -w 0			#base64 -w 0：进行 base64 加密并禁止自动换行
ewoJImF1dGhzIjogewoJCSIxOTIuMTY4LjE5NS44MCI6IHsKCQkJImF1dGgiOiAiWVdSdGFXNDZTR0Z5WW05eU1USXpORFU9IgoJCX0KCX0sCgkiSHR0cEhlYWRlcnMiOiB7CgkJIlVzZXItQWdlbnQiOiAiRG9ja2VyLUNsaWVudC8xOS4wMy41IChsaW51eCkiCgl9Cn0=