Adsense
This commit is contained in:
huanqing.shao
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 将容器组调度到指定的节点
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
参考文档： Kubernetes 官网 [Assigning Pods to Nodes](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/)
|
||||
|
||||
## 概述
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 管理容器的计算资源
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
参考文档： Kubernetes 官网 [Managing Compute Resources for Containers](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/)
|
||||
|
||||
## 概述
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 使用ConfigMap配置您的应用程序
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
本文参考了 Kubernetes 官网 [Configure a Pod to Use a ConfigMap](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap)，并有所改写
|
||||
|
||||
Kubernetes ConfigMap 可以将配置信息和容器镜像解耦，以使得容器化的应用程序可移植。本文提供了一系列的实例，解释如何通过 Kuboard 创建 ConfigMap 以及如何使用 ConfigMap 中的数据配置 Pod（容器组）。
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 为容器设置Linux Capabilities
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
使用 [Linux Capabilities](http://man7.org/linux/man-pages/man7/capabilities.7.html) 可以为容器内的进程授予某些特定的权限（而不是 root 用户的所有权限）。在容器定义的 `securityContext` 中添加 `capabilities` 字段，可以向容器添加或删除 Linux Capability。
|
||||
|
||||
本文后续章节中，先运行一个不包含 `capabilities` 字段的容器，观察容器内进程的 linux capabilities 位图的情况；然后在运行一个包含 `capabilities` 字段的容器，比较其 linux capabilities 位图与前者的不同。
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# Kuboard中容器的Security Context
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
通过 Kuboard，可以直接设定 Deployment、StatefulSet、DaemonSet 等中容器的 securityContext 的内容。在 Kuboard 工作负载编辑器界面中点击 **容器组的更多设定** 按钮，可查看到容器的 Security Context 设置界面，如下图所示：
|
||||
|
||||
|
||||
@ -28,4 +30,3 @@ meta:
|
||||
| procMount | string | procMount 代表了容器的 proc mount 的类型。默认值是 `DefaultProcMount`（使用容器引擎的默认值）。该字段需要激活 Kubernetes 的ProcMountType 特性 |
|
||||
| capabilities | <div style="width: 80px;">add: array<br />drop: array</div> | 为容器进程 add/drop Linux capabilities。默认使用容器引擎的设定。更多内容请参考 [为容器设置Linux Capabilities](./con-cap.html) |
|
||||
| seLinuxOptions | | 此字段设定的 SELinux 上下文将被应用到 Pod 中所有容器。如果不指定，容器引擎将为每个容器分配一个随机的 SELinux 上下文。<font color="grey">也可以在Pod的SecurityContext中设定，如果 Pod 和容器的 securityContext 中都设定了这个字段，则对该容器来说以容器中的设置为准。</font> |
|
||||
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 为容器设置SELinux标签
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
Pod 或容器定义的 `securityContext` 中 `seLinuxOptions` 字段是一个 [SELinuxOptions](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.16/#selinuxoptions-v1-core) 对象，该字段可用于为容器指定 SELinux 标签。如下所示：
|
||||
|
||||
``` yaml
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 为容器设置Security Context
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
容器的定义中包含 `securityContext` 字段，该字段接受 [SecurityContext](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.16/#securitycontext-v1-core) 对象。通过指定该字段，可以为容器设定安全相关的配置，当该字段的配置与 Pod 级别的 `securityContext` 配置相冲突时，容器级别的配置将覆盖 Pod 级别的配置。容器级别的 `securityContext` 不影响 Pod 中的数据卷。
|
||||
|
||||
下面的示例中的 Pod 包含一个 Container，且 Pod 和 Container 都有定义 `securityContext` 字段：
|
||||
|
||||
@ -10,6 +10,8 @@ meta:
|
||||
|
||||
# 概述
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
> 参考文档：Kubernetes 官网文档 [Configure a Security Context for a Pod or Container](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#assign-selinux-labels-to-a-container)
|
||||
|
||||
Security Context（安全上下文）用来限制容器对宿主节点的可访问范围，以避免容器非法操作宿主节点的系统级别的内容，使得节点的系统或者节点上其他容器组受到影响。
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# Kuboard中Pod的Security Context
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
通过 Kuboard，可以直接设定 Deployment、StatefulSet、DaemonSet 等中 Pod 模板的 securityContext 的内容。在 Kuboard 工作负载编辑器界面中点击 **容器组的更多设定** 按钮，可查看到 Pod 的 Security Context 设置界面，如下图所示：
|
||||
|
||||
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 为Pod设置Security Context
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
在 Pod 的定义中增加 `securityContext` 字段，即可为 Pod 指定 Security 相关的设定。 `securityContext` 字段是一个 [PodSecurityContext](./pod-kuboard.html) 对象。通过该字段指定的内容将对该 Pod 中所有的容器生效。
|
||||
|
||||
## Pod示例
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 关于数据卷
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
Pod 的 securityContext 作用于 Pod 中所有的容器，同时对 Pod 的数据卷也同样生效。具体来说，`fsGroup` 和 `seLinuxOptions` 将被按照如下方式应用到 Pod 中的数据卷：
|
||||
* `fsGroup`：对于支持 ownership 管理的数据卷，通过 `fsGroup` 指定的 GID 将被设置为该数据卷的 owner，并且可被 `fsGroup` 写入。更多细节请参考 [Ownership Management design document](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/volume-ownership-management.md)
|
||||
* `seLinuxOptions`：对于支持 SELinux 标签的数据卷，将按照 `seLinuxOptions` 的设定重新打标签，以使 Pod 可以访问数据卷内容。通常您只需要设置 `seLinuxOptions` 中 `level` 这一部分内容。该设定为 Pod 中所有容器及数据卷设置 [Multi-Category Security (MCS)](https://selinuxproject.org/page/NB_MLS) 标签。
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 创建Secret（使用Generator）
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
从 kubernetes v1.14 开始，kubectl 集成了 [Kustomize](https://kustomize.io/)。通过 Kustomize，您可以使用 generator（Kustomize 的概念）创建 Secret，并保存到 API Server。Generator 必须在 `kustomization.yaml` 文件中指定。
|
||||
|
||||
::: tip
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 创建Secret（使用kubectl）
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
假设某个 Pod 需要访问数据库。在您执行 kubectl 命令所在机器的当前目录，创建文件 `./username.txt` 文件和 `./password.txt` 暂存数据库的用户名和密码，后续我们根据这两个文件配置 kubernetes secrets。
|
||||
|
||||
```sh
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 创建Secret（使用Kuboard）
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
本文简要描述如何在 Kuboard 中创建 Kubernetes Secret。
|
||||
|
||||
Kubernetes Secret 必须从属于某一个名称空间，进入 Kuboard 名称空间界面，Secret 列表在名称空间的左上角。如下图所示：
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 创建Secret（手动）
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
和创建其他类型的 API 对象（Pod、Deployment、StatefulSet、ConfigMap 等）一样，您也可以先在 yaml 文件中定义好 Secret，然后通过 `kubectl apply -f` 命令创建。此时，您可以通过如下两种方式在 yaml 文件中定义 Secret：
|
||||
* **data**：使用 data 字段时，取值的内容必须是 base64 编码的
|
||||
* **stringData**：使用 stringData 时，更为方便，您可以直接将取值以明文的方式写在 yaml 文件中
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 解码和编辑Secret
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
## 解码Secret
|
||||
|
||||
Secret 中的信息可以通过 `kubectl get secret` 命令获取。例如，执行命令 `kubectl get secret mysecret -o yaml
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# Secret概述
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
参考文档： Kubernetes 官网文档 [Secrets](https://kubernetes.io/docs/concepts/configuration/secret/)
|
||||
|
||||
## 概述
|
||||
|
||||
@ -9,7 +9,7 @@ meta:
|
||||
|
||||
# 使用Secret存储Ingress TLS证书
|
||||
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
可以直接在 Ingress 中配置 HTTPS 证书，使得你的网站支持 HTTPS 协议。
|
||||
|
||||
|
||||
@ -10,6 +10,8 @@ meta:
|
||||
|
||||
# 概述
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
> 参考文档： Kubernetes 官网文档 [Taints and Tolerations](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/)
|
||||
|
||||
Pod 中存在属性 [Node selector / Node affinity](/learning/k8s-intermediate/config/assign-pod-node.html)，用于将 Pod 指定到合适的节点。
|
||||
|
||||
@ -10,6 +10,8 @@ meta:
|
||||
|
||||
# 基于污点的驱逐（TaintBasedEviction）
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
在前面的章节中，我们描述了 [NoExecute](/learning/k8s-intermediate/config/taints-toleration/#污点与容忍的匹配) 的污点效果，该效果将对已经运行在节点上的 Pod 施加如下影响：
|
||||
* 不容忍该污点的 Pod 将立刻被驱逐
|
||||
* 容忍该污点的 Pod 在未指定 `tolerationSeconds` 的情况下，将继续在该节点上运行
|
||||
|
||||
@ -10,6 +10,8 @@ meta:
|
||||
|
||||
# 条件化的污点（TaintNodesByCondition）
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
自 Kubernetes 1.12 开始，`TaintNodesByCondition` 这个特性进入 beta 阶段，此时节点控制器自动根据 Node Condition 为节点创建对应的污点。调度器则不去检查 Node conditions，而是检查节点的污点，因此 Node Condition 不再直接影响到调度程序。用户通过为 Pod 添加容忍，可以选择性地忽略节点的某些问题（以 Node Condition 呈现的问题）。
|
||||
|
||||
`TaintNodesByCondition` 这个特性只会为节点添加 `NoSchedule` 效果的污点。`TaintBasedEviction` （Kubernetes 1.13 开始默认生效）则为节点添加 `NoExecute` 效果的污点，参考 [TaintBasedEviction](./taint-based-evictions.html)。
|
||||
|
||||
@ -10,6 +10,8 @@ meta:
|
||||
|
||||
# 使用案例
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
污点和容忍使用起来非常灵活，可以用于：
|
||||
* 避免 Pod 被调度到某些特定的节点
|
||||
* 从节点上驱逐本不应该在该节点运行的 Pod
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 容器的环境变量
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
> 参考文档： [Container Environment Variables](https://kubernetes.io/docs/concepts/containers/container-environment-variables/)
|
||||
|
||||
Kubernetes为容器提供了一系列重要的资源：
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 容器镜像
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
在 Kubernetes 的 Pod 中使用容器镜像之前，您必须将其推送到一个镜像仓库（或者使用仓库中已经有的容器镜像）。在 Kubernetes 的 Pod 定义中定义容器时，必须指定容器所使用的镜像，容器中的 `image` 字段支持与 `docker` 命令一样的语法，包括私有镜像仓库和标签。
|
||||
|
||||
例如：`my-registry.example.com:5000/example/web-example:v1.0.1` 由如下几个部分组成：
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 容器生命周期事件处理
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
> 参考文档： [Attach Handlers to Container Lifecycle Events](https://kubernetes.io/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)
|
||||
|
||||
Kubernetes 中支持容器的 postStart 和 preStop 事件，本文阐述了如何向容器添加生命周期事件处理程序（handler）。
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 容器生命周期
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
> 参考文档： [Container Lifecycle Hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/)
|
||||
|
||||
本文描述了 kubelet 管理的容器如何使用容器生命周期钩子执行指定的代码。
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# Runtime Class
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
> 参考文档： [Runtime Class](https://kubernetes.io/docs/concepts/containers/runtime-class/)
|
||||
|
||||
特性状态：Kubernetes v1.14 <Badge type="warning">beta</Badge>
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 搭建NFS Server
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
## 背景
|
||||
|
||||
Kubernetes 对 Pod 进行调度时，以当时集群中各节点的可用资源作为主要依据，自动选择某一个可用的节点，并将 Pod 分配到该节点上。在这种情况下，Pod 中容器数据的持久化如果存储在所在节点的磁盘上，就会产生不可预知的问题，例如，当 Pod 出现故障，Kubernetes 重新调度之后，Pod 所在的新节点上，并不存在上一次 Pod 运行时所在节点上的数据。
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 存储卷PersistentVolume
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
参考文档： Kubernetes 官方文档 [Persistent Volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/)
|
||||
|
||||
## 概述
|
||||
|
||||
@ -8,6 +8,7 @@ meta:
|
||||
|
||||
# 数据卷类型如何选择
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
# 存储卷类型如何选择
|
||||
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 存储类StorageClass
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
参考文档： Kubernetes 官网 [Storage Classes](https://kubernetes.io/docs/concepts/storage/storage-classes/)
|
||||
|
||||
## 存储类概述
|
||||
|
||||
@ -8,6 +8,8 @@ meta:
|
||||
|
||||
# 数据卷-挂载
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
参考文档： Kubernetes 官网文档 [Volumes](https://kubernetes.io/docs/concepts/storage/volumes/)
|
||||
|
||||
## 容器内路径
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 数据卷Volume
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
参考文档： Kubernetes 官网文档 [Volumes](https://kubernetes.io/docs/concepts/storage/volumes/)
|
||||
|
||||
## 数据卷概述
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 使用私有仓库中的docker镜像
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
企业通常会因为如下几个原因，需要搭建自己的私有 docker registry：
|
||||
* 限制 docker 镜像的分发范围，例如：只允许在内网分发，或者只允许被授权的用户获取 docker 镜像
|
||||
* 提高推送 docker 镜像以及抓取 docker 镜像时的网络传输速度
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 如何选择网络插件
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
本文转载自： [kubernetes网络插件对比分析（flannel、calico、weave）](https://www.toutiao.com/a6708893686517727748/)
|
||||
|
||||
原文作者：残花花败柳柳
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# Service连接应用程序
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
参考文档： Kubernetes 官网文档 [Connecting Applications with Services](https://kubernetes.io/docs/concepts/services-networking/connect-applications-service/)
|
||||
|
||||
## Kubernetes 的网络模型
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# Service/Pod的DNS
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
参考文档： Kubernetes 官网文档 [DNS for Services and Pods](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/)
|
||||
|
||||
本文介绍了 Kubernetes 中的 DNS 分配方式
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# Ingress通过互联网访问您的应用
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
参考文档：
|
||||
* Kubernetes 官网 [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/)
|
||||
* Kubernetes 官网 [Ingress Controllers](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/)
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# Service详细描述
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
参考文档：Kubernetes 官网文档：[Service](https://kubernetes.io/docs/concepts/services-networking/service/)
|
||||
|
||||
## 创建 Service
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 发布Service
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
Kubernetes Service 支持的不同访问方式。
|
||||
|
||||
## Service 类型
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# Service概述
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
参考文档：Kubernetes 官网文档：[Service](https://kubernetes.io/docs/concepts/services-networking/service/)
|
||||
|
||||
## 为何需要 Service
|
||||
|
||||
@ -11,6 +11,8 @@ meta:
|
||||
|
||||
参考文档： Kubernetes 官网 [Init Containers](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/)
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
## 初始化容器介绍
|
||||
|
||||
Pod 可以包含多个工作容器，也可以包含一个或多个初始化容器，初始化容器在工作容器启动之前执行。
|
||||
|
||||
@ -7,6 +7,8 @@ meta:
|
||||
|
||||
# 容器组_Kuboard
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
## 通过 Kuboard 创建容器组
|
||||
|
||||
由于在 Kubernetes 中，任何时候都是不推荐用户直接创建容器组，而是应该通过控制器创建容器组，Kuboard 管理工具并不提供直接创建容器组的界面，而是通过 **工作负载编辑器** 创建 Deployment、StatefulSet、DaemonSet 等方式来创建容器组。
|
||||
|
||||
@ -11,6 +11,8 @@ meta:
|
||||
|
||||
参考文档： Kubernetes 官网文档 [Pod Lifecycle](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/)
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
[[TOC]]
|
||||
|
||||
## Pod phase
|
||||
|
||||
@ -7,6 +7,7 @@ meta:
|
||||
|
||||
# 容器组_Privileged 模式
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
## Privilged 模式运行容器
|
||||
|
||||
|
||||
@ -11,6 +11,8 @@ meta:
|
||||
|
||||
参考文档：Kubernetes 官方文档 [Pod Overview](https://kubernetes.io/docs/concepts/workloads/pods/pod-overview/) [Pods](https://kubernetes.io/docs/concepts/workloads/pods/pod/)
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
术语中英文对照：
|
||||
|
||||
| 英文全称 | 英文缩写 | 中文翻译 |
|
||||
|
||||
@ -11,6 +11,8 @@ meta:
|
||||
|
||||
> 参考文档： Kubernetes 官网文档 [Alternatives to DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/#alternatives-to-daemonset)
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
DaemonSet 有如下替代选项可以选择
|
||||
|
||||
## Init Scripts
|
||||
|
||||
@ -11,6 +11,8 @@ meta:
|
||||
|
||||
> 参考文档 Kubernetes 官网文档 [Communicating with Daemon Pods](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/#communicating-with-daemon-pods)
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
与 DaemonSet 容器组通信的模式有：
|
||||
|
||||
* **Push：** DaemonSet 容器组用来向另一个服务推送信息，例如数据库的统计信息。这种情况下 DaemonSet 容器组没有客户端
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 创建 DaemonSet
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
## YAML 示例
|
||||
|
||||
下面是 DaemonSet 的 YAML 文件示例 daemonset.yaml。该例子中的 DaemonSet 运行了一个 fluentd-elasticsearch 的 docker 镜像：
|
||||
|
||||
@ -11,6 +11,7 @@ meta:
|
||||
|
||||
> 参考文档： Kubernetes 官网文档 [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/)
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
DaemonSet 控制器确保所有（或一部分）的节点都运行了一个指定的 Pod 副本。
|
||||
* 每当向集群中添加一个节点时，指定的 Pod 副本也将添加到该节点上
|
||||
|
||||
@ -11,6 +11,8 @@ meta:
|
||||
|
||||
> 参考文档 Kubernetes 官网文档 [How Daemon Pods are Scheduled](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/#how-daemon-pods-are-scheduled)
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
## 由 DaemonSet 控制器调度
|
||||
|
||||
**v1.12以后默认禁用**
|
||||
|
||||
@ -11,6 +11,8 @@ meta:
|
||||
|
||||
> 参考文档 Kubernetes 官网文档 [Updating a DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/#updating-a-daemonset)
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
## 更新信息
|
||||
|
||||
* 在改变节点的标签时：
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 金丝雀发布
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
[返回 Deployment](./#deployment-概述)
|
||||
|
||||
<el-tabs type="border-card">
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 清理策略
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
[返回 Deployment](./#deployment-概述)
|
||||
|
||||
通过 Deployment 中 `.spec.revisionHistoryLimit` 字段，可指定为该 Deployment 保留多少个旧的 ReplicaSet。超出该数字的将被在后台进行垃圾回收。该字段的默认值是 10。
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 创建 Deployment
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
[返回 Deployment](./#deployment-概述)
|
||||
|
||||
本文描述了如何创建一个 Deployment，如何理解 Deployment 各个字段，以及如何查看 Deployment 的创建结果。
|
||||
|
||||
@ -11,6 +11,8 @@ meta:
|
||||
|
||||
参考文档： Kubernetes 官网 [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)、 [ReplicaSet](https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/)
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
术语表
|
||||
|
||||
| 英文 | 英文简称 | 中文 |
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 暂停和继续 Deployment
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
[返回 Deployment](./#deployment-概述)
|
||||
|
||||
您可以先暂停 Deployment，然后再触发一个或多个更新，最后再继续（resume）该 Deployment。这种做法使得您可以在暂停和继续中间对 Deployment 做多次更新，而无需触发不必要的滚动更新。
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 回滚 Deployment
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
[返回 Deployment](./#deployment-概述)
|
||||
|
||||
某些情况下，您可能想要回滚（rollback）Deployment，例如：Deployment 不稳定（可能是不断地崩溃）。默认情况下，kubernetes 将保存 Deployment 的所有更新（rollout）历史。您可以设定 revision history limit 来确定保存的历史版本数量。
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 伸缩 Deployment
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
[返回 Deployment](./#deployment-概述)
|
||||
|
||||
伸缩（Scaling） Deployment，是指改变 Deployment 中 Pod 的副本数量，以应对实际业务流量的变化。
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 查看 Deployment 的状态
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
[返回 Deployment](./#deployment-概述)
|
||||
|
||||
Deployment 的生命周期中，将会进入不同的状态，这些状态可能是：
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 更新 Deployment
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
[返回 Deployment](./#deployment-概述)
|
||||
|
||||
## 执行更新
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# StatefulSet 的基本信息
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
[返回 StatefulSet](./)
|
||||
|
||||
## 创建 StatefulSet
|
||||
|
||||
@ -11,6 +11,8 @@ meta:
|
||||
|
||||
> 参考文档： Kubernetes 官网文档 [StatefulSets](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/)
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
## StatefulSet 概述
|
||||
|
||||
StatefulSet 顾名思义，用于管理 Stateful（有状态）的应用程序。
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# StatefulSet 的部署和伸缩
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
[返回 StatefulSet](./)
|
||||
|
||||
## 部署和伸缩 StatefulSet 时的执行顺序
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# StatefulSet 的更新策略
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
[返回 StatefulSet](./)
|
||||
|
||||
## StatefulSet 的更新策略 <Badge text="Kuboard 暂不支持" type="warn"/>
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 控制器_概述
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
## 概述
|
||||
|
||||
Pod（容器组）是 Kubernetes 中最小的调度单元，您可以通过 kubectl 直接创建一个 Pod。Pod 本身并不能自愈（self-healing）。如果一个 Pod 所在的 Node （节点）出现故障，或者调度程序自身出现故障，Pod 将被删除；同理，当因为节点资源不够或节点维护而驱逐 Pod 时，Pod 也将被删除。
|
||||
|
||||
Reference in New Issue
Block a user