duolatech

Deployment 的生命周期中会有许多状态。上线新的 ReplicaSet 期间可能处于 Progressing（进行中），可能是 Complete（已完成），也可能是 Failed（失败）以至于无法继续进行。

在你更新一个 Deployment 的时候， 你可以在触发一个或多个更新之前暂停 Deployment 的上线过程。当你准备应用这些变更时，你可以重新恢复 Deployment 上线过程。

默认情况下，Deployment 的所有上线记录都保留在系统中，以便可以随时回滚 （你可以通过修改修订历史记录限制来更改这一约束）。Deployment 被触发上线时，系统就会创建 Deployment 的新的修订版本。这意味着仅当 Deployment 的 Pod 模板（）发生更改时，才会创建新修订版本 -- 例如，模板的标签或容器镜像发生变化。其他更新，如 Deployment 的扩缩容操作不会创建 Deployment 修订版本。这是为了方便同时执行手动缩放或自动缩放。

例如，如果仔细查看上述 Deployment ，将看到它首先创建了一个新的 Pod，然后删除旧的 Pod， 并创建了新的 Pod。它不会杀死旧 Pod，直到有足够数量的新 Pod 已经出现。在足够数量的旧 Pod 被杀死前并没有创建新 Pod。Deployment 还确保仅所创建 Pod 数量只可能比期望 Pod 数高一点点。默认情况下，它可确保启动的 Pod 个数比期望个数最多多出 125%（最大峰值 25%）。Deployment 可确保在更新时仅关闭一定数量的 Pod。

下面是一个 Deployment 示例。其中创建了一个 ReplicaSet，负责启动三个。该名称将成为所创建的 Pod 的命名基础。其中 的。注意 ReplicaSet 的名称格式始终为。字符串与 ReplicaSet 上的。请注意期望副本数是根据。

而 Deployment 控制器（Controller） 以受控速率更改实际状态， 使其变为期望状态。你可以定义 Deployment 以创建新的 ReplicaSet，或删除现有 Deployment， 并通过新的 Deployment 收养其资源。一个 Deployment 为 Pod 和 ReplicaSet 提供声明式的更新能力。查看Deployment资源对象的组成部分。你负责描述 Deployment 中的。查看Deployment下的spec字段。

这实际上意味着，你可能永远不需要操作 ReplicaSet 对象：而是使用 Deployment，并在 spec 部分定义你的应用。

【代码】k8s Context。

在 Kubernetes 中，名字空间（Namespace）提供一种机制，将同一集群中的资源划分为相互隔离的组。同一名字空间内的资源名称要唯一，但跨名字空间时没有这个要求。名字空间作用域仅针对带有名字空间的对象， （例如 Deployment、Service 等），这种作用域对集群范围的对象 （例如 StorageClass、Node、PersistentVolume 等）不适用。

启动 Pod 的体面关闭逻辑的同时，控制平面会评估是否将关闭的 Pod 从对应的 EndpointSlice（和端点）对象中移除，过滤条件是 Pod 被对应的服务以某 选择算符选定。任何正在终止的 Pod 所对应的端点都不会立即从 EndpointSlice 中被删除，EndpointSlice API（以及传统的 Endpoints API）会公开一个状态来指示其处于 终止状态。当你请求删除某个 Pod 时，集群会记录并跟踪 Pod 的体面终止周期， 而不是直接强制地杀死 Pod。会触发强制关闭过程。

ReadyfalseHTTP Probes 允许针对httpGethostschemepathport对于 HTTP 探测，kubelet 发送一个 HTTP 请求到指定的路径和端口来执行检测。除非httpGet中的host字段设置了，否则 kubelet 默认是给 Pod 的 IP 地址发送探测。如果scheme字段设置为了HTTPS，kubelet 会跳过证书验证发送 HTTPS 请求。大多数情况下，不需要设置host字段。这里有个需要设置host。

这个例子展示了如何配置 Kubernetes 以将其用于应用程序的存活性检查。类似地，你可以配置就绪探针和启动探针。如果你的应用实现了 gRPC 健康检查协议， kubelet 可以配置为使用该协议来执行应用存活性检查。要使用 gRPC 探针，必须配置。

这个例子展示了如何配置 Kubernetes 以将其用于应用程序的存活性检查。类似地，你可以配置就绪探针和启动探针。如果你的应用实现了 gRPC 健康检查协议， kubelet 可以配置为使用该协议来执行应用存活性检查。要使用 gRPC 探针，必须配置。

另外一种类型的存活探测方式是使用 HTTP GET 请求。下面是一个 Pod 的配置文件kind: Podmetadata:labels:spec:ports:httpGet:path: /port: 80在这个配置文件中，你可以看到 Pod 也只有一个容器。字段指定了 kubelet 每隔 3 秒执行一次存活探测。字段告诉 kubelet 在执行第一次探测前应该等待 3 秒。kubelet 会向容器内运行的服务（服务在监听 8080 端口）发送一个 HTTP GET 请求来执行探测。

许多长时间运行的应用最终会进入损坏状态，除非重新启动，否则无法被恢复。Kubernetes 提供了存活探针来发现并处理这种情况。在本练习中，你会创建一个 Pod，其中运行一个基于busybox镜像的容器。下面是这个 Pod 的配置文件。sleep 600exec:command:- cat在这个配置文件中，可以看到 Pod 中只有一个Container。

如果就绪态探测失败， 端点控制器将从与 Pod 匹配的所有服务的端点列表中删除该 Pod 的 IP 地址。如果端口打开，则诊断被认为是成功的。如果远程系统（容器）在打开连接后立即将其关闭，这算作是健康的。如果存活态探测失败，则 kubelet 会杀死容器， 并且容器将根据其重启策略决定未来。要执行诊断，kubelet 既可以在容器内执行代码，也可以发出一个网络请求。如果提供了启动探针，则所有其他探针都会被 禁用，直到此探针成功为止。如果响应的状态码大于等于 200 且小于 400，则诊断被认为是成功的。

字段，其可能取值包括 Always、OnFailure 和 Never。默认值是 Always。会按指数回退方式计算重启的延迟（10s、20s、40s、...），其最长延迟为 5 分钟。当 Pod 中的容器退出时，适用于 Pod 中的所有容器。

当你最初创建一个 Deployment、 StatefulSet、Pod 或者其他包含 Pod 模板的对象时，如果没有显式设定的话， Pod 中所有容器的默认镜像拉取策略是。这一策略会使得 kubelet 在镜像已经存在的情况下直接略过拉取镜像的操作。

Kubernetes 会跟踪 Pod 中每个容器的状态，就像它跟踪 Pod 总体上的阶段一样。一旦 Pod 被调度（分派）到某个节点，Pod 会一直在该节点运行，直到 Pod 停止或者被终止。状态的容器仍在运行它完成启动所需要的操作：例如， 从某个容器镜像仓库拉取容器镜像，或者向容器应用 Secret 数据等等。状态的容器的 Pod 时，你也会看到一个 Reason 字段，其中给出了容器处于等待状态的原因。状态的容器的 Pod 时， 你会看到容器进入此状态的原因、退出代码以及容器执行期间的起止时间。

Pod是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。Pod（就像在鲸鱼荚或者豌豆荚中）是一组（一个或多个） 容器；这些容器共享存储、网络、以及怎样运行这些容器的声明。Pod 中的内容总是并置（colocated）的并且一同调度，在共享的上下文中运行。Pod 所建模的是特定于应用的 “逻辑主机”，其中包含一个或多个应用容器， 这些容器相对紧密地耦合在一起。Pod 的共享上下文包括一组 Linux 名字空间、控制组（cgroup）和可能一些其他的隔离方面， 即用来隔离容器的技术。

当你部署完 Kubernetes，便拥有了一个完整的集群。一组工作机器，称为 节点， 会运行容器化应用程序。每个集群至少有一个工作节点。工作节点会托管 Pod ，而 Pod 就是作为应用负载的组件。控制平面管理集群中的工作节点和 Pod。在生产环境中，控制平面通常跨多台计算机运行， 一个集群通常运行多个节点，提供容错性和高可用性。本文档概述了一个正常运行的 Kubernetes 集群所需的各种组件。Kubernetes 集群的组件。

kubectl 是使用 Kubernetes API 与 Kubernetes 集群的控制面进行通信的命令行工具。- 基于文件、标准输入或通过指定标签选择器、名称、资源选择器或资源来删除资源。- 显示一个或多个资源的详细状态，默认情况下包括未初始化的资源。- 以文件或标准输入为准应用或更新资源。- 对 Pod 中的容器执行命令。- 打印 Pod 中容器的日志。- 查看集群建议更新的差异。- 列出一个或多个资源。

containerd 命令。

打开recommended.yaml, 找到kind: Service 后，添加红框中的type、nodePort。（默认Dashboard只能集群内部访问，修改Service参数使其可以外网访问）pod状态为Running后，在浏览器中输入 https://172.16.234.153:32000/#/login。172.16.234.153（k8s-master节点IP）32000（上方设置的nodePort）目前最新版v2.7支持kubernetes 1.25以上版本。1. 创建admin用户。

metrics-server 是一个集群范围内的资源数据集和工具，同样的，metrics-server 也只是显示数据，并不提供数据存储服务，主要关注的是资源度量 API 的实现，比如 CPU、文件描述符、内存、请求延时等指标，metric-server 收集数据给 k8s 集群内使用。使用kubectl top 命令查看node和pod的cpu和内存。安装，目前最新版是v0.6.3。

输入k8s-master节点的IP（172.16.234.153）+端口号。Pod 是一个 K8S 最核心的资源对象，是最小的调度单位。创建一个简单的nginx pod。

说明：此时在node节点（k8s-node01、k8s-node02）查看集群节点时。控制节点（k8s-master）初始化。查看指定版本的镜像文件。提前拉取指定版本的镜像。

在集群中的每个节点上用来启动 Pod 和容器等。：用来与集群通信的命令行工具。：用来初始化集群的指令。

containerd 安装

k8s安装准备