diff --git a/.vuepress/config.js b/.vuepress/config.js index b03743c..021f37a 100644 --- a/.vuepress/config.js +++ b/.vuepress/config.js @@ -48,10 +48,10 @@ module.exports = { // } // } // }, - '@vuepress/pwa': { - serviceWorker: true, - updatePopup: true - }, + // '@vuepress/pwa': { + // serviceWorker: true, + // updatePopup: true + // }, '@vssue/vuepress-plugin-vssue': { // set `platform` rather than `api` platform: 'github', @@ -82,7 +82,7 @@ module.exports = { // zIndex: 10000, // }, // }, - 'vuepress-plugin-smooth-scroll': {}, + // 'vuepress-plugin-smooth-scroll': {}, 'code-switcher': {}, 'reading-progress': {}, // 'vuepress-plugin-baidu-autopush':{}, @@ -274,6 +274,9 @@ module.exports = { children: [ 'k8s-intermediate/container/images', 'k8s-intermediate/container/env', + 'k8s-intermediate/container/runtime', + 'k8s-intermediate/container/lifecycle', + 'k8s-intermediate/container/lifecycle-p', ] }, { diff --git a/.vuepress/public/statics/learning/container/lifecycle.yaml b/.vuepress/public/statics/learning/container/lifecycle.yaml new file mode 100644 index 0000000..dd8ce90 --- /dev/null +++ b/.vuepress/public/statics/learning/container/lifecycle.yaml @@ -0,0 +1,15 @@ +apiVersion: v1 +kind: Pod +metadata: + name: lifecycle-demo +spec: + containers: + - name: lifecycle-demo-container + image: nginx + lifecycle: + postStart: + exec: + command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"] + preStop: + exec: + command: ["/bin/sh","-c","nginx -s quit; while killall -0 nginx; do sleep 1; done"] diff --git a/learning/k8s-basics/expose.md b/learning/k8s-basics/expose.md index 35a3a62..7319d74 100644 --- a/learning/k8s-basics/expose.md +++ b/learning/k8s-basics/expose.md @@ -48,7 +48,7 @@ Service是一个抽象层，它通过 LabelSelector 选择了一组 Pod（容器 ## 服务和标签 -下图中有两个服务Service A(蓝色虚线)和Service B(黄色虚线) +下图中有两个服务Service A(黄色虚线)和Service B(蓝色虚线) Service A 将请求转发到 IP 为 10.10.10.1 的Pod上， Service B 将请求转发到 IP 为 10.10.10.2、10.10.10.3、10.10.10.4 的Pod上。 diff --git a/learning/k8s-intermediate/container/env.md b/learning/k8s-intermediate/container/env.md index 1f196b4..1cf22d0 100644 --- a/learning/k8s-intermediate/container/env.md +++ b/learning/k8s-intermediate/container/env.md @@ -9,6 +9,8 @@ meta: # 容器的环境变量 +> 参考文档： [Container Environment Variables](https://kubernetes.io/docs/concepts/containers/container-environment-variables/) + Kubernetes为容器提供了一系列重要的资源： * 由镜像、一个或多个数据卷合并组成的文件系统 * 容器自身的信息 diff --git a/learning/k8s-intermediate/container/lifecycle-p.md b/learning/k8s-intermediate/container/lifecycle-p.md new file mode 100644 index 0000000..cc059fc --- /dev/null +++ b/learning/k8s-intermediate/container/lifecycle-p.md @@ -0,0 +1,71 @@ +--- +vssueId: 124 +layout: LearningLayout +description: Kubernetes教程_Kubernetes 中支持容器的 postStart 和 preStop 事件，本文阐述了如何向容器添加生命周期事件处理程序（handler） +meta: + - name: keywords + content: Kubernetes 教程,K8S 教程,容器生命周期 +--- + +# 容器生命周期事件处理 + +> 参考文档： [Attach Handlers to Container Lifecycle Events](https://kubernetes.io/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/) + +Kubernetes 中支持容器的 postStart 和 preStop 事件，本文阐述了如何向容器添加生命周期事件处理程序（handler）。 +* `postStart` 容器启动时，Kubernetes 立刻发送 postStart 事件，但不确保对应的 handler 是否能在容器的 `EntryPoint` 之前执行 +* `preStop` 容器停止前，Kubernetes 发送 preStop 事件 + +## 前提 + +您已经有一个安装好的 Kubernetes 集群，并且可以通过 kubectl 访问该集群。请参考： + +[安装Kubernetes单Master节点](/install/install-k8s.html) + +## 定义postStart和preStop处理程序 + +下面的例子中，您将创建一个包含单一容器的 Pod，并为该容器关联 postStart 和 preStop 处理程序（handler）。Pod 的yaml文件定义如下： + +<<< @/.vuepress/public/statics/learning/container/lifecycle.yaml + +在该例子中，请注意： +* postStart 命令向 `usr/share/message` 文件写入了一行文字 +* preStop 命令优雅地关闭了 nginx + > 如果容器碰到问题，被 Kubernetes 关闭，这个操作是非常有帮助的，可以使得您的程序在关闭前执行必要的清理任务 + +* 创建 Pod + ``` sh + kubectl apply -f https://kuboard.cn/statics/learning/container/lifecycle.yaml + ``` + +* 验证 Pod 中的容器已经运行： + + ``` sh + kubectl get pod lifecycle-demo + ``` + +* 进入容器的命令行终端： + + ``` sh + kubectl exec -it lifecycle-demo -- /bin/bash + ``` + +* 在命令行终端中，验证 `postStart` 处理程序创建的 `message` 文件： + + ``` sh + root@lifecycle-demo:/# cat /usr/share/message + ``` + + 输出结果如下所示： + ``` + Hello from the postStart handler + ``` + +## 总结 + +Kubernetes 在容器启动后立刻发送 postStart 事件，但是并不能确保 postStart 事件处理程序在容器的 EntryPoint 之前执行。postStart 事件处理程序相对于容器中的进程来说是异步的（同时执行），然而，Kubernetes 在管理容器时，将一直等到 postStart 事件处理程序结束之后，才会将容器的状态标记为 Running。 + +Kubernetes 在决定关闭容器时，立刻发送 preStop 事件，并且，将一直等到 preStop 事件处理程序结束或者 Pod 的 `--grace-period` 超时，才删除容器。请参考 [Termination of Pod](/learning/k8s-intermediate/workload/pod.html#termination-of-pods) + +::: tip +Kubernetes 只在 Pod `Teminated` 状态时才发送 preStop 事件，这意味着，如果 Pod 已经进入了 `Completed` 状态， preStop 事件处理程序将不会被调用。这个问题已经记录在 kubernetes 的 issue 中： [issue #55087](https://github.com/kubernetes/kubernetes/issues/55807) +::: diff --git a/learning/k8s-intermediate/container/lifecycle.md b/learning/k8s-intermediate/container/lifecycle.md new file mode 100644 index 0000000..e508bc9 --- /dev/null +++ b/learning/k8s-intermediate/container/lifecycle.md @@ -0,0 +1,82 @@ +--- +vssueId: 124 +layout: LearningLayout +description: Kubernetes教程_本文描述了 kubelet 管理的容器如何使用容器生命周期钩子执行指定的代码。 +meta: + - name: keywords + content: Kubernetes 教程,K8S 教程,容器生命周期 +--- + +# 容器生命周期 + +> 参考文档： [Container Lifecycle Hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) + +本文描述了 kubelet 管理的容器如何使用容器生命周期钩子执行指定的代码。 + +## 概述 + +绝大多数高级程序编程语言的框架（例如，Angular、Spring Framework、Vue 等）在组件的生命周期中提供 hook（钩子函数），例如 Vue 组件的 `created`、`mounted`、`beforeDestroy`、`destroyed`， Java Web 应用中 ServeletContextListener 的 `contextInitialized`、`contextDestroyed` 等。Kubernetes 中，也为容器提供了对应的生命周期钩子函数，使得容器可以获知其所在运行环境对其进行管理的生命周期事件，以便容器可以响应该事件，并执行对应的代码。 + +## 容器钩子 + +Kubernetes中为容器提供了两个 hook（钩子函数）： + +* `PostStart` + + 此钩子函数在容器创建后将立刻执行。但是，并不能保证该钩子函数在容器的 `ENTRYPOINT` 之前执行。该钩子函数没有输入参数。 + +* `PreStop` + + 此钩子函数在容器被 terminate（终止）之前执行，例如： + + * 通过接口调用删除容器所在 Pod + * 某些管理事件的发生：健康检查失败、资源紧缺等 + + 如果容器已经被关闭或者进入了 `completed` 状态，preStop 钩子函数的调用将失败。该函数的执行是同步的，即，kubernetes 将在该函数完成执行之后才删除容器。该钩子函数没有输入参数。 + + 更多内容请参考 [Termination of Pods](/learning/k8s-intermediate/workload/pod.html#termination-of-pods) + +### Hook handler的实现 + +容器只要实现并注册 hook handler 便可以使用钩子函数。Kubernetes 中，容器可以实现两种类型的 hook handler： + +* Exec - 在容器的名称空进和 cgroups 中执行一个指定的命令，例如 `pre-stop.sh`。该命令所消耗的 CPU、内存等资源，将计入容器可以使用的资源限制。 +* HTTP - 想容器的指定端口发送一个 HTTP 请求 + + +### Hook handler的执行 + +当容器的生命周期事件发生时，Kubernetes 在容器中执行该钩子函数注册的 handler。 + +对于 Pod 而言，hook handler 的调用是同步的。即，如果是 `PostStart` hook，容器的 `ENTRYPOINT` 和 hook 是同时出发的，然而如果 hook 执行的时间过长或者挂起了，容器将不能进入到 `Running` 状态。 + +`PreStop` hook 的行为与此相似。如果 hook 在执行过程中挂起了，Pod phase 将停留在 `Terminating` 的状态，并且在 `terminationGracePeriodSeconds` 超时之后，Pod被删除。如果 `PostStart` 或者 `PreStop` hook 执行失败，则 Kubernetes 将 kill（杀掉）该容器。 + +用户应该使其 hook handler 越轻量级越好。例如，对于长时间运行的任务，在停止容器前，调用 `PreStop` 钩子函数，以保存当时的计算状态和数据。 + + +### Hook触发的保证 + +Hook 将至少被触发一次，即，当指定事件 `PostStart` 或 `PreStop` 发生时，hook 有可能被多次触发。hook handler 的实现需要保证即使多次触发，执行也不会出错。 + +通常来说，hook 实际值被触发一次。例如：如果 HTTP hook 的服务端已经停机，或者因为网络的问题不能接收到请求，请求将不会被再次发送。在极少数的情况下， 触发两次 hook 的事情会发生。例如，如果 kueblet 在触发 hook 的过程中重启了，该 hook 将在 Kubelet 重启后被再次触发。 + +### 调试 hook handler + +Hook handler 的日志并没有在 Pod 的 events 中发布。如果 handler 因为某些原因失败了，kubernetes 将广播一个事件 `PostStart` hook 发送 `FailedPreStopHook` 事件。 +可以执行命令 `kubectl describe pod $(pod_name)` 以查看这些事件，例如： + +``` sh +Events: + FirstSeen LastSeen Count From SubobjectPath Type Reason Message + --------- -------- ----- ---- ------------- -------- ------ ------- + 1m 1m 1 {default-scheduler } Normal Scheduled Successfully assigned test-1730497541-cq1d2 to gke-test-cluster-default-pool-a07e5d30-siqd + 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulling pulling image "test:1.0" + 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Created Created container with docker id 5c6a256a2567; Security:[seccomp=unconfined] + 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulled Successfully pulled image "test:1.0" + 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Started Started container with docker id 5c6a256a2567 + 38s 38s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 5c6a256a2567: PostStart handler: Error executing in Docker Container: 1 + 37s 37s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 8df9fdfd7054: PostStart handler: Error executing in Docker Container: 1 + 38s 37s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} Warning FailedSync Error syncing pod, skipping: failed to "StartContainer" for "main" with RunContainerError: "PostStart handler: Error executing in Docker Container: 1" + 1m 22s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} +``` diff --git a/learning/k8s-intermediate/container/runtime.md b/learning/k8s-intermediate/container/runtime.md new file mode 100644 index 0000000..eb207aa --- /dev/null +++ b/learning/k8s-intermediate/container/runtime.md @@ -0,0 +1,109 @@ +--- +vssueId: 124 +layout: LearningLayout +description: Kubernetes教程_使用RuntimeClass这一特性可以为容器选择运行时的容器引擎。可以通过 RuntimeClass，使不同的 Pod 使用不同的容器引擎，以在性能和安全之间取得平衡。 +meta: + - name: keywords + content: Kubernetes教程,K8S教程,Runtime Class +--- + +# Runtime Class + +> 参考文档： [Runtime Class](https://kubernetes.io/docs/concepts/containers/runtime-class/) + +特性状态：Kubernetes v1.14 beta + +## RuntimeClass + +使用 RuntimeClass 这一特性可以为容器选择运行时的容器引擎。 + +## 设计目标 + +可以通过 RuntimeClass，使不同的 Pod 使用不同的容器引擎，以在性能和安全之间取得平衡。例如，如果某些工作负载需要非常高的信息安全保证，您可能将其 Pod 运行在那种使用硬件虚拟化的容器引擎上；同时，将其他的 Pod 运行在另外一种容器引擎上，以获得更高的性能。 + +也可以通过 RuntimeClass 配置，使不同的 Pod 使用相同的容器引擎，但是不同的容器引擎设定。 + +### 配置步骤 + +确保 RuntimeClass 的 feature gate 在 apiserver 和 kubelet 上都是是激活状态（默认是激活的，请参考 [Feature Gates](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/)）。 + +#### 在节点上配置 CRI + +如需通过RuntimeClass进行配置，是依赖于 Container Runtime Interface（CRI）的具体实现的。 + +配置 CRI 时，请留意其 `handler` 名称（该名称是有 字符/数字 和 `-` 组成的字符串），RuntimeClass中将引用该名称。 + +::: tip +RuntimeClass默认要求集群中所有节点上的容器引擎的配置都是相同的。在Kubernetes v1.16中才开始引入对节点上容器引起不同的情况下的支持（本文暂不讨论这部分内容） +::: + +安装 CRI 请参考文档 [CRI installation](https://kubernetes.io/docs/setup/production-environment/container-runtimes/) + +* dockershim + + Kubernetes 内建的 dockershim CRI 不支持 RuntimeClass + +* [containerd](https://containerd.io/) + + 通过 containerd 的配置文件 `/etc/containerd/config.toml` 配置其 Runtime handler。请注意该文档的如下内容 + + ``` + [plugins.cri.containerd.runtimes.${HANDLER_NAME}] + ``` + + 更多细节请参考 [https://github.com/containerd/cri/blob/master/docs/config.md](https://github.com/containerd/cri/blob/master/docs/config.md) + +* [cri-o](https://cri-o.io/) + + 通过 cri-o 的配置文件 `/etc/crio/crio.conf` 配置 Runtime handler。请注意该文档的 [crio.runtime table](https://github.com/kubernetes-sigs/cri-o/blob/master/docs/crio.conf.5.md#crioruntime-table) + + ``` + [crio.runtime.runtimes.${HANDLER_NAME}] + runtime_path = "${PATH_TO_BINARY}" + ``` + + 更多细节请参考文档 [https://github.com/kubernetes-sigs/cri-o/blob/master/cmd/crio/config.go](https://github.com/kubernetes-sigs/cri-o/blob/master/cmd/crio/config.go) + + + +#### 创建对应的 RuntimeClass + +在前面的步骤中完成了配置之后，每个配置都会有一个 `handler` 名称，用来唯一地标识该 CRI 的配置。此时，我们需要为每一个 handler 创建一个对应的 RuntimeClass api 对象。 + +RuntimeClass 目前只有两个主要的字段： +* RuntimeClass name（`metadata.name`） +* handler (`handler`) + +该对象的定义如下所示： + +``` yaml +apiVersion: node.k8s.io/v1beta1 +kind: RuntimeClass +metadata: + name: myclass # RuntimeClass 没有名称空间 +handler: myconfiguration # 对应 CRI 配置的 handler 名称 +``` + +::: tip +建议只让集群管理员可以修改（create/update/pacth/delete） RuntimeClass，这也是集群的默认配置。请参考 [Authorization Overview](https://kubernetes.io/docs/reference/access-authn-authz/authorization/) +::: + +### 使用 + +为集群完成 RuntimeClass 的配置后，使用的时候会非常简单。在 Pod 的定义中指定 `runtimeClassName` 即可，例如： + +``` yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + runtimeClassName: myclass + # ... +``` + +kubelet 将依据这个字段使用指定的 RuntimeClass 来运行该 Pod。如果指定的 RuntimeClass 不存在，或者 CRI 不能运行对应的 handler 配置，则 Pod 将进入 `Failed` 这个终止 [阶段](/learning/k8s-intermediate/workload/pod-lifecycle.html#pod-phase)。此时可通过 Pod 中的 Event（事件）来查看具体的出错信息。 + +如果 Pod 中未指定 `runtimeClassName`，kubelet 将使用默认的 RuntimeHandler 运行 Pod，其效果等价于 RuntimeClass 这个特性被禁用的情况。 + +##