Pod

Pod 是容器的外壳
Pod里面有一个基础容器pause，处于停止状态，其他容器共享pause的IPC,Network,UTS

image.png

虽然Pod可以跑多个容器，但我们要尽量跑一个容器，即Pod里面跑一个主容器，其余的为辅助容器，我们称之为side car（边车）
例：跑一个nginx容器，要收集日志，需要一个辅助容器收集日志
同一类型的资源不能同名
k8s上每一种资源都可以有标签，我们通过标签选择器(label selector)来完成对资源过滤

标签（label）

• 标签就是键值类型的数据，它们可于资源创建时指定，也可以随时按需添加与活动对象，而后即可由标签选择器进行匹配检查从而完成资源挑选
• 一个对象可拥有不止一个标签，而同一个标签也可被添加至多个资源上，可以为资源附加多个不同纬度的标签，以实现灵活的资源分组管理不同的版本。例如版本标签，环境标签，分层架构标签，等用于交叉标识同一个资源所属的不同版本，环境，即架构层级
  标签中的键名称通常由键前缀和键名组成。其中键前缀可选，其格式诶"KEY_PREFIX/KEY_NAME" 键名至多使用63个字符，必须以字母和数字开头，键前缀必须为DNS子域名名称格式，且不能超过253个字符。省略前缀是，键将被视为用户的私有数据。而"kubernetes.io"前缀预留给kubernetes的核心组件使用，不能给用户使用。标签中键值不能多于63个字符，以数字和字母开头即结尾

标签选择器（label selector）

标签选择器用于表达标签的查询条件或选择标准
kubernetes API 目前支持两个选择器
基于等值关系（equality-based）
操作符有=、==、和!= 三种，其中前两个相同，都表示等值关系，最后一个表示不等关系
基于集合关系(set-based)
KEY in （VALEUEL1,VALUE2，....）
KEY not in (VALUE1,VALUE2,...)
KEY: 所有存在此键名标签的资源
!KEY: 所有不存在此键名标签的资源
使用标签选择器时还遵循以下逻辑： 同时指定的多个选择器之间的逻辑关系为"与"操作，使用空值得标签选择器意味着每个资源对象都将被选中，空的标签选择器将无法选出任何资源
定义标签选择器的方式：
matchLabels: 通过给定键值对，指定标签选择器
matchExpressions: 基于表达式指定的标签选择器列表，每个选择器形如"{key:KEY_NAME,operator:OPERATOR,values:{VALUE1,VALUE2,....}}" 选择器列表间为"逻辑与"关系
使用In或NotIn操作时，使用values非必须为非空字符串列表，而使用exists或DostNotExist时，其values必须为空
kubectl get pods --show-labels 显示pod的标签

[root@k8s-master basic]# cat pod-label.yaml 
apiVersion: v1
kind: Pod
metadata:
 name: pod-daemon
 namespace: develop
 labels: 
   app: pod-daemon
   rel: stable
spec:
 containers:
   - name: myapp
     image: ikubernetes/myapp:v1
     imagePullPolicy: IfNotPresent

kubectl  label -h
kubectl label --overwrite pods mypod unhealthy=true
key: unhealthy
value: true
kubectl label --overwrite pods mypod unhealthy=false //覆盖原先key的值
kubectl label --overwrite pods mypod unhealthy-  //删除unhealthy key

使用标签选择器
kubectl get pods --show-lables -l app=myapp
kubectl get pods --show-labels -l "app in (myapp,ngx-dep)"  //过滤app的键值为myapp或ngx-dep的
kubectl get pods -l "app in (myapp,ngx-dep)" -L app //显示app这个键的值，在过滤标签中

资源注解（annotation）

注解也为键值类型的数据，不过它不能用于标签及挑选kubernets对象，仅用于对资源提供源数据信息
注解中的元数据不受字符数量的限制，它可大可小，可以为结构化或非结构化形式，也支持使用在标签中禁止使用的其他字符
kubernetes的新版本中（Alpha或Beta阶段）为资源引入新字段时，常以注解的方式提供以避免其增删等变动给用户带去困扰，一旦确定支持使用它们，这些新增字段再引到资源中，并淘汰相关注解

kubelte apply 多次执行的原因，每次执行apply都会对比这次版本与上次区别，然后打成补丁去进行更新

Pod生命周期

1、init Container 初始化容器
一般主容器运行之前，需要一些文件（如nginx，需要站点目录），所以在主容器运行之前，有一些初始化容器，完成文件创建，然后结束（初始化容器，并不是必须的）。在我们创建主容器，感觉它完成不了时，就需要初始化容器（init Container）初始化容器也可以有多个，如果多个，得所有初始化容器完成工作后，主容器才能启动，且这个多初始化容器是串行启动，但主容器和辅助容器是并行启动的
kubectl explain pods.spec.initContainers
2、主容器运行
     容器刚刚启动之后（post start hook）
     容器结束之前（pre stop hook）
     正常阶段(liveness) 探测容器内的程序是否正常运行
post start hook 和pre stop hook 可以触发用户自定义命令
正常运行，使用用户自定义命令去探测容器内的进程，是否工作。如果不工作，则重启容器。如果重启失败，会立即重启。如果再失败，隔5秒重启，再失败，隔10秒，在依次递归到最后隔5分钟重启
 就绪状态检测，
kubectl explain pods.spec.containers.lifecycle
定义 post start hook 和pre stop hook的
 kubectl explain pods.spec.containers.livenessProbe
exec: 运行的命令。注意此命令一定是镜像内的命令，这个命令是在容器内执行的。它可以是任何命令，可以判断容器内的文件是否存在或判断服务是否可用
failureThreshold    <integer>  几次失败后才算真的失败，默认3次
timeoutSeconds  <integer> 我们请求一个服务，它响应超时时间，默认1秒中

kubectl explain pods.spec.containers.readinessProbe  就绪状态检测，没有权利重启容器
健康状态检测，才能重启容器，只有就绪状态检测成功了，service才会把Pod 端口添加到规则里面来，就绪状态检测也是周期性工作，会一直检测服务状态，如果就绪状态检测不成功。就会从service中移除

Pod 对象的相位

Pod 对象总是应该处于其生命进程中以下几个相位（phase)
Pending: API server 创建了Pod资源对象并已存入etcd中，但它尚未调度完成（多数原因，node节点资源不够）
Running：Pod 已经被调度至某节点，并且所有容器都已经被kubelete 创建完成
Succeded: Pod 中所有容器都已经成功终止，并且不会重启
Failed：所有容器都已经终止，但至少有一个容器终止失败，即容器返回了非0值的退出状态，或已经被系统终止
Unknown: API server 无法正常获取Pod对象的状态信息，通常是由于其无法与所在的工作节点的kubectl通信导致

Pod对象创建过程

image.png

容器的重启策略
Pod对象因容器程序崩溃或容器申请超出限制的资源等原因可能导致其终止，此时是否应该重建此它取决去其重启策略（restartPolicy）属性的定义
Always:但凡Pod对象终止，就将其重启，此为默认设定
OnFailure：仅在Pod对象出现错误时，方才将其重启，正常终止不会重启
Nerver：从不重启

Pod 终止过程

image.png

kubectl explain pods.spec
securitycontext: 限制Pod的程序以Node节点的身份运行
Pod Security：
kubectl explain pods.spec.containers.securityContext
capabilities 定义这个容器的内核哪些能力（需要详细了解内核的安全机制）
Pod 优先级设定
kubectl explain pods.spec.priorityClassName
在k8s中，首先定义出几个优先级来，然后进行分配这个优先级的名字
Pod中使用容器资源
kubectl explain pods.spec.containers.resources
resources：操作系统资源（计算资源）
Pod服务质量类别
根据Pod对象的requests 和limit 属性，kubernets 把Pod对象归类成 BestEffort，Bursttable和Guarnateed 三个服务质量类别（Quality of service ,Qos）类别下
Guaranteed: 每个容器都为cpu资源，设置了具有相同的request 和limits属性，以及每个容器都为内存资源设置了相同值的request 和limit属性的Pod资源，会自动归属此类别，这类Pod具有最高优先级
Bursttable：至少有一个容器设置了cpu或内存资源的request属性，但不满足Guaranteed类别要求的Pod资源自动归属此类别，它们具有中等优先级
BestEffort：未任何一个容器，设置requests或limit属性的Pod资源自动归属此类别，它们的优先级为最低优先级