优化 StarGazer,Deployment 教程
This commit is contained in:
@ -5,4 +5,101 @@ description: 本文介绍了 Kubernetes Deployment 的概念、行为及使用
|
||||
|
||||
# 控制器 - Deployment
|
||||
|
||||
正在撰写...
|
||||
参考文档: Kubernetes 官网 [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)
|
||||
|
||||
术语表
|
||||
|
||||
| 英文 | 英文简称 | 中文 |
|
||||
| ---------- | ---------- | ------ |
|
||||
| Pod | Pod | 容器组 |
|
||||
| Controller | Controller | 控制器 |
|
||||
| ReplicaSet | ReplicaSet | 副本集 |
|
||||
| Deployment | Deployment | 部署 |
|
||||
|
||||
|
||||
|
||||
## 背景知识
|
||||
|
||||
### Pod 容器组
|
||||
|
||||
Pod 容器组是 Kubernetes 中最小的调度单元,更多信息请参考 [容器组 - 概述](./pod.html)
|
||||
|
||||
### ReplicaSet 副本集
|
||||
|
||||
ReplicaSet 副本集的用途是为指定的 Pod 维护一个副本(实例)数量稳定的集合。下面是一个定义 ReplicaSet 副本集的 yaml 文件:
|
||||
|
||||
``` yaml {8,9,12}
|
||||
apiVersion: apps/v1
|
||||
kind: ReplicaSet
|
||||
metadata:
|
||||
name: frontend
|
||||
labels:
|
||||
tier: frontend
|
||||
spec:
|
||||
replicas: 3
|
||||
selector:
|
||||
matchLabels:
|
||||
tier: frontend
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
tier: frontend
|
||||
spec:
|
||||
containers:
|
||||
- name: php-redis
|
||||
image: gcr.io/google_samples/gb-frontend:v3
|
||||
```
|
||||
|
||||
ReplicaSet 副本集的主要几个字段有:
|
||||
* selector 确定哪些 Pod 属于该副本集
|
||||
* replicas 副本集应该维护几个 Pod 副本(实例)
|
||||
* template Pod 的定义
|
||||
|
||||
副本集将通过创建、删除 Pod 容器组来确保符合 selector 选择器的 Pod 数量等于 replicas 指定的数量。当符合 selector 选择器的 Pod 数量不够时,副本集通过使用 template 中的定义来创建 Pod。
|
||||
|
||||
在 Kubernetes 中,并不建议您直接使用 ReplicaSet,推荐使用 Deployment,由 Deployment 创建和管理 ReplicaSet。
|
||||
|
||||
## Deployment 概述
|
||||
|
||||
Deployment 是最常用的用于部署无状态服务的方式。Deployment 控制器使得您能够以声明的方式更新 Pod(容器组)和 ReplicaSet(副本集)。
|
||||
|
||||
::: tip
|
||||
声明的方式是相对于非声明方式而言的。例如,以滚动更新为例,假设有 3 个容器组,现需要将他们的容器镜像更新为新的版本。
|
||||
* 非声明的方式,您需要手动逐步执行以下过程:
|
||||
* 使用 kubectl 创建一个新版本镜像的容器组
|
||||
* 使用 kubectl 观察新建容器组的状态
|
||||
* 新建容器组的状态就绪以后,使用 kubectl 删除一个旧的容器组
|
||||
* 重复执行上述过程,直到所有容器组都已经替换为新版本镜像的容器组
|
||||
* 声明的方式,您只需要执行:
|
||||
* 使用 kubectl 更新 Deployment 定义中 spec.template.spec.containers[].image 字段
|
||||
> Deployment 实际执行滚动更新时的行为,本文后面有详细描述
|
||||
:::
|
||||
|
||||
以“声明”的方式管理 Pod 和 ReplicaSet,其本质是将一些特定场景的一系列运维步骤固化下来,以便快速准确无误的执行。Deployment 为我们确定了如下几种运维场景:
|
||||
|
||||
* [创建Deployment](#创建deployment) 创建 Deployment 后,Deployment 控制器将立刻创建一个 ReplicaSet 副本集,并由 ReplicaSet 创建所需要的 Pod。
|
||||
* [更新Deployment](#更新deployment) 更新 Deployment 中 Pod 的定义(例如,发布新版本的容器镜像)。此时 Deployment 控制器将为该 Deployment 创建一个新的 ReplicaSet 副本集,并且逐步在新的副本集中创建 Pod,在旧的副本集中删除 Pod,以达到滚动更新的效果。
|
||||
* [回滚Deployment](#回滚deployment) 回滚到一个早期 Deployment 版本。
|
||||
* [伸缩Deployment](#伸缩deployment) 水平扩展 Deployment,以便支持更大的负载,或者水平收缩 Deployment,以便节省服务器资源。
|
||||
* [暂停和继续Deployment](#暂停和继续deployment) 暂停正在进行的滚动更新,继续正在进行的滚动更新。
|
||||
* [查看Deployment状态](#查看deployment状态)
|
||||
* [清理旧的ReplicaSet](#清理旧的replicaset)
|
||||
* [金丝雀发布](#金丝雀发布)
|
||||
|
||||
## 创建Deployment
|
||||
|
||||
未完待续,最后更新时间:2019年9月9日 22:50
|
||||
|
||||
## 更新Deployment
|
||||
|
||||
## 回滚Deployment
|
||||
|
||||
## 伸缩Deployment
|
||||
|
||||
## 暂停和继续Deployment
|
||||
|
||||
## 查看Deployment状态
|
||||
|
||||
## 清理旧的ReplicaSet
|
||||
|
||||
## 金丝雀发布
|
||||
|
||||
@ -7,14 +7,14 @@ description: 本文介绍了 Kubernetes Controller(控制器)的概念,以
|
||||
|
||||
Pod(容器组)是 Kubernetes 中最小的调度单元,您可以通过 kubectl 直接创建一个 Pod。Pod 本身并不能自愈(self-healing)。如果一个 Pod 所在的 Node (节点)出现故障,或者调度程序自身出现故障,Pod 将被删除;同理,当因为节点资源不够或节点维护而驱逐 Pod 时,Pod 也将被删除。
|
||||
|
||||
Kubernetes 通过引入 Controller(控制器)的概念来管理 Pod 实例。在 Kubernetes 中,<font color="red">您应该始终通过创建 Controller 来创建 Pod,而不是直接创建 Pod</font>。控制器可以提供如下特性:
|
||||
Kubernetes 通过引入 Controller(控制器)的概念来管理 Pod 实例。在 Kubernetes 中,<font color="red">您应该始终通过创建 Controller 来创建 Pod,而不是直接创建 Pod</font>。**控制器可以提供如下特性:**
|
||||
* 水平扩展(运行 Pod 的多个副本)
|
||||
* rollout(版本更新)
|
||||
* self-healing(故障恢复)
|
||||
|
||||
例如:当一个节点出现故障,控制器可以自动地在另一个节点调度一个配置完全一样的 Pod,以替换故障节点上的 Pod。
|
||||
|
||||
在 Kubernetes 中,广泛使用的控制器有:
|
||||
|
||||
**在 Kubernetes 支持的控制器有如下几种:**
|
||||
|
||||
* [Deployment](./wl-deployment.html) <Badge text="Kuboard 已支持" type="success"/>
|
||||
* [StatefulSet](./wl-statefulset.html) <Badge text="Kuboard 已支持" type="success"/>
|
||||
@ -23,7 +23,22 @@ Kubernetes 通过引入 Controller(控制器)的概念来管理 Pod 实例
|
||||
* [CronJob](./wl-cronjob.html) <Badge text="Kuboard 正在计划中" type="warn"/>
|
||||
* [Jobs - Run to Completion](./wl-job.html) <Badge text="Kuboard 正在计划中" type="warn"/>
|
||||
|
||||
* ReplicaSet <Badge text="Kuboard 暂不支持" type="warn"/>
|
||||
* ReplicationController <Badge text="Kuboard 暂不支持" type="warn"/>
|
||||
* Garbage Collection <Badge text="Kuboard 暂不支持" type="warn"/>
|
||||
* TTL Controller for Finished Resources <Badge text="Kuboard 暂不支持" type="warn"/>
|
||||
* [ReplicaSet](https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/)<Badge text="使用 Deployment" type="error"/>
|
||||
|
||||
> Kubernetes 官方推荐使用 Deployment 替代 ReplicaSet
|
||||
|
||||
* [ReplicationController](https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller/) <Badge text="使用 Deployment" type="error"/>
|
||||
|
||||
> Kubernetes 官方推荐使用 Deployment 替代 ReplicationController
|
||||
|
||||
* [Garbage Collection](https://kubernetes.io/docs/concepts/workloads/controllers/garbage-collection/)
|
||||
|
||||
> Kuboard 暂时不支持
|
||||
|
||||
* [TTL Controller for Finished Resources](https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/)
|
||||
|
||||
> Kuboard 暂时不支持
|
||||
|
||||
::: tip
|
||||
常规的部署任务中所需要的控制器类型,Kuboard 都已经支持。以典型的 Spring Cloud 等微服务框架而言,Kuboard 已经可以非常好地对其进行运维和管理。
|
||||
:::
|
||||
|
||||
Reference in New Issue
Block a user