Linux云计算运维架构师（连载）-Pod API属性详解-01

发布时间：2022-10-26 16:00:19 所属栏目：云计算来源：转载

导读： Linux云计算运维架构师（连载）-Pod API属性详解-01
1、Pod 属性分类
Pod是 K8S 项目中的最小编排单位。将这个设计落实到 API 对象上，容器（Container）就成了 Pod 属性里一个普通的字段。

1、Pod 属性分类

Pod是 K8S 项目中的最小编排单位。将这个设计落实到 API 对象上，容器（Container）就成了 Pod 属性里一个普通的字段。

问题：

到底哪些属性属于 Pod 对象，哪些属性属于 Container？

解决：

Pod 扮演的是传统环境里"虚拟机"的角色。是为了使用户从传统环境（虚拟机环境）向 K8S（容器环境）的迁移，更加平滑。

把 Pod 看成传统环境里的"机器"、把容器看作是运行在这个"机器"里的"用户程序"，那么很多关于 Pod 对象的设计就非常容易理解了。

凡是调度、网络、存储，以及安全相关的属性，基本上是 Pod 级别的。

共同特征是，它们描述的是"机器"这个整体，而不是里面运行的"程序"。

比如：

1.arpVersion

2、kind

指定了这个 API 对象的类型（Type），是一个 Pod，根据实际情况，此处资源类型可以是Deployment、Job、Ingress、Service等。

3、metadata

包含Pod的一些meta信息，比如名称、namespace、标签等信息。

4、spec

specification of the resource content 指定该资源的内容,包括一些container，storage，volume以及其他Kubernetes需要的参数，以及诸如是否在容器失败时重新启动容器的属性。可在特定Kubernetes API找到完整的Kubernetes Pod的属性。

容器可选的设置属性：

除了上述的基本属性外，还能够指定复杂的属性，包括容器启动运行的命令、使用的参数、工作目录以及每次实例化是否拉取新的副本。还可以指定更深入的信息，例如容器的退出日志的位置。

容器可选的设置属性包括：

name、image、command、args、workingDir、ports、env、resource、volumeMounts、livenessProbe、readinessProbe、livecycle、terminationMessagePath、imagePullPolicy、securityContext、stdin、stdinOnce、tty

跟"机器"相关的配置

5、nodeSelector

是一个供用户将 Pod 与 Node 进行绑定的字段，用法：

kubectl describe nodes w101


  apiVersion: v1
  kind: Pod
  ...
  spec:
   nodeSelector:
    disktype: ssd

表示这个 Pod 永远只能运行在携带了"disktype: ssd"标签（Label）的节点上；否则，它将调度失败。

6、NodeName

nodeName= web2

一旦 Pod 的这个字段被赋值，K8S就会被认为这个 Pod 已经经过了调度，调度的结果就是赋值的节点名字。

这个字段一般由调度器负责设置，用户也可以设置它来"骗过"调度器，这个做法一般是在测试或者调试的时候才会用到。

7、HostAliases

连接到容器

# kubectl exec -it test1 -- /bin/bash

定义 Pod 的 hosts 文件（比如 /etc/hosts）里的内容，用法：


  apiVersion: v1
  kind: Pod
  ...
  spec:
   hostAliases:
   - ip: "10.1.2.3"
     hostnames:
     - "foo.remote"
     - "bar.remote"
  ...

这里设置了一组 IP 和 hostname 的数据。

此Pod 启动后，/etc/hosts 的内容将如下所示：

    # cat /etc/hosts
  # Kubernetes-managed hosts file.
  127.0.0.1 localhost
  ...
  10.244.135.10 hostaliases-pod
  10.1.2.3 foo.remote
  10.1.2.3 bar.remote

注：在 K8S 中，如果要设置 hosts 文件里的内容，一定要通过这种方法。否则，如果直接修改了 hosts 文件，在 Pod 被删除重建之后，kubelet 会自动覆盖掉被修改的内容。

凡是跟容器的 Linux Namespace 相关的属性，也一定是 Pod 级别的

原因：Pod 的设计，就是要让它里面的容器尽可能多地共享 Linux Namespace，仅保留必要的隔离和限制能力。这样，Pod 模拟出的效果，就跟虚拟机里程序间的关系非常类似了。

举例，一个 Pod 定义 yaml 文件如下：


apiVersion: v1
kind: Pod
metadata:
 name: nginx
?
spec:
 shareProcessNamespace: true
 
 containers:
 - name: nginx
   image: nginx
   
 - name: shell
   image: busybox
   stdin: true
   tty: true

定义了 shareProcessNamespace=true

表示这个 Pod 里的容器要共享 PID Namespace定义了两个容器：

一个 nginx 容器

一个开启了 tty 和 stdin 的 shell 容器

在 Pod 的 YAML 文件里声明开启它们俩，等同于设置了 docker run 里的 -it（-i 即 stdin，-t 即 tty）参数。

可以直接认为 tty 就是 Linux 给用户提供的一个常驻小程序，用于接收用户的标准输入，返回操作系统的标准输出。为了能够在 tty 中输入信息，需要同时开启 stdin（标准输入流）。

此 Pod 被创建后，就可以使用 shell 容器的 tty 跟这个容器进行交互了。

创建资源并连接到 shell 容器的 tty 上：

# kubectl attach -it nginx -c shell

在 shell 容器里执行 ps 指令，查看所有正在运行的进程：

# kubectl attach -it nginx -c shell
/# ps ax
PID  USER   TIME  COMMAND
  1 root    0:00 /pause
  8 root    0:00 nginx: master process nginx -g daemon off;
  14 101    0:00 nginx: worker process
  15 root    0:00 sh
  21 root    0:00 ps ax

在容器里不仅可以看到它本身的 ps ax 指令，还可以看到 nginx 容器的进程，以及 Infra 容器的 /pause 进程。也就是说整个 Pod 里的每个容器的进程，对于所有容器来说都是可见的：它们共享了同一个 PID Namespace。

凡是 Pod 中的容器要共享宿主机的 Namespace，也一定是 Pod 级别的定义

比如：


apiVersion: v1
kind: Pod
metadata:
 name: nginx
spec:
 hostNetwork: true
 hostIPC: true
 hostPID: true
 containers:
 - name: nginx
   image: nginx
 - name: shell
   image: busybox
   stdin: true
   tty: true

定义了共享宿主机的 Network、IPC 和 PID Namespace。这样，此 Pod 里的所有容器，会直接使用宿主机的网络、直接与宿主机进行 IPC 通信、看到宿主机里正在运行的所有进程。

8、常用容器属性

Pod 里最重要的字段"Containers"：

"Containers"和"Init Containers"这两个字段都属于 Pod 对容器的定义，内容也完全相同，只是 Init Containers 的生命周期，会先于所有的 Containers，并且严格按照定义的顺序执行。

K8S 对 Container 的定义，和 Docker 相比并没有什么太大区别。

Docker中Image（镜像）、Command（启动命令）、workingDir（容器的工作目录）、Ports（容器要开发的端口），以及 volumeMounts（容器要挂载的 Volume）都是构成 K8S 中 Container 的主要字段。

9、其他的容器属性1、 imagePullPolicy 字段

定义镜像的拉取策略。之所以是一个 Container 级别的属性，是因为容器镜像本来就是 Container 定义中的一部分。

默认值： Always

表示每次创建 Pod 都重新拉取一次镜像。

当容器的镜像是类似于 nginx 或者 nginx:latest 这样的名字时，ImagePullPolicy 也会被认为 Always。

值：Never 或者 IfNotPresent

表示 Pod 永远不会主动拉取这个镜像，或者只在宿主机上不存在这个镜像时才拉取。

事例：


    spec:
      containers:
        - name: kubernetes-dashboard
          image: kubernetesui/dashboard:v2.0.0-rc5
          imagePullPolicy: IfNotPresent

2、 Lifecycle 字段

定义 Container Lifecycle Hooks（钩子=行程开关）。作用是在容器状态发生变化时触发一系列"钩子"。启动之后和关闭之前做的一个指令。

注： lifecycle /la?f ?sa?kl/ n 生命周期

lifecycle：生命周期就是pod的状态

git可以判断有更新就执行钩子脚本，类似于Jenkins

svn 和git的区别

svn是C/S git是分布式

例子：这是 K8S 官方文档的一个 Pod YAML 文件

在这个例子中，容器成功启动之后，在 /usr/share/message 里写入了一句"欢迎信息"（即 postStart 定义的操作）。而在这个容器被删除之前，我们则先调用了 nginx 的退出指令（即 preStop 定义的操作），从而实现了容器的"优雅退出"。


apiVersion: v1
kind: Pod
metadata:
 name: lifecycle-demo
spec:
 containers:
 - name: lifecycle-demo-container
   image: nginx
   lifecycle:
    postStart: #容器启动后要去执行 post=之后
     exec:
        command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"] #所有要做的指令要写成一行，放到command 
?
    preStop:
       exec:
           command: ["/usr/sbin/nginx","-s","quit"] # grace 优雅的关闭nginx

command: ["sh","-c","echo -n hello"] 空格变逗号，所有命令引用起来command: ["sh","-c","while :; do echo 'hello'; done "]restart= shutdown && startup定义了一个 nginx 镜像的容器设置了一个 postStart 和 preStop 参数

postStart:

? 是在容器启动后，立刻执行一个指定的操作。

? 注意：

?postStart 定义的操作，虽然是在 Docker 容器 ENTRYPOINT 执行之后，但它并不严格保证顺序。

?也就是说，在 postStart 启动时，ENTRYPOINT 有可能还没有结束。

?如果 postStart执行超时或者错误，K8S 会在该 Pod 的 Events 中报出该容器启动失败的错误信息，导致 Pod 也处于失败的状态。

preStop:

? 是容器被杀死之前（比如，收到了 SIGKILL 信号）。

? 注意：

?preStop 操作的执行，是同步的。

?所以，它会阻塞当前的容器杀死流程，直到这个 Hook 定义操作完成之后，才允许容器被杀死云计算架构师，这跟 postStart 不一样。

一个Pod 对象在 Kubernetes 中的生命周期

Pod 生命周期的变化，主要体现在 Pod API 对象的Status 部分，这是除了 Metadata 和 Spec 之外的第三个重要字段。其中，pod.status.phase，就是 Pod 的当前状态，有如下几种可能的情况：

Pending：准备状态

此状态表示Pod 的 YAML 文件已经提交给了 Kubernetes，API 对象已经被创建并保存在 Etcd 当中。

但这个 Pod 里有些容器因为某种原因而不能被顺利创建。比如，调度不成功。

Running：运行状态

此状态表示Pod 已经调度成功，跟一个具体的节点绑定。它包含的容器都已经创建成功，并且至少有一个正在运行中。

Succeeded：同completed ：完成状态 1/1 2/2 0/1 completed (有些容器里面的不是一个服务，运行一段时间就完成了，然是会报0/1)

此状态表示 Pod 里的所有容器都正常运行完毕，并且已经退出了。这种情况在运行一次性任务时最为常见。

Failed：失败的

此状态表示 Pod 里至少有一个容器以不正常的状态（非 0 的返回码）退出。

这个状态的出现，意味着你得想办法 Debug 这个容器的应用，比如查看 Pod 的 Events 和日志。

Unknown：未知状态

这是一个异常状态，表示 Pod 的状态不能持续地被 kubelet 汇报给 kube-apiserver

这很有可能是主从节点（Master 和 Kubelet）间的通信出现了问题。

Pod 对象的 Status 字段，还可以再细分出一组 Conditions：

这些细分状态的值包括：PodScheduled、Ready、Initialized，以及 Unschedulable

它们主要用于描述造成当前 Status 的具体原因是什么。

比如, Pod 当前的 Status 是 Pending，对应的 Condition 是 Unschedulable，这表示它的调度出现了问题。

比如, Ready 这个细分状态表示 Pod 不仅已经正常启动（Running 状态），而且已经可以对外提供服务了。这两者之间（Running 和 Ready）是有区别的，仔细思考一下。

Pod 的这些状态信息，是判断应用运行情况的重要标准，尤其是 Pod 进入了非"Running"状态后，一定要能迅速做出反应，根据它所代表的异常情况开始跟踪和定位，而不是去手忙脚乱地查阅文档。

有基础的可以仔细阅读 $GOPATH/src/K8S.io/kubernetes/vendor/K8S.io/api/core/v1/types.go 里，type Pod struct ，尤其是 PodSpec 部分的内容。

10、投射数据卷 Projected Volume

注：Projected Volume 是 Kubernetes v1.11 之后的新特性

什么是Projected Volume ,k8s中存储相关的都是volume

在 K8S 中，有几种特殊的 Volume，它们的意义不是为了存放容器里的数据，也不是用来进行容器和宿主机之间的数据交换。而是为容器提供预先定义好的数据。从容器的角度来看，这些 Volume 里的信息仿佛是被 K8S "投射"（Project）进入容器当中的。

K8S 支持的 Projected Volume 一共有四种：

Secret 秘密：安全：K8s存储数据的一种方式，他是存到k8s集群的etcd数据库，适合存储短小的数据。比如说用户名和密码。etcdctl = etc数据库的客户端 jianshu.com/p/cd93f7b3f089ConfigMap：K8s存储数据的一种方式，他是存到k8s集群的etcd数据库，适合存储配置文件，比如nginx的配置文件Downward API：向下api 容器的底层是pod，此可以在容器内部拿到承载这个容器的这个pod的信息，可以拿到这个pod的名字，很方便ServiceAccountToken：

?token类似公钥和私钥，也是一段数据，就是一种secret做的凭据token

?kubectl describe secret default-token-dgchb

?要求能使用命令行创建secret 、和configmap

使用yaml文件创建sercret 和configmap

（编辑：南平站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!

管理数百个Kubernetes	混合云如何使混乱回
Kyndryl公布为宝马集团	中航云任涛打造跨境数