kubernetes 官方文档整理，k8s入门教程笔记整理---5、容器

7. 容器

每个运行的容器都是可重复的，容器内包含了依赖环境，将应用程序从底层主机设施中解耦。
在k8s中运行pod，pod中运行了容器。
容器镜像是可运行的软件包，包含运行应用程序所需的一切（代码、运行时、应用程序、库、默认值等）
容器运行时是负责运行容器的软件，containerd、CRI-O、kubernetes CRI(容器运行时接口)，你可以为Pod指定RuntimeClass

7.1 镜像

容器镜像所承载的是封装了应用程序和所有软件依赖的二进制数据。是可执行的软件包

7.1.1 镜像名称

仓库:端口(可选)/项目名/镜像名:tag
例如：harbor.openserver.cn:443/cscec_big_data-cloudbases/kube-proxy:v1.21.5
标签可以包含小写、大写字母、数字、“_”、“.”、“-”。默认标签为latest
docker images --digests 镜像的摘要,以sha256表示的指纹信息。可以说镜像摘要是唯一标识一个镜像的存在，因为镜像的tag有可能被覆盖，被覆盖后旧的镜像的tag就会变为none。

7.1.2 更新镜像

7.1.2.1 镜像拉取策略

容器的imagePullPolicy会影响镜像拉取策略
默认镜像拉取策略为IfNotPresent，代表kubelet在镜像已存在的情况下略过拉取镜像的操作

• IfNotPresent
  本地不存在镜像才拉取
• Always
  每当kubelet启动容器时，都会访问容器的镜像仓库，将名称解析为摘要，如果本地有对应的摘要，就会使用这个缓存的镜像。否则kubelet就会重新拉取镜像
• Never
  kubelet不会从仓库获取镜像，只使用本地的镜像，镜像不存在则启动失败

要注意尽量不使用latest标签，因为默认标签很容易被替换，可以使用v1.42.1这样的标签。
或者使用sha256摘要，@，使用摘要可以确保每次使用的都是这个镜像而不会被替换。
当覆盖镜像仓库中某个镜像的tag时，旧镜像的tag会被置为，如果你本地存在这个镜像且镜像拉取策略为IfNotPresent，就有可能造成重启pod时使用的还是旧镜像，解决方法是将镜像拉取策略改为Always或在对应节点本地删除对应镜像

7.1.2.2 默认镜像拉取策略

在省略imagePullPolicy时

• 镜像指定为摘要或:非latest的标签 -> IfNotPresent
• 镜像tag为latest或没指定标签 -> Always

7.1.2.2 ImagePullBackOff

k8s拉取镜像失败，BackOff表示会重复拉取镜像，但是每次延迟增加300秒。

7.1.3 串行和并行镜像拉取

串行：每次只发起一个镜像拉取请求，其他镜像拉取请求等待。
并行：配置kubelet将字段serializeImagePulls设置为false，将会向镜像仓库发其多个镜像请求，但是并行拉取是对pod来说的，而不是容器。
设置字段maxParallelImagePulls，代表最大并行镜像拉取的数量

7.1.4 带镜像索引的多架构镜像

可以设置不同系统的tag 例如pause-amd64，其中后缀代表镜像索引，供不同系统基于机器体系拉取镜像

7.1.5 私有仓库

私有仓库有可能需要密钥，

• 配置节点向私有仓库的身份认证（再节点上配置）
• kubelet凭据提供程序，动态获取私有仓库凭据。（使用插件）
• 预拉镜像，在节点上预先拉取一份
• 在pod上设置ImagePullSecrets（建议使用）

apiVersion: v1
kind: Pod
metadata:
  name: foo
  namespace: awesomeapps
spec:
  containers:
    - name: foo
      image: janedoe/awesomeapp:v1
  imagePullSecrets:
    - name: myregistrykey

• 特定于厂商扩展或本地扩展

7.2 容器环境

容器环境给容器提供了几个重要资源

• 文件系统，包含镜像和卷
• 容器自身信息
• 集群中其他对象的信息

容器信息

• hostname命令或调用libc的gethostname函数获取
• pod名称和ns可以通过下行API转为环境变量
• Pod中的用户定义的环境变量也可以在容器中使用

集群信息

• 正在运行的同命名空间的所有服务都可作为容器的环境变量
• 例如名为foo的服务，想要映射到bar的容器。
  FOO_SERVICE_HOST=<其上服务正运行的主机>
  FOO_SERVICE_PORT=<其上服务正运行的端口>
  服务具有专用的 IP 地址。如果启用了 DNS 插件， 可以在容器中通过 DNS 来访问服务

7.3 容器运行时类(Runtime Class)

Runtime Class 是一个用于选择容器运行时配置的特性，容器运行时配置用于运行Pod中的容器。
可以在不同的Pod设置不同的Runtime Class，以提供性能和安全性的平衡

7.3.1 设置

• 在节点上配置CRI实现
  RuntimeClass配置依赖于CRI(容器运行时接口)的实现。
  • containerd
    修改/etc/containerd/config.toml配置[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.${HANDLER_NAME}]
  • CRI-O
    修改/etc/crio/crio.conf配置[crio.runtime.runtimes.${HANDLER_NAME}] runtime_path = "${PATH_TO_BINARY}"
• 创建相应的RuntimeClass资源
  每个配置都需要有一个用于标识配置的handler。针对每个handler都需要创建一个RuntimeClass对象 。
  需要配置metadata.name和handler。RuntimeClass对象的名称必须是有效的DNS子域名

# RuntimeClass 定义于 node.k8s.io API 组
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  # 用来引用 RuntimeClass 的名字
  # RuntimeClass 是一个集群层面的资源
  name: myclass
# 对应的 CRI 配置的名称
handler: myconfiguration

• 在Pod的Spec中指定RuntimeCLassName，未指定则使用默认的

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  runtimeClassName: myclass
  # ...

7.3.2 调度

设置runtimeclass.scheduling，代表将pod调度到指定的节点上(如果不设置代表所有的节点都支持此RuntimeClass)，例如设置runtimeclass.scheduling.nodeSeletor和tolerations以配置节点选择器和容忍度，这将于pod的节点选择器和容忍度取交集，如果冲突则报错。
你可以指定运行于运行pod相关的开销资源，代表允许集群在决策pod和资源是将其考虑在内，通过RuntimeClass的overhead定义，你可以指定使用的RuntimeClass运行pod时的开销并确保k8s将这些开销计算在内

7.4 容器生命周期回调

7.4.1 概述

kubelet管理的容器如何使用容器生命周期回调框架，也就是由其管理生命周期中的时间触发，运行指定代码
像Angular、kubernetes为容器提供了生命周期回调，这种回调能够管理生命周期的事件，并处理程序中的代码

7.4.2 容器回调

• PostStart 容器创建后被立即执行，但是不能保证回调会在容器入口点（ENTRYPOINT）之前执行。没有参数传递给处理程序。
• PreStop 在容器因API请求或管理事件（如存活态探针、启动探针失败、资源抢占、资源竞争），在被终止前，终止宽限周期开始计时，
  此回调会被调用，到期则停止。所以PreStop有可能调用失败，因为有可能调用的时候容器已终止。

7.4.3 回调处理程序的实现

通过实现和注册该回调的处理程序来访问该回调。两种类型

• Exec 在容器的cgroups和ns中执行特定命令。命令所消耗的资源计入容器资源消耗
• HTTP 对容器上特定端点执行HTTP请求

7.4.4 回调处理程序执行

当调用容器生命周期管理回调时，httpGet、tcpSocket在kubelet执行，exec在容器内执行。

• PostStart：回调处理程序调用在pod中是上下文同步的(跑完回调处理程序才能跑pod)，而在容器内，容器入口点和回调处理程序是异步触发的，所以容器跑完了，回调处理程序有可能还没处理完，这将导致还没pod无法running
• PreStop：回调必须在发送结束信号之前完成，PreStop执行时停滞不前，那么Pod会变成Terminating并一直处于该状态，直到terminationGracePeriodSeconds 耗尽，pod才被杀死。
• 如果PostStart和PreStop回调失败，那么会杀死容器
• 正常情况下回调只调用一次，

7.4.5 调试回调程序

回调处理程序如果失败会产生一个事件，FailedPostStartHook或FailedPreStopHook
修改 lifecycle-events.yaml 将 postStart 命令更改为 “badcommand” 即可调试