Pod资源管理

时间 2019-12-01

标签 pod 资源管理繁體版

原文原文链接

Pod属性？nginx

在同一个Pod之下的容器使用IPC互相通讯
容器能够经过localhost找到彼此
每一个容器继承Pod的name
在同一个网络共享平面中每一个Pod都有一个ip
Volumes被Pod中的容器所共享

标签（Label）ubuntu

标签就是“键值”类型的数据，他们可于资源建立时直接指定，也可随时按需添加于活动对象，然后便可由标签选择器进行匹配度检查从而完成资源筛选
- 一个对象可拥有不止一个标签，而同一个标签也可被添加至多个资源之上
- 实践中，能够为资源附件多个不一样维度的标签以实现灵活的资源分组管理功能，例如版本标签、环境标签、分层架构标签等，用于交叉标识同一个资源所属的不一样版本、环境及架构层级等
- 标签中的键名称一般由键前缀和键名组成，其中前缀可选，其格式形如“KEY_PREFIX/KEY_NAME”
  - 键名至多能使用63各字符，可以使用如数字、字母、链接号(-)、下划线(_)、点号(.)等字符，且只能以字母或数字开头
  - 键前缀必须为DNS子域名格式，且不能超过253个字符。省略键前缀时，键将被视为用户的私有数据，不过由Kunernetes系统组件或第三方组件自动为用户资源添加的键必须使用键前缀，而”Kubernetes.io/“前缀预留给kubernetes的核心组件使用
  - 标签中的键值必须不能多余63个字符，它要么为空，要么是以字母或者数字开头及结尾，且中间仅使用了数字、字母、链接号(-)、下划线(_)、点号(.)等字符的数据

标签示例图：c#

标签选择器（Label Selector）api

标签选择器用于表达标签的查询条件或者选择标准，Kubernetes API目前支持两个选择器
- 给予等值关系（equality-based）
  - 操做符有 = == 和 != 三种，其中前两个意义相同，都表示“等值”关系，最后一个表示“不等”关系
- 基于集合关系（set-based）
  - KEY in （VALUE1,VALUE12, ...）
  - KEY not in （VALUE1,VALUE12, ...）
  - KEY：全部存在此键名标签的资源
  - KEY：全部不存在此键名标签的资源
使用标签选择器时还将遵循如下逻辑
- 同时指定多个选择器之间的逻辑关系为“与”操做
- 使用空值的标签选择器意味着每一个资源对象都将被选中
- 空的标签选择器将没法选择出任何资源

定义标签选择器的方式安全

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.yaml
apiVersion: v1
kind: Pod
metadata:
  name: dev-pod
  namespace: develop
  labels:　　　　　　　　# 这里是新增标签
    app: ngx-demo rel: stable
spec:
  containers:
  - image: nginx
    imagePullPolicy: IfNotPresent
    name: nginx-maple
  hostNetwork: true

查询结果：



命令行打标签操做：
1. 增长tier标签
2. overwrite app标签
3. 删除标签，输出标签使用 键名-

资源注解（annotation）架构

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

Pod生命周期app

容器探针：spa

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资源自动归属此类别，他们的优先级为最低级别