k8s-3_1集群资源总结
k8s-3_1集群资源总结
原文大佬文章，
1.K8S中的资源对象
Kubernetes的API对象大体可分为工作负载（Workload）、发现和负载均衡（Discovery& LB）、配置和存储（Config &Storage）、集群（Cluster）以及元数据（Metadata）五个类别。
一、工作负载型资源
Pod是工作负载型资源中的基础资源，它负责运行容器，并为其解决环境性的依赖。但Pod可能会因为资源超限或节点故障等原因而终止，这些非正常终止的Pod资源需要被重建，不过，这类工作将由工作负载型的控制器来完成，它们通常也称为pod控制器
pod控制器
1. ReplicationController：用于确保每个Pod副本在任一时刻均能满足目标数量，换言之，它用于保证每个容器或容器组总是运行并且可访问；它是上一代的无状态Pod应用控制器，现已被Deployment和ReplicaSet取代。
2. ReplicaSet：新一代ReplicationController，它与ReplicationController的唯一不同之处仅在于支持的标签选择器不同，ReplicationController只支持等值选择器，而ReplicaSet还额外支持基于集合的选择器。
3. Deployment：用于管理无状态的持久化应用，例如HTTP服务器；它用于为Pod和ReplicaSet提供声明式更新，是建构在ReplicaSet之上的更为高级的控制器。
4. StatefulSet：用于管理有状态的持久化应用，如database服务程序；其与Deployment的不同之处在于StatefulSet会为每个Pod创建一个独有的持久性标识符，并会确保各Pod之间的顺序性。
5. DaemonSet：用于确保每个节点都运行了某Pod的一个副本，新增的节点一样会被添加此类Pod；在节点移除时，此类Pod会被回收；DaemonSet常用于运行集群存储守护进程——如glusterd和ceph，还有日志收集进程——如fluentd和logstash，以及监控进程——如Prometheus的Node Exporter、collectd、Datadog agent和Ganglia的gmond等。
6. Job：用于管理运行完成后即可终止的应用，例如批处理作业任务；换句话讲，Job创建一个或多个Pod，并确保其符合目标数量，直到Pod正常结束而终止。
7. CronJob：用于管理Job控制器资源的运行时间。Job控制器定义的作业任务在其控制器资源创建之后便会立即执行，但CronJob可以以类似于Linux操作系统的周期性任务作业计划（crontab）的方式控制其运行的时间点及重复运行的方式
二、发现和负载均衡
Pod资源可能会因为任何意外故障而被重建，于是它需要固定的可被“发现”的方式。另外，Pod资源仅在集群内可见，它的客户端也可能是集群内的其他Pod资源，若要开放给外部网络中的用户访问，则需要事先将其暴露到集群外部，并且要为同一种工作负载的访问流量进行负载均衡。
1. Service：基于标签选择器将一组pod定义成一个逻辑组合，并通过自己的IP地址和端口调度代理请求至组内的对象上。并对客户端隐藏了真实的处理用户请求的pod资源。Service资源会通过API Service持续监视着标签选择器匹配到的后端pod对象，并实时跟踪个对象的变动；
2. Endpoint：存储在etcd中，用来记录一个service对应的所有pod的访问地址，创建Service资源对象时，其关联的Endpoint对象会自动创建。
3. Ingress：利用nginx，haproxy，envoy,traefik等负载均衡器来暴露集群内部服务，利用Ingress可以解决内部资源访问外部资源的方式，和四层调度替换为七层调度的问题。
三、配置与存储
Docker容器分层联合挂载的方式决定了不宜在容器内部存储需要持久化的数据，于是它通过引入挂载外部存储卷的方式来解决此类问题
1. Volume(存储卷)：本质上，Kubernetes Volume 是一个目录，当 Volume 被 mount 到Pod，Pod 中的所有容器都可以访问这个Volume。Kubernetes支持众多类型的存储设备或存储系统，如GlusterFS、CEPH、RBD和Flocker等。
2. CSI：容器存储接口,可以扩展各种各样的第三方存储卷)特殊类型的存储卷
3. ConfigMap：用于为容器中的应用提供配置数据以定制程序的行为
4. Secret：保存敏感数据，如敏感的配置信息，例如密钥、证书等
5. DownwardAPI：把外部环境中的信息输出给容器
四、集群级资源
用于定义集群自身配置信息的对象，它们仅应该由集群管理员进行操作
1. Namespace：资源对象名称的作用范围，绝大多数对象都隶属于某个名称空间，默认时隶属于“default”。
2. Node:Kubernetes集群的工作节点，其标识符在当前集群中必须是唯一的。
3. Role：名称空间级别的由规则组成的权限集合，可被RoleBinding引用。
4. ClusterRole:Cluster级别的由规则组成的权限集合，可被RoleBinding和ClusterRoleBinding引用。
5. RoleBinding：将Role中的许可权限绑定在一个或一组用户之上，它隶属于且仅能作用于一个名称空间；绑定时，可以引用同一名称空间中的Role，也可以引用全局名称空间中的ClusterRole。
6. ClusterRoleBinding：将ClusterRole中定义的许可权限绑定在一个或一组用户之上；它能够引用全局名称空间中的ClusterRole，并能通过Subject添加相关信息。
五、元数据型资源
用于为集群内部的其他资源配置其行为或特性
1. HPA：自动伸缩工作负载类型的资源对象的规模
2. PodTemplate：为pod资源的创建预制模板
3. LimitRange：为名称空间的资源设置其CPU和内存等系统级资源的数量限制等。
六、查看方式
kubectl api-resources --namespaced=true ##查看哪些资源在命令空间
kubectl api-resources --namespaced=false ##查看哪些资源不在命令空间
一、yuml文档格式
官方文档
https://k8syaml.com/
1. 注释
使用#作为注释，YAML中只有行注释。
2. 基本格式要求
- YAML大小写敏感；
- 使用缩进代表层级关系；
- 缩进只能使用空格，不能使用TAB，不要求空格个数，只需要相同层级左对齐（一般2个或4个空格）
3. YAML支持的数据结构
- 对象：键值对集合，又称为映射、哈希、字典
- 数组：一组按照次序排列的值，又称为序列、列表
- 纯量：单个、不可再分的值
4. k8s yaml 文件中字段类型
- 对象类型
metadata：
name：
namespace:
- <[]Object> 对象列表类型
containers:
- name: name1
images:
- name: name2
images:
● <string> 字符串类型
namespace: default
● <integer> 整型
replica: 3
● <boolean> 布尔类型 true or false
hostIPC: false
● <map[string]string>字符串嵌套
nodeSelector:
label: lablename
● <[]> 列表类型
写法1：
command:
- "string1"
- "string2"
写法二：
command: ["string1","string2","string3"]
二、必要字段
1. 模板
apiVersion: v1
kind: Namespace
metadata:
name: dev
spec:
finalizers:
- kubernetes
2. 字段说明
| 字段 | 类型 | 说明 |
|---|---|---|
| apiVersion | string | k8s API版本，可以使用kubectl api-versions查询 |
| kind | string | yaml文件定义的资源类型和角色，有Pod、Deployment、Endpoints、Service |
| metadata | object | 元数据对象 |
| spec | object | 详细定义对象，用来描述所期望的对象应该具有的状态 |
三、metadata字段
| 字段 | 类型 | 说明 |
|---|---|---|
| namespace | string | 指定当前对象隶属的名称空间，默认值为default。 |
| name： | string | 设定当前对象的名称，在其所属的名称空间的同一类型中必须唯一。 |
| labels： | string | 用于标识当前对象的标签，键值数据，常被用作挑选条件。 |
四、spec字段
1. spec.containers[]：spec对象的容器列表定义
| spec.containers[].name | string | 定义容器的名字 |
|---|---|---|
| spec.containers[].image | string | 定义用到的镜像名称 |
| spec.containers[].imagePullPolicy | string | 定义镜像拉取策略 always：默认，每次都hub拉取 never：仅使用本机镜像 ifnotprestnt：本机没有就hub拉取 |
| spec.containers[].command[] | list | 指定一个或多个容器启动命令 |
| spec.containers[].args[] | list | 指定容器启动命令参数，Dockerfile中CMD参数 |
| spec.containers[].workingDir | string | 指定容器工作目录 |
2. spec.containers[].volumeMounts[]：指定容器内部的存储卷配置
| spec.containers[].volumeMounts[].name | string | 容器挂载的存储卷名称 |
|---|---|---|
| spec.containers[].volumeMounts[].mountPath | string | 容器挂载的存储卷路径 |
| spec.containers[].volumeMounts[].readOnly | string | 存储卷读写模式，ture或false， 默认为读写模式 |
3. spec.containers[].ports[]：指定容器端口列表
| spec.containers[].ports[].name | string | 指定端口名称 |
|---|---|---|
| spec.containers[].ports[].containerPort | string | 指定容器监听的端口号 |
| spec.containers[].ports[].hostPort | string | 指定容器所在主机监听的端口号，设置了hostPort后同一台主机无法启动相同副本 |
| spec.containers[].ports[].protocol | string | 指定端口协议，默认为TCP |
4. spec.containers[].env[]：指定容器运行前环境变量
| spec.containers[].env[].name | string | 指定环境变量名称 |
|---|---|---|
| spec.containers[].env[].value | string | 指定环境变量值 |
5. spec.containers[].resources.limits：指定容器运行时资源的上限
| spec.containers[].resources.limits.cpu | string | 指定cpu限制，单位为core数 |
|---|---|---|
| spec.containers[].resources.limits.memory | string | 指定内存限制，单位为MIB，GIB |
6. spec.containers[].resources.requests：指定容器启动和调度时资源的上限
| spec.containers[].resources.requests.cpu | string | 指定cpu限制，单位为core数 |
|---|---|---|
| spec.containers[].resources.requests.memory | string | 指定内存限制，单位为MIB，GIB |
7. 探针
| spec.containers[].livenessProbe | object | 存活检测 |
|---|---|---|
| spec.containers[].ReadinessProbe | object | 就绪检测 |
| spec.containers[].检测方式.initialDelaySeconds | Int | 初始化延迟的时间，监测从多久之后开始运行，单位是秒 |
| spec.containers[].检测方式.timeoutSeconds | Int | 监测的超时时间，如果超过这个时长后，则认为监测失败 |
| spec.containers[].检测方式.periodSeconds | int | 存活性探测的频度，显示为period属性，默认为10s，最小值为1 |
| spec.containers[].检测方式.successThreshold | int | 处于失败状态时，探测操作至少连续多少次的成功才被认为是通过检测，显示为#success属性，默认值为1，最小值也为1。 |
| spec.containers[].检测方式.failureThreshold： | int | 处于成功状态时，探测操作至少连续多少次的失败才被视为是检测不通过，显示为#failure属性，默认值为3，最小值为1。 |
8. exec检测
| spec.containers[].检测方式.exec | Object | exec方式执行命令检测 |
|---|---|---|
| spec.containers[].检测方式.exec.command | List | 执行的检测命令依据 |
9. httpGet检测
| spec.containers[].检测方式.httpGet | Object | http探针，依据状态码 |
|---|---|---|
| spec.containers[].检测方式.httpGet.host | string | 请求的主机地址，默认为Pod IP； |
| spec.containers[].检测方式.httpGet.port | string | 请求的端口，必选字段。 |
| spec.containers[].检测方式.httpGet.httpHeaders | Object | 自定义的请求报文首部 |
| spec.containers[].检测方式.httpGet.path | string | 请求的HTTP资源路径，即URL |
| spec.containers[].检测方式.httpGet.scheme | string | 建立连接使用的协议，仅可为HTTP或HTTPS，默认为HTTP。 |
10. tcpSocket检测
| spec.containers[].检测方式.tcpSocket | Object | tcpSocket检测，依据端口是否开放 |
|---|---|---|
| spec.containers[].检测方式.tcpSocket.host | string | 请求连接的目标IP地址，默认为Pod IP。 |
| spec.containers[].检测方式.tcpSocket.port | string | 请求连接的目标端口，必选字段。 |
11. 其他spec
| spec.restartPolicy | string | 定义Pod重启策略 always：pod一旦终止就重启 onfailure：pod只有以非零退出码终止时（正常结束退出码为0），才会重启 never：pod终止后，不会重启 |
|---|---|---|
| spec.nodeSelector | object | 定义node的label过滤标签，以key:value指定 |
| spec.imagePullSecrets | object | 定义pull镜像时，使用secret名称，以key:value指定 |
| spec.hostNetwork | Boolean | 定义是否使用主机网络模式，默认使用docker网桥，如果设置true无法启动相同副本 |
五、控制器字段
1. ReplicaSet
| spec.replicas | integer | 期望的Pod对象副本数 |
|---|---|---|
| spec.selector | Object | 当前控制器匹配Pod对象副本的标签选择器 |
| spec.selector.matchLabels | string | matchLabels标签选择器 |
| spec.selector.matchExpressions | string | matchExpressions标签选择器 |
| spec.template | Object | 用于补足Pod副本数量时使用的Pod模板资源 |
2. Deployment
| spec.strategy.rollingUpdate. maxSurge | integer/percent | 升级期间存在的总Pod对象数量最多可超出期望值的个数，其值可以是0或正整数，也可以是一个期望值的百分比 |
|---|---|---|
| spec.strategy.rollingUpdate.maxUnavailable | integer/percent | 升级期间正常可用的Pod副本数（包括新旧版本）最多不能低于期望数值的个数，其值可以是0或正整数，也可以是一个期望值的百分比 |
| spec.revisionHistoryLimit | integer | 控制器可保存的历史版本数量 |
| spec.minReadySeconds | integer | 新建的Pod对象，在启动后的多长时间内如果其容器未发生崩溃等异常情况即被视为“就绪”；默认为0秒，表示一旦就绪性探测成功，即被视作可用 |
3. DaemonSet控制器
●.spec.selector 是必填字段，且指定该字段时，必须与.spec.template.metata.labels 字段匹配（不匹配的情况下创建 DaemonSet将失败）。DaemonSet 创建以后，.spec.selector字段就不可再修改。如果修改，可能导致不可预见的结果。
4. Job控制器
●Pod模板中的spec.restartPolicy默认为“Always”，这对Job控制器来说并不适用，因此必须在Pod模板中显式设定restartPolicy属性的值为“Never”或“OnFailure”。
| .spec.parallelism | integer | 能够定义作业执行的并行度，将其设置为2或者以上的值即可实现并行多队列作业同时运行 |
|---|---|---|
| spec.completions | integer | 使用的是默认值1，则表示并行度即作业总数 |
●将.spec.completions属性值设置为大于.spec.parallelism的属性值，则表示使用多队列串行任务作业模式
| .spec.activeDeadlineSeconds | integer | Job的deadline，用于为其指定最大活动时间长度，超出此时长的作业将被终止。 |
|---|---|---|
| .spec.backoffLimit | integer | 将作业标记为失败状态之前的重试次数，默认值为6。 |
5. CronJob控制器
| jobTemplate | Object | Job控制器模板，用于为CronJob控制器生成Job对象；必选字段 |
|---|---|---|
| schedule | string | Cron格式的作业调度运行时间点；必选字段。 |
| concurrencyPolicy | string | 并发执行策略，可用值有“Allow”（允许）、“Forbid”（禁止）和“Replace”（替换），用于定义前一次作业运行尚未完成时是否以及如何运行后一次的作业 |
| failedJobHistoryLimit | integer | 为失败的任务执行保留的历史记录数，默认为1。 |
| successfulJobsHistoryLimit | integer | 为成功的任务执行保留的历史记录数，默认为3 |
| startingDeadlineSeconds | integer | 因各种原因缺乏执行作业的时间点所导致的启动作业错误的超时时长，会被记入错误历史记录 |
| suspend | boolean | 是否挂起后续的任务执行，默认为false，对运行中的作业不会产生影响。 |
| .spec.successfulJobsHistoryLimit | integer | 保留多少完成的 Job。默认没有限制，所有成功和失败的 Job 都会被保留。 当运行一个 Cron Job 时，Job 可以很快就堆积很多，推荐设置这两个字段的值。设置限制的值为 0，相关类型的 Job 完成后将不会被保留。 |
| .spec.failedJobsHistoryLimit | integer | 保留多少失败的 Job |
| .spec.concurrencyPolicy | Allow/Forbid/Replace | 属性控制作业并存的机制，其默认值为“Allow”，即允许前后Job，甚至属于同一个CronJob的更多Job同时运行。 “Forbid”用于禁止前后两个Job同时运行，如果前一个尚未结束，后一个则不予启动（跳过）， “Replace”用于让后一个Job取代前一个，即终止前一个并启动后一个。 |
6. PDB
| .spec.selector | Object | 当前PDB对象使用的标签选择器，一般是与相关的Pod控制器使用同一个选择器。 |
|---|---|---|
| .spec.minAvailable | string | Pod自愿中断的场景中，至少要保证可用的Pod对象数量或比例，要阻止任何Pod对象发生自愿中断，可将其设置为100% |
| .spec.maxUnavailable | string | Pod自愿中断的场景中，最多可转换为不可用状态的Pod对象数量或比例，0值意味着不允许Pod对象进行自愿中断；此字段与minAvailable互斥 |
六、service
| .spec.selector: | Object | 当前svc使用的标签选择器，用来管理pod中一样的标签资源。 |
|---|---|---|
| .spec.type | string | service类型 |
| .spec.clusterIP | string | 虚拟服务IP地址 |
| .spec.ExternalName | string | ExternalName模式域名 |
| .spec.sessionAffinity | string | 是否支持session会话绑定 |
| .spec.ports.name | string | 端口名称 |
| .spec.ports.protocol | string | 端口协议，默认tcp |
| .spec.ports.port | integer | 服务监听端口号 |
| .spec.ports.targetPort | integer | 转发到后端的服务端口号 |
| .spec.ports.nodePort | integer | nodeport模式绑定物理主机端口 |
七、ingress
| .spec.rules | Object | 用于定义当前Ingress资源的转发规则列表 |
|---|---|---|
| .spec.rules.host | string | 指定访问地址，留空表示通配所有的主机名 |
| .spec.backend | Object | 为负载均衡器指定一个全局默认的后端 |
| .spec.backend.serviceName | string | 流量转发的后端目标Service资源的名称 |
| .spec.backend.servicePort | integer | 流量转发的后端目标Service资源的端口 |
| .spec.tls | Object | TLS配置，目前仅支持通过默认端口443提供服务 |
| .spec.tls.hosts | string | 使用的TLS证书之内的主机名称，此处使用的主机名必须匹配tlsSecret中的名称。 |
| .spec.tls.secretName | string | SSL会话的secret对象名称，在基于SNI实现多主机路由的场景中，此字段为可选。 |
八、存储
-
configmap
| .spec.volumes.configMap.items.key | string | 要引用的键名称，必选字段 |
|---|---|---|
| .spec.volumes.configMap.items.path | string | 对应的键于挂载点目录中生成的文件的相对路径，可以不同于键名称，必选字段 |
| .spec.volumes.configMap.items.mode | integer | 文件的权限模型，可用范围为0到0777。 |
管理Namespace资源
一、简介
1. 名称空间（Namespace）是Kubernetes集群级别的资源，用于将集群分隔为多个隔离的逻辑分区以配置给不同的用户、租户、环境或项目使用，例如，可以为development、qa和production应用环境分别创建各自的名称空间。
2. Kubernetes的绝大多数资源都隶属于名称空间级别（另一个是全局级别或集群级别），名称空间资源为这类的资源名称提供了隔离的作用域，同一名称空间内的同一类型资源名必须是唯一的，但跨名称空间时并无此限制。不过，Kubernetes还是有一些资源隶属于集群级别的，如Node、Namespace和PersistentVolume等资源，它们不属于任何名称空间，因此资源对象的名称必须全局唯一
二、Namespaces 的常用操作
-
查看命名空间
`# kubectl get namespaces ` -
Kubernetes默认有三个命名空间
- default:默认的命名空间
- kube-system:由Kubernetes系统对象组成的命名空间
- kube-public:该空间由系统自动创建并且对所有用户可读性，做为集群公用资源的保留命名空间
-
查看特定名称空间的详细信息
`# kubectl describe namespaces default ` -
创建命名空间
`# kubectl create namespace test-cluster ` -
查询命名空间中的资源
`# kubectl get all --namespace=test-cluster ` `# kubectl get all -n test-clutser ` `# kubectl get nodes ` `# kubectl get pods -n kube-system ` -
修改默认的namespace配置
`# kubectl config view`
-
先查看是否设置了current-context
`# kubectl config set-context default --namespace=bs-test` -
设置default配置的namespace参数
# kubectl config set current-context default//设置当前环境变量为 default -
通过这段代码设置默认的命名空间后，就不用每次在输入命令的时候带上–namespace参数了。
三、其他操作
-
查看命名空间中的资源。
`# kubectl api-resources --namespaced=true ` -
查看不在命名空间中的资源
`# kubectl api-resources --namespaced=false `
标签与标签选择器
一、标签概述
1. 标签就是“键值”类型的数据，它们可于资源创建时直接指定，也可随时按需添加于活动对象中，而后即可由标签选择器进行匹配度检查从而完成资源挑选。一个对象可拥有不止一个标签，而同一个标签也可被添加至多个资源之上。
2. 为资源附加多个不同纬度的标签以实现灵活的资源分组管理功能，例如，版本标签、环境标签、分层架构标签等，用于交叉标识同一个资源所属的不同版本、环境及架构层级等
二、管理标签资源
- 创建资源时，可直接在其metadata中嵌套使用“labels”字段以定义要附加的标签项。
-
在“kubectl get pods”命令中使用“–show-labels”选项，以额外显示对象的标签信息：
$ kubectl get pods --show-labels
-
按需进行添加标签操作。
$ kubectl label pods/pod-with-labels version=v1
-
对于已经附带了指定键名的标签，使用“–overwrite”命令以强制覆盖原有的键值
$ kubectl label pods/pod-with-labels version=v2 --overwrite
-
删除指定键名的标签，使用“标签名-”，即可删除
三、标签选择器
1. Kubernetes API目前支持两个选择器：基于等值关系（equality-based）以及基于集合关系（set-based）。
2. 基于等值关系的标签选择器的可用操作符有“=”“==”和“!=”三种，其中前两个意义相同，都表示“等值”关系，最后一个表示“不等”关系
3. “kubectl get”命令的“-l”选项能够指定使用标签选择器，例如，显示键名env的值不为qa的所有Pod对象：
$ kubectl get pods -l "env! =qa" -L env
4. 基于集合关系的标签选择器，它们的使用格式及意义具体如下。
● KEY in (VALUE1, VALUE2, …)：指定的键名的值存在于给定的列表中即满足条件。
● KEY notin (VALUE1, VALUE2, …)：指定的键名的值不存在于给定的列表中即满足条件。
● KEY：所有存在此键名标签的资源。
● ! KEY：所有不存在此键名标签的资源。
例如，显示标签键名env的值为production或dev的所有Pod对象：
$ kubectl get pods -l "env in (production, dev)" -L env
5. Kubernetes的诸多资源对象必须以标签选择器的方式关联到Pod资源对象，例如Service、Deployment和ReplicaSet类型的资源等，它们在spec字段中嵌套使用嵌套的“selector”字段，通过“matchLabels”来指定标签选择器，有的甚至还支持使用“matchExpressions”构造复杂的标签选择机制。
● matchLabels：通过直接给定键值对来指定标签选择器。
● matchExpressions：基于表达式指定的标签选择器列表，每个选择器都形如“{key:KEY_NAME,operator: OPERATOR, values: [VALUE1, VALUE2,…]}”，选择器列表间为“逻辑与”关系；使用In或NotIn操作符时，其values不强制要求为非空的字符串列表，而使用Exists或DostNotExist时，其values必须为空。
四、Pod节点选择器nodeSelector
1. Pod节点选择器是标签及标签选择器的一种应用，它能够让Pod对象基于集群中工作节点的标签来挑选倾向运行的目标节点。
2. Pod对象的spec.nodeSelector可用于定义节点标签选择器，用户事先为特定部分的Node资源对象设定好标签，而后配置Pod对象通过节点标签选择器进行匹配检测，从而完成节点亲和性调度。
3. 为Node资源对象附加标签的方法同Pod资源，使用“kubectl label nodes/NODE”命令即可。
● 例如，可为node2节点设置“disktype=ssd”标签以标识其拥有SSD设备：
$ kubectl label nodes node2 disktype=ssd
● 查看具有键名SSD的标签的Node资源：
$ kubectl get nodes -l 'disktype' -L disktype
- 如果某Pod资源需要调度至这些具有SSD设备的节点之上，那么只需要为其使用spec.nodeSelector标签选择器即可，例如下面的资源清单文件pod-with-nodeselector.yaml示例：
apiVersion: v1
kind: Pod
metadata:
name: pod-with-nodeselector
labels:
env: testing
spec:
containers:
- name: myapp
image: busybox
nodeSelector:
disktype: ssd
Pod资源对象
一、Pod概念的产生
1. 在一个真正的操作系统里，进程并不是“孤苦伶仃”地独自运行的，而是以进程组的方式，“有原则地”组织在一起。
2. 而Kubernetes项目所做的，其实就是将“进程组”的概念映射到了容器技术中，并使其成为了这个云计算“操作系统”里的“一等公民”。
3. 分别运行于各自容器的进程之间无法实现基于IPC的通信机制，此时，容器间的隔离机制对于依赖于此类通信方式的进程来说却又成了阻碍。Pod资源抽象正是用来解决此类问题
二、Pod特点
在 Kubernetes项目里， Pod的实现需要使用一个中间容器，这个容器叫作Infra容器。在这个 Pod中，Infra容器永远都是第一个被创建的容器，而其他用户定义的容器，则通过 Join Network Namespace的方式，与 Infra容器关联在一起。
2. 对于 Pod 里的容器 A 和容器 B 来说：
● 它们可以直接使用 localhost 进行通信；
● 它们看到的网络设备跟 Infra 容器看到的完全一样；
● 一个 Pod 只有一个 IP 地址，也就是这个 Pod 的 Network Namespace 对应的 IP地址；
● 其他的所有网络资源，都是一个 Pod 一份，并且被该 Pod 中的所有容器共享；
● Pod 的生命周期只跟 Infra 容器一致，而与容器 A 和 B 无关。
3. 把整个虚拟机想象成为一个
Pod，把这些进程分别做成容器镜像，把有顺序关系的容器，定义为 Init Container。这才是更加合理的、松耦合的容器编排诀窍，也是从传统应用架构，到“微服务架构”最自然的过渡方式。
三、Pod模型
1. Sidecar
pattern（边车模型或跨斗模型）：即为Pod的主应用容器提供协同的辅助应用容器，每个应用独立运行
● 最为典型的代表是将主应用容器中的日志使用agent收集至日志服务器中时，可以将agent运行为辅助应用容器，即sidecar。另一个典型的应用是为主应用容器中的database server启用本地缓存。
2. Ambassador
pattern（大使模型）：即为远程服务创建一个本地代理，代理应用运行于容器中，主容器中的应用通过代理容器访问远程服务
● 一个典型的使用示例是主应用容器中的进程访问“一主多从”模型的远程Redis应用时，可在当前Pod容器中为Redis服务创建一个Ambassador container，主应用容器中的进程直接通过localhost接口访问Ambassador container即可。即便是Redis主从集群架构发生变动时，也仅需要将Ambassador container加以修改即可，主应用容器无须对此做出任何反应。
3. Adapter
pattern（适配器模型）：此种模型一般用于将主应用容器中的内容进行标准化输出，
● 例如，日志数据或指标数据的输出，这有助于调用者统一接收数据的接口，另外，某应用滚动升级后的版本不兼容旧的版本时，其报告信息的格式也存在不兼容的可能性，使用Adapter
container有助于避免那些调用此报告数据的应用发生错误。
Kubernetes系统的Pod资源对象用于运行单个容器化应用，此应用称为Pod对象的主容器（main container），同时Pod也能容纳多个容器，不过额外的容器一般工作为Sidecar模型，用于辅助主容器完成工作职能。
四、yaml文件Pod与Container对象
1. 基本原则
● 凡是调度、网络、存储，以及安全相关的属性，基本上是 Pod 级别的，凡是跟容器的Linux Namespace 相关的属性，也一定是 Pod 级别的，凡是 Pod中的容器要共享宿主机的 Namespace，也一定是 Pod 级别的定义
2. 应用举例
● NodeSelector：供用户将 Pod 与 Node 进行绑定
● HostAliases：定义了 Pod 的 hosts 文件（比如 /etc/hosts）里的内容
● shareProcessNamespace=true：这个 Pod 里的容器要共享 PID Namespace
7.Pod生命周期
一、Pod相位
1. Pod 生命周期的变化，主要体现在 Pod API 对象的 Status 部分，这是它除了Metadata 和 Spec 之外的第三个重要字段。其中，pod.status.phase，就是 Pod的当前状态，它有如下几种可能的情况：
● Pending。这个状态意味着，Pod 的 YAML 文件已经提交给了 Kubernetes，API 对象已经被创建并保存在 Etcd 当中。但是，这个 Pod里有些容器因为某种原因而不能被顺利创建。比如，调度不成功。
● Running。这个状态下，Pod已经调度成功，跟一个具体的节点绑定。它包含的容器都已经创建成功，并且至少有一个正在运行中。
● Succeeded。这个状态意味着，Pod里的所有容器都正常运行完毕，并且已经退出了。这种情况在运行一次性任务时最为常见。
● Failed。这个状态下，Pod 里至少有一个容器以不正常的状态（非 0的返回码）退出。这个状态的出现，意味着你得想办法 Debug这个容器的应用，比如查看 Pod 的 Events 和日志。
● Unknown。这是一个异常状态，意味着 Pod 的状态不能持续地被 kubelet 汇报给kube-apiserver，这很有可能是主从节点（Master 和Kubelet）间的通信出现了问题。
二、Pod创建过程
1. 用户通过kubectl或其他API客户端提交Pod Spec给API Server。
2. API Server尝试着将Pod对象的相关信息存入etcd中，待写入操作执行完成，API Server即会返回确认信息至客户端。
3. API Server开始反映etcd中的状态变化。
4. 所有的Kubernetes组件均使用“watch”机制来跟踪检查API Server上的相关的变动。
5. kube-scheduler（调度器）通过其“watcher”觉察到API Server创建了新的Pod对象但尚未绑定至任何工作节点。
6. kube-scheduler为Pod对象挑选一个工作节点并将结果信息更新至API Server。
7. 调度结果信息由API Server更新至etcd存储系统，而且API Server也开始反映此Pod对象的调度结果。
8. Pod被调度到的目标工作节点上的kubelet尝试在当前节点上调用Docker启动容器，并将容器的结果状态回送至API Server。
9. API Server将Pod状态信息存入etcd系统中。
10. 在etcd确认写入操作成功完成后，API Server将确认信息
三、Pod生命周期中行为
四、初始化容器
1. 初始化容器（init container）即应用程序的主容器启动之前要运行的容器，常用于为主容器执行一些预置操作，它们具有两种典型特征。
● 初始化容器必须运行完成直至结束，若某初始化容器运行失败，那么Kubernetes需要重启它直到成功完成。
● 每个init容器都必须在下一个init容器启动之前成功完成
2. 初始化容器作用
● 包含并运行实用工具，但是出于安全考虑，是不建议在应用程序容器镜像中包含这些实用工具的
● 包含使用工具和定制化代码来安装，但是不能出现在应用程序镜像中。例如，创建镜像没必要FROM另一个镜像，只需要在安装过程中使用类似sed、awk、python或dig这样的工具。
● 应用程序镜像可以分离出创建和部署的角色，而没有必要联合它们构建一个单独的镜像。
● Init容器使用LinuxNamespace，所以相对应用程序容器来说具有不同的文件系统视图。因此，它们能够具有访问Secret的权限，而应用程序容器则不能。
● 它们必须在应用程序容器启动之前运行完成，而应用程序容器是并行运行的，所以Init容器能够提供了一种简单的阻塞或延迟应用容器的启动的方法，直到满足了一组先决条件。
3. 特殊说明
● 在Pod启动过程中，Init容器会按顺序在网络和数据卷初始化之后启动。每个容器必须在下一个容器启动之前成功退出
● 如果由于运行时或失败退出，将导致容器启动失败，它会根据Pod的restartPolicy指定的策略进行重试。然而，如果Pod的restartPolicy设置为Always，Init容器失败时会使用RestartPolicy策略
● 在所有的Init容器没有成功之前，Pod将不会变成Ready状态。Init容器的端口将不会在Service中进行聚集。正在初始化中的Pod处于Pending状态，但应该会将Initializing状态设置为true
● 如果Pod重启，所有Init容器必须重新执行
● 对Init容器spec的修改被限制在容器image字段，修改其他字段都不会生效。更改Init容器的image字段，等价于重启该Pod
● Init容器具有应用容器的所有字段。除了readinessProbe，因为Init容器无法定义不同于完成（completion）的就绪（readiness）之外的其他状态。这会在验证过程中强制执行
● 在Pod中的每个app和Init容器的名称必须唯一；与任何其它容器共享同一个名称，会在验证时抛出错误
五、生命周期钩子函数
1. 容器生命周期钩子使它能够感知其自身生命周期管理中的事件，并在相应的时刻到来时运行由用户指定的处理程序代码。Kubernetes为容器提供了两种生命周期钩子。
● postStart：于容器创建完成之后立即运行的钩子处理器（handler）
● preStop：于容器终止操作之前立即运行的钩子处理器，它以同步的方式调用，因此在其完成之前会阻塞删除容器的操作的调用。
2. 钩子处理器的实现方式有“Exec”和“HTTP”两种，
● exec：执行一段命令
● HTTP：发送HTTP请求
六、容器探测
1. kubelet对容器周期性执行的健康状态诊断，诊断操作由容器的处理器（handler）进行定义。Kubernetes支持三种处理器用于Pod探测。
● ExecAction：在容器中执行一个命令，并根据其返回的状态码进行诊断的操作称为Exec探测，状态码为0表示成功，否则即为不健康状态。
● TCPSocketAction：通过与容器的某TCP端口尝试建立连接进行诊断，端口能够成功打开即为正常，否则为不健康状态。
● HTTPGetAction：通过向容器IP地址的某指定端口的指定path发起HTTP GET请求进行诊断，响应码为2xx或3xx时即为成功，否则为失败。
2. 每次探测都将获得以下三种结果之一：
● 成功：容器通过了诊断。
● 失败：容器未通过诊断。
● 未知：诊断失败，因此不会采取任何行动
七、容器的重启策略
1. 容器程序发生崩溃或容器申请超出限制的资源等原因都可能会导致Pod对象的终止，此时是否应该重建该Pod对象则取决于其重启策略（restartPolicy）属性的定义。
● Always：但凡Pod对象终止就将其重启，此为默认设定。
● OnFailure：仅在Pod对象出现错误时方才将其重启。
● Never：从不重启。
2. 需要注意的是，restartPolicy适用于Pod对象中的所有容器，而且它仅用于控制在同一节点上重新启动Pod对象的相关容器。首次需要重启的容器，将在其需要时立即进行重启，随后再次需要重启的操作将由kubelet延迟一段时间后进行，且反复的重启操作的延迟时长依次为10秒、20秒、40秒、80秒、160秒和300秒，300秒是最大延迟时长。事实上，一旦绑定到一个节点，Pod对象将永远不会被重新绑定到另一个节点，它要么被重启，要么终止，直到节点发生故障或被删除。
八、存活性检测
1. 用于判定容器是否处于“运行”（Running）状态；一旦此类检测未通过，kubelet将杀死容器并根据其restartPolicy决定是否将其重启；未定义存活性检测的容器的默认状态为“Success”。
2. 设置exec探针：通过在目标容器中执行由用户自定义的命令来判定容器的健康状态，若命令状态返回值为0则表示“成功”通过检测，其值均为“失败”状态。
● 示例：使用busybox镜像创建/tem/headthy文件，1分钟后删除。如果文件存在，检测通过，否则为失败
● 定义liveness-exec.yaml文件
- 在60秒之内使用“kubectl describe pods/liveness-exec”查看其详细信息，其存活性探测不会出现错误。而超过60秒之后，再次运行“kubectl describe pods/liveness-exec”查看其详细信息可以发现，存活性探测出现了故障
- 待容器重启完成后再次查看，容器已经处于正常运行状态，直到文件再次被删除，存活性探测失败而重启。从下面的命令显示可以看出，liveness-exec已然重启
3. 设置HTTP探针
基于HTTP的探测（HTTPGetAction）向目标容器发起一个HTTP请求，根据其响应码进行结果判定。“spec.containers.livenessProbe.httpGet”字段用于定义此类检测，它的可用配置字段包括如下几个。
● host <string>：请求的主机地址，默认为Pod IP
● port <string>：请求的端口，必选字段。
● httpHeaders <[]Object>：自定义的请求报文首部。
● path <string>：请求的HTTP资源路径，即URL path。
● scheme：建立连接使用的协议，仅可为HTTP或HTTPS，默认为HTTP。
● 示例：通过nginx生成一个index.html页面文件，请求的资源路径为“/index.html”，地址默认为Pod
IP，端口使用了容器中定义的端口名称HTTP，然后删除文件，再次查看pod信息
● 定义liveness-http.yaml文件
- 而后查看其健康状态检测相关的信息，健康状态检测正常时，容器也将正常运行：
- 接下来借助于“kubectl exec”命令删除index.html测试页面：
$ kubectl exec liveness-httpget rm /usr/share/nginx/html/index.html - 而后再次使用“kubectl describe pod/liveness-httpget”查看其详细的状态信息
4. 设置TCP探针
向容器的特定端口发起TCP请求并尝试建立连接进行结果判定，连接建立成功即为通过检测。“spec.containers.livenessProbe.tcpSocket”字段用于定义此类检测，它主要包含以下两个可用的属性。
● host <string>：请求连接的目标IP地址，默认为Pod IP。
● port <string>：请求连接的目标端口，必选字段。
● 下面是一个定义在资源清单文件liveness-tcp.yaml中的示例，它向Pod IP的80/tcp端口发起连接请求，并根据连接建立的状态判定测试结果：
九、就绪性检测
1. 用于判断容器是否准备就绪并可对外提供服务；未通过检测的容器意味着其尚未准备就绪，端点控制器（如Service对象）会将其IP从所有匹配到此Pod对象的Service对象的端点列表中移除；检测通过之后，会再次将其IP添加至端点列表中。
2. 与存活性探测机制相同，就绪性探测也支持Exec、HTTP GET和TCP Socket三种探测方式。
3. 与存活性探测触发的操作不同的是，探测失败时，就绪性探测不会杀死或重启容器以保证其健康性，而是通知其尚未就绪，并触发依赖于其就绪状态的操作（例如，从Service对象中移除此Pod对象）以确保不会有客户端请求接入此Pod对象。
8.资源需求与限制
一、资源
1. CPU：1个单位的CPU相当于虚拟机上的1颗虚拟CPU（vCPU）或物理机上的一个超线程（Hyperthread，或称为一个逻辑CPU），它支持分数计量方式，一个核心（1core）相当于1000个微核心（millicores），因此500m相当于是0.5个核心，即二分之一个核心。
2. 内存的计量方式与日常使用方式相同，默认单位是字节，也可以使用E、P、T、G、M和K作为单位后缀，或Ei、Pi、Ti、Gi、Mi和Ki形式的单位后缀。
二、资源需求
1. “requests”属性定义其请求的确保可用值，即容器运行可能用不到这些额度的资源，但用到时必须要确保有如此多的资源可用
2. 示例
● 定义一个Pod中stress容器，确保128Mi的内存及五分之一个CPU核心（200m）资源可用，
● 它运行stress-ng镜像启动一个进程（-m 1）进行内存性能压力测试，满载测试时它也会尽可能多地占用CPU资源
● 另外再启动一个专用的CPU压力测试进程（-c 1）。v
- 查看资源使用情况
- 每个测试进程CPU占用率为25%，内存占用为262m，此两项资源占用量都远超其请求的用量，原因是stress-ng会在可用的范围内尽量多地占用相关的资源
三、资源限制
1. ”limits”属性则用于限制资源可用的最大值，即硬限制
2. 示例：一个Pod对象，它模拟内存泄漏操作不断地申请使用内存资源，直到超出limits属性中memory字段设定的值而导致“OOMKillled”为止：
Pod资源的默认重启策略为Always，于是在memleak因内存资源达到硬限制而被终止后会立即重启。不过，多次重复地因为内存资源耗尽而重启会触发Kubernetes系统的重启延迟机制，即每次重启的时间间隔会不断地拉长。于是，用户看到的Pod资源的相关状态通常为“CrashLoopBackOff”：
9.Pod服务质量（优先级）
1. Kubernetes允许节点资源对limits的过载使用，当节点无法同时满足其上的所有Pod对象以资源满载的方式运行。
2. 在内存资源紧缺时，通过Pod对象的优先级完成先后终止哪些Pod对象判定。根据Pod对象的requests和limits属性，Kubernetes将Pod对象归类到BestEffort、Burstable和Guaranteed三个服务质量（Quality of Service, QoS）类别下，具体说明如下。
3. Guaranteed：每个容器都为CPU资源设置了具有相同值的requests和limits属性，以及每个容器都为内存资源设置了具有相同值的requests和limits属性的Pod资源会自动归属于此类别，这类Pod资源具有最高优先级。
4. Burstable：至少有一个容器设置了CPU或内存资源的requests属性，但不满足Guaranteed类别要求的Pod资源将自动归属于此类别，它们具有中等优先级。
5. BestEffort：未为任何一个容器设置requests或limits属性的Pod资源将自动归属于此类别，它们的优先级为最低级别。
6. 内存资源紧缺时，BestEffort类别的容器将首当其冲地被终止，因为系统不为其提供任何级别的资源保证，但换来的好处是，它们能够在可用时做到尽可能多地占用资源。若已然不存任何BestEffort类别的容器，则接下来是有着中等优先级的Burstable类别的Pod被终止。Guaranteed类别的容器拥有最高优先级，它们不会被杀死，除非其内存资源需求超限，或者OOM时没有其他更低优先级的Pod资源存在。
ernetes系统的重启延迟机制，即每次重启的时间间隔会不断地拉长。于是，用户看到的Pod资源的相关状态通常为“CrashLoopBackOff”：
[外链图片转存中...(img-jwiVY7AD-1660039144415)]
# 9.Pod服务质量（优先级）
```shell
1. Kubernetes允许节点资源对limits的过载使用，当节点无法同时满足其上的所有Pod对象以资源满载的方式运行。
2. 在内存资源紧缺时，通过Pod对象的优先级完成先后终止哪些Pod对象判定。根据Pod对象的requests和limits属性，Kubernetes将Pod对象归类到BestEffort、Burstable和Guaranteed三个服务质量（Quality of Service, QoS）类别下，具体说明如下。
3. Guaranteed：每个容器都为CPU资源设置了具有相同值的requests和limits属性，以及每个容器都为内存资源设置了具有相同值的requests和limits属性的Pod资源会自动归属于此类别，这类Pod资源具有最高优先级。
4. Burstable：至少有一个容器设置了CPU或内存资源的requests属性，但不满足Guaranteed类别要求的Pod资源将自动归属于此类别，它们具有中等优先级。
5. BestEffort：未为任何一个容器设置requests或limits属性的Pod资源将自动归属于此类别，它们的优先级为最低级别。
6. 内存资源紧缺时，BestEffort类别的容器将首当其冲地被终止，因为系统不为其提供任何级别的资源保证，但换来的好处是，它们能够在可用时做到尽可能多地占用资源。若已然不存任何BestEffort类别的容器，则接下来是有着中等优先级的Burstable类别的Pod被终止。Guaranteed类别的容器拥有最高优先级，它们不会被杀死，除非其内存资源需求超限，或者OOM时没有其他更低优先级的Pod资源存在。