调整结构
This commit is contained in:
huanqing.shao
23
learning/k8s-intermediate/workload/pod-kuboard.md
Normal file
23
learning/k8s-intermediate/workload/pod-kuboard.md
Normal file
@ -0,0 +1,23 @@
|
||||
---
|
||||
description: 本文描述了 Kuboard 如何处理 Kubernetes 容器组
|
||||
---
|
||||
|
||||
# 容器组 - Kuboard
|
||||
|
||||
## 通过 Kuboard 创建容器组
|
||||
|
||||
由于在 Kubernetes 中，任何时候都是不推荐用户直接创建容器组，而是应该通过控制器创建容器组，Kuboard 管理工具并不提供直接创建容器组的界面，而是通过 **工作负载编辑器** 创建 Deployment、StatefulSet、DaemonSet 等方式来创建容器组。
|
||||
|
||||
在 Kuboard **工作负载编辑器** 中，容器组的概念处于如下图所示的位置：
|
||||
|
||||
在 Kuboard **工作负载编辑器** 界面中，容器组的 template 由界面中的如下几个部分指定：
|
||||
|
||||
## 通过 Kuboard 查看容器组
|
||||
|
||||
Kuboard 中，有两种方式可以查看容器组的信息：
|
||||
* 通过 **工作负载编辑器** 显示界面查看
|
||||
* 通过 **容器组列表** 查看
|
||||
|
||||
## 工作负载编辑器
|
||||
|
||||
## 容器组列表
|
||||
@ -0,0 +1,44 @@
|
||||
---
|
||||
layout: LearningLayout
|
||||
description: 本文描述了 Kubernetes DaemonSet 的概念、行为及用法
|
||||
---
|
||||
|
||||
# DaemonSet 的替代选项
|
||||
|
||||
> 参考文档： Kubernetes 官网文档 [Alternatives to DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/#alternatives-to-daemonset)
|
||||
|
||||
DaemonSet 有如下替代选项可以选择
|
||||
|
||||
## Init Scripts
|
||||
|
||||
您可以通过脚本（例如，`init`、`upstartd`、`systemd`）直接在节点上启动一个守护进程。相对而言，DaemonSet 在处理守护进程时，有如下优势：
|
||||
|
||||
* 使用与应用程序相同的方式处理守护进程的日志和监控
|
||||
* 使用与应用程序相同的配置语言和工具（例如：Pod template、kubectl）处理守护进程
|
||||
* 在容器中运行守护进程，可为守护进程增加 resource limits 等限定
|
||||
|
||||
## Pods
|
||||
|
||||
您可以直接创建 Pod，并指定其在某一个节点上运行。相对而言，使用 DaemonSet 可获得如下优势：
|
||||
|
||||
* Pod 终止后，DaemonSet 可以立刻新建 Pod 以顶替已终止的 Pod。Pod 终止的原因可能是：
|
||||
* 节点故障
|
||||
* 节点停机维护
|
||||
|
||||
## 静态 Pod
|
||||
|
||||
您可以在 Kubelet 监听的目录下创建一个 Pod 的 yaml 文件，这种形式的 Pod 叫做 [静态 Pod（static pod）](https://kubernetes.io/docs/tasks/configure-pod-container/static-pod/)。与 DaemonSet 不同，静态 Pod 不能通过 kubectl 或者 Kuboard 进行管理。静态 Pod 不依赖 Kubernetes APIServer 的特点，使得它在引导集群启动的过程中非常有用。
|
||||
|
||||
::: warning
|
||||
静态 Pod 将来可能被不推荐使用 （deprecated）
|
||||
:::
|
||||
|
||||
## Deployment
|
||||
|
||||
DaemonSet 和 Deployment 一样，他们都创建长时间运行的 Pod（例如 web server、storage server 等）
|
||||
|
||||
* Deployment 适用于无状态服务（例如前端程序），对于这些程序而言，扩容（scale up）/ 缩容（scale down）、滚动更新等特性比精确控制 Pod 所运行的节点更重要。
|
||||
|
||||
* DaemonSet 更适合如下情况：
|
||||
* Pod 的副本总是在所有（或者部分指定的）节点上运行
|
||||
* 需要在其他 Pod 启动之前运行
|
||||
@ -0,0 +1,15 @@
|
||||
---
|
||||
layout: LearningLayout
|
||||
description: 本文描述了 Kubernetes DaemonSet 的概念、行为及用法
|
||||
---
|
||||
|
||||
# 与 DaemonSet 通信
|
||||
|
||||
> 参考文档 Kubernetes 官网文档 [Communicating with Daemon Pods](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/#communicating-with-daemon-pods)
|
||||
|
||||
与 DaemonSet 容器组通信的模式有：
|
||||
|
||||
* **Push：** DaemonSet 容器组用来向另一个服务推送信息，例如数据库的统计信息。这种情况下 DaemonSet 容器组没有客户端
|
||||
* **NodeIP + Port：** DaemonSet 容器组可以使用 `hostPort`，此时可通过节点的 IP 地址直接访问该容器组。客户端需要知道节点的 IP 地址，以及 DaemonSet 容器组的 端口号
|
||||
* **DNS：** 创建一个 [headless service](https://kubernetes.io/docs/concepts/services-networking/service/#headless-services)，且该 Service 与 DaemonSet 有相同的 Pod Selector。此时，客户端可通过该 Service 的 DNS 解析到 DaemonSet 的 IP 地址
|
||||
* **Service：** 创建一个 Service，且该 Service 与 DaemonSet 有相同的 Pod Selector，客户端通过该 Service，可随机访问到某一个节点上的 DaemonSet 容器组
|
||||
96
learning/k8s-intermediate/workload/wl-daemonset/create.md
Normal file
96
learning/k8s-intermediate/workload/wl-daemonset/create.md
Normal file
@ -0,0 +1,96 @@
|
||||
---
|
||||
layout: LearningLayout
|
||||
description: 本文描述了 Kubernetes 中如何创建 DaemonSet
|
||||
---
|
||||
|
||||
# 创建 DaemonSet
|
||||
|
||||
## YAML 示例
|
||||
|
||||
下面是 DaemonSet 的 YAML 文件示例 daemonset.yaml。该例子中的 DaemonSet 运行了一个 fluentd-elasticsearch 的 docker 镜像：
|
||||
|
||||
``` yaml
|
||||
apiVersion: apps/v1
|
||||
kind: DaemonSet
|
||||
metadata:
|
||||
name: fluentd-elasticsearch
|
||||
namespace: kube-system
|
||||
labels:
|
||||
k8s-app: fluentd-logging
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
name: fluentd-elasticsearch
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
name: fluentd-elasticsearch
|
||||
spec:
|
||||
tolerations:
|
||||
- key: node-role.kubernetes.io/master
|
||||
effect: NoSchedule
|
||||
containers:
|
||||
- name: fluentd-elasticsearch
|
||||
image: fluent/fluentd-kubernetes-daemonset:v1.7.1-debian-syslog-1.0
|
||||
resources:
|
||||
limits:
|
||||
memory: 200Mi
|
||||
requests:
|
||||
cpu: 100m
|
||||
memory: 200Mi
|
||||
volumeMounts:
|
||||
- name: varlog
|
||||
mountPath: /var/log
|
||||
- name: varlibdockercontainers
|
||||
mountPath: /var/lib/docker/containers
|
||||
readOnly: true
|
||||
terminationGracePeriodSeconds: 30
|
||||
volumes:
|
||||
- name: varlog
|
||||
hostPath:
|
||||
path: /var/log
|
||||
- name: varlibdockercontainers
|
||||
hostPath:
|
||||
path: /var/lib/docker/containers
|
||||
```
|
||||
|
||||
执行如下命令可创建该 DaemonSet：
|
||||
|
||||
``` sh
|
||||
kubectl apply -f ./daemonset.yaml
|
||||
```
|
||||
|
||||
## 必填字段
|
||||
|
||||
与其他所有 Kubernetes API 对象相同，DaemonSet 需要如下字段：
|
||||
* apiVersion
|
||||
* kind
|
||||
* metadata
|
||||
|
||||
除此之外，DaemonSet 还需要 `.spec` 字段
|
||||
|
||||
## Pod Template
|
||||
|
||||
`.spec.template` 是必填字段，定义了 Pod 的模板，与定义 Pod 的 yaml 格式完全相同（除了内嵌在 DaemonSet 中以外，没有 kind、APIVersion 字段以外）。
|
||||
|
||||
在 DaemonSet 中，您必须指定 `.spec.template.metadata.labels` 字段和 `.spec.tempalte.spec` 字段。
|
||||
|
||||
DaemonSet 的 `.spec.template.spec.restartPolicy` 字段必须为 Always，或者不填（默认值为 Always）
|
||||
|
||||
## Pod Selector
|
||||
|
||||
`.spec.selector` 字段定义了 DaemonSet 的 pod selector，DaemonSet 认为符合该选择器的 Pod 由其管理。
|
||||
|
||||
自 Kubernets v1.8 以后，`.spec.selector` 是必填字段，且您指定该字段时，必须与 `.spec.template.metata.labels` 字段匹配（不匹配的情况下创建 DaemonSet 将失败）。DaemonSet 创建以后，`.spec.selector` 字段就不可再修改。如果修改，可能导致不可预见的结果。
|
||||
|
||||
`.spec.selector` 由两个字段组成：
|
||||
* matchLabels <Badge text="Kuboard 已支持" type="success"/>
|
||||
* matchExpressions <Badge text="Kuboard 暂不支持" type="warn"/> 通过指定 key、value列表以及运算符，可以构造更复杂的选择器
|
||||
|
||||
如果两个字段同时存在，则必须同时满足两个条件的 Pod 才被选中。
|
||||
|
||||
任何情况下，您不能以任何方式创建符合 DaemonSet 的 `.spec.selector` 选择器的 Pod。否则 DaemonSet Controller 会认为这些 Pod 是由它创建的。这将导致不可预期的行为出现。
|
||||
|
||||
## 只在部分节点上运行
|
||||
|
||||
指定 `.spec.template.spec.nodeSelector` <Badge text="Kuboard 已支持" type="success"/>，DaemonSet Controller 将只在指定的节点上创建 Pod （参考 [节点选择器 nodeSelector](/learning/k8s-intermediate/config/assign-pod-node.html#节点选择器-nodeselector)）。同样的，如果指定 `.spec.template.spec.affinity` <Badge text="Kuboard 暂不支持" type="warn"/>，DaemonSet Controller 将只在与 [node affinity](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/) 匹配的节点上创建 Pod。
|
||||
@ -3,6 +3,27 @@ layout: LearningLayout
|
||||
description: 本文描述了 Kubernetes DaemonSet 的概念、行为及用法
|
||||
---
|
||||
|
||||
# 控制器 - DaemonSet
|
||||
# 介绍 DaemonSet
|
||||
|
||||
正在撰写...
|
||||
> 参考文档： Kubernetes 官网文档 [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/)
|
||||
|
||||
|
||||
DaemonSet 控制器确保所有（或一部分）的节点都运行了一个指定的 Pod 副本。
|
||||
* 每当向集群中添加一个节点时，指定的 Pod 副本也将添加到该节点上
|
||||
* 当节点从集群中移除时，Pod 也就被垃圾回收了
|
||||
* 删除一个 DaemonSet 可以清理所有由其创建的 Pod
|
||||
|
||||
DaemonSet 的典型使用场景有：
|
||||
|
||||
* 在每个节点上运行集群的存储守护进程，例如 glusterd、ceph
|
||||
* 在每个节点上运行日志收集守护进程，例如 fluentd、logstash
|
||||
* 在每个节点上运行监控守护进程，例如 [Prometheus Node Exporter](https://github.com/prometheus/node_exporter)、[Sysdig Agent](https://sysdigdocs.atlassian.net/wiki/spaces/Platform)、collectd、[Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/)、[APPDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes)、[Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/)、[New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration)、Ganglia gmond、[Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/) 等
|
||||
|
||||
通常情况下，一个 DaemonSet 将覆盖所有的节点。复杂一点儿的用法，可能会为某一类守护进程设置多个 DaemonSets，每一个 DaemonSet 针对不同类硬件类型设定不同的内存、cpu请求。
|
||||
|
||||
本文从以下几方面介绍 DaemonSet：
|
||||
* [创建 DaemonSet](./create.html)
|
||||
* [DaemonSet 是如何调度的](./schedule.html)
|
||||
* [与 DaemonSet 通信](./communicate.html)
|
||||
* [更新 DaemonSet](./update.html)
|
||||
* [DaemonSet 的替代选项](./alternative.html)
|
||||
|
||||
54
learning/k8s-intermediate/workload/wl-daemonset/schedule.md
Normal file
54
learning/k8s-intermediate/workload/wl-daemonset/schedule.md
Normal file
@ -0,0 +1,54 @@
|
||||
---
|
||||
layout: LearningLayout
|
||||
description: 本文描述了 Kubernetes DaemonSet 如何调度 Pod
|
||||
---
|
||||
|
||||
# DaemonSet 是如何调度的
|
||||
|
||||
> 参考文档 Kubernetes 官网文档 [How Daemon Pods are Scheduled](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/#how-daemon-pods-are-scheduled)
|
||||
|
||||
## 由 DaemonSet 控制器调度
|
||||
|
||||
**v1.12以后默认禁用**
|
||||
|
||||
通常，Kubernetes Scheduler（调度器）决定了 Pod 在哪个节点上运行。然而 DaemonSet Controller 创建的 Pod 已经指定了 `.spec.nodeName` 字段，因此：
|
||||
* Node 节点的 [unschedulable](https://kubernetes.io/docs/concepts/architecture/nodes/#manual-node-administration) 字段将被 DaemonSet Controller 忽略
|
||||
* DaemonSet Controller 可以在 kubernetes scheduler 启动之前创建 Pod，这个特性在引导集群启动的时候非常有用（集群使用者无需关心）
|
||||
|
||||
## 由默认调度器调度
|
||||
|
||||
**v1.12以后默认启用**
|
||||
|
||||
DaemonSet 确保所以符合条件的节点运行了一个指定的 Pod。通常，Kubernetes Scheduler 决定 Pod 在哪个节点上运行。然而如果 DaemonSet 的 Pod 由 DaemonSet Controller 创建和调度，会引发如下问题：
|
||||
|
||||
* Pod 的行为不一致：普通的 Pod 在创建后处于 **Pending** 状态，并等待被调度，但是 DaemonSet Pod 创建后，初始状态不是 **Pending**。这会使用户感到困惑
|
||||
* [Pod 的优先权（preemption）](https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/) 由 kubernetes 调度器处理。如果 Pod 优先权被启用，DaemonSet Controller 在创建和调度 Pod 时，不会考虑 Pod 的优先权
|
||||
|
||||
Kubernetes v1.12 版本以后，默认通过 kubernetes 调度器来调度 DaemonSet 的 Pod。DaemonSet Controller 将会向 DaemonSet 的 Pod 添加 `.spec.nodeAffinity` 字段，而不是 `.spec.nodeName` 字段，并进一步由 kubernetes 调度器将 Pod 绑定到目标节点。如果 DaemonSet 的 Pod 已经存在了 `nodeAffinity` 字段，该字段的值将被替换。
|
||||
|
||||
``` yaml
|
||||
nodeAffinity:
|
||||
requiredDuringSchedulingIgnoredDuringExecution:
|
||||
nodeSelectorTerms:
|
||||
- matchFields:
|
||||
- key: metadata.name
|
||||
operator: In
|
||||
values:
|
||||
- target-host-name
|
||||
```
|
||||
|
||||
此外， `node.kubernetes.io/unschedulable:NoSchedule` 容忍（[toleration](/learning/k8s-intermediate/config/taints-and-toleration.html)）将被自动添加到 DaemonSet 的 Pod 中。由此，默认调度器在调度 DaemonSet 的 Pod 时可以忽略节点的 **unschedulable** 属性
|
||||
|
||||
## 污点和容忍
|
||||
|
||||
在调度 DaemonSet 的 Pod 时，污点和容忍（[taints and tolerations](/learning/k8s-intermediate/config/taints-and-toleration.html)）会被考量到，同时，以下容忍（toleration）将被自动添加到 DaemonSet 的 Pod 中：
|
||||
|
||||
| Toleration Key | Effect | Version | 描述 |
|
||||
| -------------------------------------- | ---------- | ------- | ------------------------------------------------------------ |
|
||||
| node.kubernetes.io/not-ready | NoExecute | 1.13+ | 节点出现问题时（例如网络故障），DaemonSet 容器组将不会从节点上驱逐 |
|
||||
| node.kubernetes.io/unreachable | NoExecute | 1.13+ | 节点出现问题时（例如网络故障），DaemonSet 容器组将不会从节点上驱逐 |
|
||||
| node.kubernetes.io/disk-pressure | NoSchedule | 1.8+ | |
|
||||
| node.kubernetes.io/memory-pressure | NoSchedule | 1.8+ | |
|
||||
| node.kubernetes.io/unschedulable | NoSchedule | 1.12+ | 默认调度器针对 DaemonSet 容器组，容忍节点的 `unschedulable `属性 |
|
||||
| node.kubernetes.io/network-unavailable | NoSchedule | 1.12+ | 默认调度器针对 DaemonSet 容器组，在其使用 host network 时，容忍节点的 `network-unavailable` 属性 |
|
||||
|
||||
23
learning/k8s-intermediate/workload/wl-daemonset/update.md
Normal file
23
learning/k8s-intermediate/workload/wl-daemonset/update.md
Normal file
@ -0,0 +1,23 @@
|
||||
---
|
||||
layout: LearningLayout
|
||||
description: 本文描述了 Kubernetes DaemonSet 的概念、行为及用法
|
||||
---
|
||||
|
||||
# 更新 DaemonSet
|
||||
|
||||
> 参考文档 Kubernetes 官网文档 [Updating a DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/#updating-a-daemonset)
|
||||
|
||||
## 更新信息
|
||||
|
||||
* 在改变节点的标签时：
|
||||
* 如果该节点匹配了 DaemonSet 的 `.spec.template.spec.nodeSelector`，DaemonSet 将会在该节点上创建一个 Pod
|
||||
* 如果该节点原来匹配 DaemonSet 的 `.spec.template.spec.nodeSelector`，现在不匹配了，则，DaemonSet 将会删除该节点上对应的 Pod
|
||||
|
||||
* 您可以修改 DaemonSet 的 Pod 的部分字段，但是，DaemonSet 控制器在创建新的 Pod 时，仍然会使用原有的 Template 进行 Pod 创建。
|
||||
|
||||
* 您可以删除 DaemonSet。如果在 `kubectl` 命令中指定 `--cascade=false` 选项，DaemonSet 容器组将不会被删除。紧接着，如果您创建一个新的 DaemonSet，与之前删除的 DaemonSet 有相同的 `.spec.selector`，新建 DaemonSet 将直接把这些未删除的 Pod 纳入管理。DaemonSet 根据其 `updateStrategy` 决定是否更新这些 Pod
|
||||
|
||||
## 执行滚动更新
|
||||
|
||||
|
||||
https://kubernetes.io/docs/tasks/manage-daemon/update-daemon-set/
|
||||
@ -47,7 +47,7 @@ spec:
|
||||
terminationGracePeriodSeconds: 10
|
||||
containers:
|
||||
- name: nginx
|
||||
image: k8s.gcr.io/nginx-slim:0.8
|
||||
image: nginx:1.7.9
|
||||
ports:
|
||||
- containerPort: 80
|
||||
name: web
|
||||
|
||||
@ -5,6 +5,8 @@ description: 本文描述了 Kubernetes StatefulSet 的概念、行为及用法
|
||||
|
||||
# StatefulSet 的使用场景
|
||||
|
||||
> 参考文档： Kubernetes 官网文档 [StatefulSets](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/)
|
||||
|
||||
## StatefulSet 概述
|
||||
|
||||
StatefulSet 顾名思义，用于管理 Stateful（有状态）的应用程序。
|
||||
|
||||
Reference in New Issue
Block a user