Pod 的本质
Pod 包装了一个或多个容器。 Pod 是 K8S 的最小执行单元。 Pod 是 K8S 中的一个进程。 Pod 可包装 Docker，也支持包装其他类型容器。 Pod 包含封装的容器、存储资源、网络资源、以及指导容器如何运行的配置。
可以把容器理解为一个无挂钩的光秃秃的集装箱，K8S 这艘大船无法直接挂载它，通过给集装箱(容器)加装挂钩(IP地址)等形成一个 Pod，方便 K8S 来操作。
也可以把 Pod 理解为传统的虚拟机，而容器是传统虚拟机中运行的程序，只不过虚拟机是一个实体，而 Pod 是一个逻辑概念。
K8S 通过编排 Pod 来调度容器，而不是直接操作容器，K8S 无法直接操纵容器。
Pod 中的共享资源
Pod 为其中运行的多容器提供共享的网络、存储资源、命名空间。
网络
Pod 具有唯一 IP 地址，Pod 中的多个容器共享一个 IP 地址和网络端口等网络资源 Pod 中多容器可使用 localhost 通信 Pod 中容器和外部通信时候，多容器需要协调网络端口 Pod 中的容器获取的系统主机名与为 Pod 配置的 name 相同
存储
Pod 可指定一组存储卷 Pod 中多容器均可以访问该存储卷，以便互相共享数据 Pod 中的共享卷可以持久保存，防止容器重启丢失数据
Pod 的特点
如果使用 kind: Pod 的 yaml 文件来创建 Pod，当前节点服务器出现问题后，Pod 不能被自动调度到其他可用服务器。
一般使用 kind: Deployment 的 yaml 来创建 Pod。
Deployment 是一种控制器，可以用来创建、管理 Pod。如创建多副本 Pod，滚动更新 Pod。
当 Pod 所在节点出现问题，Deployment 控制器可以在集群中其他节点启动新 Pod。
Pod 模板
apiVersion: v1kind: Podmetadata: name: myapp-pod labels: app: myappspec: containers:- name: myapp-container image: busybox command:[sh,-c,echo Hello Kubernetes!&& sleep 3600]
镜像拉取策略
不具体指定的情况下，imagePullPolicy 是 Always，即 kubelet 会尝试从指定的仓库拉取每个镜像。如果容器属性 imagePullPolicy 设置为 IfNotPresent ，则会优先使用本地镜像。如果容器属性 imagePullPolicy 设置为 IfNotPresent Never，则会一定使用本地镜像。
apiVersion: v1kind: Podmetadata: name: private-image-test-1spec: containers:- name: uses-private-image image: nginx imagePullPolicy: Always command:[ “echo”,”SUCCESS”]
Pod 常用参数
NodeSelector
功能：将 Pod 与 Node 绑定
apiVersion: v1kind: Pod…spec: nodeSelector: disktype: ssd
该 Pod 只能运行在携带了“disktype：ssd”标签（Label）的节点上，如果没有这种标签的节点，调度将失败。
NodeName
该字段一般由调度器设置，但我们测试时候可以手工设置该字段，让调度器认为该 Pod 已经被调度过了。
HostAliase
给 Pod 里各容器的/etc/hosts 文件设置内容
apiVersion: v1kind: Pod……spec: hostAliases:- ip:”10.20.20.20″ hostnames:- “test1.com”- “test2.com”
进容器检查一下
[root@master01~]# kubectl exec -it nginx — bashroot@nginx:/# cat /etc/hosts……# Entries added by HostAliases.10.20.20.20 test1.com test2.com
shareProcessNamespace
定义参数 shareProcessNamespace=true，那么该 Pod 中所有容器将共享 PID Namespace
创建一个包含两个容器的 Pod
[root@master01~]# cat nginx.yaml apiVersion: v1kind: Podmetadata: name: nginxspec: shareProcessNamespace: true containers:- name: nginx image: nginx – name: shell image: busybox stdin: true tty: true
查看运行情况
[root@master01~]# kubectl get pods -o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESnginx 2/2 Running 0117s 192.10.137.131 work03
进入到 Pod nginx 中的名为 shell 的容器中
[root@master01~]# kubectl attach -it nginx -c shellIf you dont see a command prompt, try pressing enter./# ps auxPID USER TIME COMMAND 1 root 0:00/pause 6 root 0:00 nginx: master process nginx -g daemon off;331010:00 nginx: worker process 34 root 0:00 sh 39 root 0:00 ps aux
可以看到，shell 容器中可以看到 nginx 容器的进程
Pod 的预设参数 PodPreset
我们可以预先设置好一些通用的配置，当用户提交自己的个性化 Pod 配置时，PodPreset 就可以自动附加通用配置到对应的 Pod 上。
PodPreset 里定义的内容，只会在 Pod API 对象被创建之前追加在这个对象本身上，而不会影响任何 Pod 的控制器的定义。
比如，我们现在提交的是一个 nginx-deployment，那么这个 Deployment 对象本身是永远不会被 PodPreset 改变的，被修改的只是这个 Deployment 创建出来的所有 Pod。
未启用 PodPreset 特性时
# kubectl get podpresetserror: the server doesnt have a resource type “podpresets”
启用 PodPreset 特性
修改[/etc/kubernetes/manifests/kube-apiserver.yaml]中的spec.containers.command:修改原—runtime-config=api/all=true为—runtime-config=api/all=true,settings.k8s.io/v1alpha1=true新加一行—enable-admission-plugins=PodPreset3台MASTER均执行重启 kubeletsystemctl restart kubelet
预设值配置 preset.yaml
apiVersion: settings.k8s.io/v1alpha1kind: PodPresetmetadata: name: allow-tz-envspec: selector: matchLabels: env:- name: TZ value: Asia/Shanghai
Pod配置 nginx.yaml
apiVersion: v1kind: Podmetadata: name: nginxspec: containers:- name: nginx image: nginx
创建 PodPreset
# kubectl get podpresetNo resources found in default namespace.# kubectl apply -f podpreset.yamlpodpreset.settings.k8s.io/allow-tz-env created# kubectl get podpresetNAME CREATED ATallow-tz-env
创建 Pod
[root@master01~]# kubectl apply -f nginx.yaml pod/nginx created
查看该 Pod 是否被注入
# kubectl get pod nginx -o yaml …省略spec: containers:- env:- name: TZ value: Asia/Shanghai image: nginx imagePullPolicy: Always name: nginx resources:{}…省略
可以看到 Pod 被注入了名为 TZ 的 env
Init 容器
特点
Init 容器在 Pod 内应用容器启动之前运行。一个 Pod 可以有一个或多个 Init 容器。每个 Init 容器运行必须完成。如果 Init 容器运行失败，K8S 会不断重启该 Pod，直到 Init 容器运行成功。但如果 Pod 对应的 restartPolicy 值为 Never，它不会重新启动。如果一个 Pod 有多个 Init 容器，这些容器会按顺序逐个运行。每个 Init 容器必须运行成功，下一个才能够运行。Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。例如，没有必要仅为了在安装过程中使用类似 sed、 awk、 python 或 dig 这样的工具而去FROM 一个镜像来生成一个新的镜像。Init 容器可以安全地运行这些工具，避免这些工具导致应用镜像的安全性降低。应用镜像的创建者和部署者可以各自独立工作，而没有必要联合构建一个单独的应用镜像。Init 容器能以不同于 Pod 内应用容器的文件系统视图运行。因此，Init容器可具有访问 Secrets 的权限，而应用容器不能够访问。由于 Init 容器必须在应用容器启动之前运行完成，因此 Init 容器提供了一种机制来阻塞或延迟应用容器的启动，直到满足了一组先决条件。一旦前置条件满足，Pod 内的所有的应用容器会并行启动。在所有的 Init 容器没有成功之前，Pod 将不会变成 Ready 状态。Init 容器镜像的变更会引起 Pod 重启，应用容器镜像的变更仅会重启应用容器。Pod 中每一个容器副本启动之前，都会执行一遍 Init 容器。
如何使用
定义一个具有2 个 Init 容器的 Pod。init 容器为 myservice 和 mydb。这两个 Init 容器都启动完成，Pod 才能启动 spec 区域中的应用容器 myapp-container
创建 Pod 的 YAML 文件：
cat myapp.yaml
apiVersion: v1kind: Podmetadata: name: myapp-pod labels: app: myappspec: 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.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for myservice; sleep 2; done”]- name: init-mydb image: busybox:1.28 command:[sh,-c,”until nslookup mydb.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for mydb; sleep 2; done”]
创建 mydb 和 myservice 两个 Service 的 YAML 文件：
cat myservice.yaml
kind: ServiceapiVersion: v1metadata: name: myservicespec: ports:- protocol: TCP port:80 targetPort:9376—kind: ServiceapiVersion: v1metadata: name: mydbspec: ports:- protocol: TCP port:80 targetPort:9377
要启动这个 Pod，可以执行如下命令：
kubectl apply -f myapp.yamlpod/myapp-pod created
检查其状态：
kubectl get -f myapp.yamlNAME READY STATUS RESTARTS AGEmyapp-pod 0/1 Init:0/20 6m
使用下面命令查看更详细的信息：
kubectl describe -f myapp.yamlName: myapp-podNamespace: default[…]Labels: app=myappStatus: Pending[…]Init Containers: init-myservice:[…] State: Running[…] init-mydb:[…] State: Waiting Reason: PodInitializing Ready: False[…]Containers: myapp-container:[…] State: Waiting Reason: PodInitializing Ready: False[…]
查看Pod内 Init 容器的日志
$ kubectl logs myapp-pod -c init-myservice$ kubectl logs myapp-pod -c init-mydb
此时，Init 容器将会等待直到发现名称为mydb和myservice的 Service。
创建mydb和myservice的 service：
$ kubectl create -f services.yamlservice “myservice” createdservice “mydb” created
可以看到这些 Init 容器执行完毕，随后my-app的Pod转移进入 Running 状态：
$ kubectl get -f myapp.yamlNAME READY STATUS RESTARTS AGEmyapp-pod 1/1 Running 09m
只有我们启动了 mydb 和 myservice 这两个 Service，Init 容器完成，myapp-pod 才能被创建。
Debug Pod
如果 Pod 被终止，可通过如下命令查看原因
kubectl describe pod pod名称kubectl get pod -o go-template={{range.status.containerStatuses}}{{“Container Name:”}}{{.name}}{{“\r\nLastState:”}}{{.lastState}}{{end}} pod名称
结束语
Pod 包装了容器，K8S 通过操作 Pod 来操作容器。
Pod 可以包含多个应用容器和多个 Init 容器。
人工直接创建的 Pod 在服务器节点故障时，没有自愈能力，需要使用控制器来解决这个问题。
暂无评论内容