Pod属性？
- 在同一个Pod之下的容器使用IPC互相通信
- 容器可以通过localhost找到彼此
- 每个容器继承Pod的name
- 在同一个网络共享平面中每个Pod都有一个ip
- Volumes被Pod中的容器所共享
标签（Label）
- 标签就是“键值”类型的数据，他们可于资源创建时直接指定，也可随时按需添加于活动对象，而后即可由标签选择器进行匹配度检查从而完成资源筛选
- 一个对象可拥有不止一个标签，而同一个标签也可被添加至多个资源之上
- 实践中，可以为资源附件多个不同维度的标签以实现灵活的资源分组管理功能，例如版本标签、环境标签、分层架构标签等，用于交叉标识同一个资源所属的不同版本、环境及架构层级等
- 标签中的键名称通常由键前缀和键名组成，其中前缀可选，其格式形如“KEY_PREFIX/KEY_NAME”
- 键名至多能使用63各字符，可使用如数字、字母、连接号(-)、下划线(_)、点号(.)等字符，且只能以字母或数字开头
- 键前缀必须为DNS子域名格式，且不能超过253个字符。省略键前缀时，键将被视为用户的私有数据，不过由Kunernetes系统组件或第三方组件自动为用户资源添加的键必须使用键前缀，而”Kubernetes.io/“前缀预留给kubernetes的核心组件使用
- 标签中的键值必须不能多余63个字符，它要么为空，要么是以字母或者数字开头及结尾，且中间仅使用了数字、字母、连接号(-)、下划线(_)、点号(.)等字符的数据
标签示例图：
标签选择器（Label Selector）
- 标签选择器用于表达标签的查询条件或者选择标准，Kubernetes API目前支持两个选择器
- 给予等值关系（equality-based）
- 操作符有 = == 和 != 三种，其中前两个意义相同，都表示“等值”关系，最后一个表示“不等”关系
- 基于集合关系（set-based）
- KEY in （VALUE1,VALUE12, ...）
- KEY not in （VALUE1,VALUE12, ...）
- KEY： 所有存在此键名标签的资源
- KEY： 所有不存在此键名标签的资源
- 给予等值关系（equality-based）
- 使用标签选择器时还将遵循以下逻辑
- 同时指定多个选择器之间的逻辑关系为“与”操作
- 使用空值的标签选择器意味着每个资源对象都将被选中
- 空的标签选择器将无法选择出任何资源
定义标签选择器的方式
- Kubernetes的诸多资源对象必须以标签选择器的方式关联到Pod资源对象，例如Service、Deployment和ReplicaSet类型的资源等，他们在spec字段中嵌套使用嵌套的“selector"字段，通过“matchLabels”来指定标签选择器，有的甚至还支持使用“matchExpressions”构造复杂的标签选择机制。
- matchLabels：通过直接给定键值对指定标签选择器
- matchExpressions：基于表达式指定的标签选择器列表，每个选择器形如“{key： KEY_NAME，operator： OPERATOR，values：[VALUE1,VALUE2,...]}”，选择器列表间为逻辑“与”关系
- 使用In或NotIn操作符时，其values非必须为非空的字符串列表，而使用Exists或DostDotExists时，其values必须为空
添加标签示例：
yaml清单配置添加labels： root@k8s-master:/home/ubuntu/manifests/basic# cat dev-pod.yamlapiVersion: v1kind: Podmetadata: name: dev-pod namespace: develop labels: # 这里是新增标签 app: ngx-demo rel: stablespec: containers: - image: nginx imagePullPolicy: IfNotPresent name: nginx-maple hostNetwork: true 查询结果： 命令行打标签操作： 1. 增加tier标签 2. overwrite app标签 3. 删除标签，输出标签使用 键名-
资源注解（annotation）
- 注解也是“键值”类型的数据，不过它不能用于标签及挑选kubernetes对象，仅用于为资源提供“元数据”信息
- 注解中的元数据不受字符数量的限制，它可大可小，可以为结构化或非结构化形式，也支持使用在标签中禁止使用的其他字符
- 在kubernetes的新版本(Alpha或Beta阶段)中为某资源引入新字段时，常以注解方式提供以表面增删等变动给用户带去困扰，一旦确定支持使用它们，这心新增字段再引入到资源中并淘汰相关的注解
Pod生命周期
容器探针：
- livenessProbe（存活）：指示容器是否正在运行。如果存活探测失败，则 kubelet 会杀死容器，并且容器将受到其重启策略 的影响。如果容器不提供存活探针，则默认状态为 Success。
- readinessProbe（就绪）：指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与 Pod 匹配的所有 Service 的端点中删除该 Pod 的 IP 地址。初始延迟之前的就绪状态默认为 Failure。如果容器不提供就绪探针，则默认状态为 Success。
探针操作（由kubelet调用容器实现的Handler）：
- ExecAction：在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。
- TCPSocketAction：对指定端口上的容器的 IP 地址进行 TCP 检查。如果端口打开，则诊断被认为是成功的。
- HTTPGetAction：对指定的端口和路径上的容器的 IP 地址执行 HTTP Get 请求。如果响应的状态码大于等于200 且小于 400，则诊断被认为是成功的。
Pod对象的相位：
- 挂起（Pending）：Pod 已被 Kubernetes 系统接受，但有一个或者多个容器镜像尚未创建。等待时间包括调度 Pod 的时间和通过网络下载镜像的时间，这可能需要花点时间。
- 运行中（Running）：该 Pod 已经绑定到了一个节点上，Pod 中所有的容器都已被创建。至少有一个容器正在运行，或者正处于启动或重启状态。
- 成功（Succeeded）：Pod 中的所有容器都被成功终止，并且不会再重启。
- 失败（Failed）：Pod 中的所有容器都已终止了，并且至少有一个容器是因为失败终止。也就是说，容器以非0状态退出或者被系统终止。
- 未知（Unknown）：因为某些原因无法取得 Pod 的状态，通常是因为与 Pod 所在主机通信失败。
Pod对象的创建过程：
容器的重启策略：
Pod对象因容器程序崩溃或容器申请超出限制的资源等原因都可能导致其被终止，此时是否应该重建取决于其重启策略
- Always：但凡pod对象终止就将其重启，此为默认设定
- Onfailure： 仅在pod对象出现错误时才将其重启
- Never： 从不重启
Pod对象的终止过程：
Pod安全上下文
- 节点运行权限设定，具体设定可以参考securityContext
kubectl explain pod.spec.securityContext
- 同时还有容器的安全上下文设定securityContext
kubectl explain pod.spec.containers.securityContext
Pod优先级
资源紧缺时，需要用到优先级
kubectl explain pod.spec.priority
容器资源范围
kubectl explain pod.spec.containers.resources.limits 上限
kubectl explain pod.spec.containers.resources.requests 下限
资源需求及资源限制
容器的计算资源配额
- CPU属于可压缩型资源，即资源额度可按需收缩，而内存则是不可压缩型资源，对其执行收缩操作可能会导致某种程度的问题
- CPU资源的计量方式
- 一个核心相当于1000个微核心，及1=1000m，0.5=500m
- 内存资源的计量方式
- 默认单位为字节，也可以使用使用E、P、G、M和K后缀单位，或Ei、Pi、Gi、Mi和Ki后缀单位
Pod服务质量类别
根据Pod对象的requests和limits属性，k8s把Pod对象归类到BestEffort、Burstable和Guaranteed三个服务质量类别
- Guaranteed：每个容器都为CPU资源设置了具有相同值的requests和limits属性，以及每个容器都为内存次元设置了具有相同值的requests和limits属性的Pod资源会自动归属此列别，这类pod资源具有最高优先级
- Burstable：至少有一个容器设置了CPU或内存资源的requests属性，但不满足Guaranteed类别要求的pod资源自动归属此类别，他们具有中等优先级
- BestEffort：未为任何一个容器设置requests或limits属性的pod资源自动归属此类别，他们的优先级为最低级别