kubernetes基础知识 核心功能 架构

 一、提供一套Minikube集群测试环境

1、Minikube集群测试环境服务器地址
https://kubernetes.io/docs/tutorials/hello-minikube/

二、k8s核心功能：应用部署、访问、Scale Up/Down 以及滚动更新

1、部署应用

?
命令：
kubectl run kubernetes-bootcamp \
      --image=docker.io/jocatalin/kubernetes-bootcamp:v1 \
      --port=8080
 
通过 kubectl run 部署了一个应用，命名为 kubernetes-bootcamp。
 
Docker 镜像通过 --image 指定。
 
--port 设置应用对外服务的端口。
 
结果：
kubectl run --generator=deployment/apps.v1 is DEPRECATED and will be removed in a future version. Use kubectl run --generator=run-pod/v1 or kubectl create instead.
deployment.apps/kubernetes-bootcamp created

3、Kubernetes 重要术语 

a、Pod 是容器的集合，通常会将紧密相关的一组容器放到一个 Pod 中，同一个 Pod 中的所有容器共享 IP 地址和 Port 空间，也就是说它们在一个 network namespace 中。Pod 是 Kubernetes 调度的最小单位，同一 Pod 中的容器始终被一起调度。

 b、deployment可以理解为应用。

查看当前的pod

?
$ kubectl get pods
NAME                                   READY   STATUS    RESTARTS   AGE
kubernetes-bootcamp-6c5cfd894b-698g2   1/1     Running   0          28s

访问应用

默认情况下，所有 Pod 只能在集群内部访问。对于上面这个例子，要访问应用只能直接访问容器的 8080 端口。为了能够从外部访问应用，我们需要将容器的 8080 端口映射到节点的端口。

 执行如下命令：

?
kubectl expose deployment/kubernetes-bootcamp \
      --type="NodePort" \
      --port 8080

查看应用被映射到节点的哪个端口

?
$ kubectl get services
NAME                  TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)          AGE
kubernetes            ClusterIP   10.96.0.1     <none>        443/TCP          2m43s
kubernetes-bootcamp   NodePort    10.105.35.4   <none>        8080:30207/TCP   33s

kubernetes-bootcamp 是我们应用的 service，8080 端口已经映射到 host01 的 32320 端口，端口号是随机分配的。

访问应用命令：

?
$ hostname
minikube
 
$ curl minikube:30207
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-6c5cfd894b-698g2 | v=1

Scale 应用

默认情况下应用只会运行一个副本，可以通过 kubectl get deployments查看副本数。

?
$  kubectl get deployments
NAME                  READY   UP-TO-DATE   AVAILABLE   AGE
kubernetes-bootcamp   1/1     1            1           5m1s

将副本数增加到 3 个

?
$ kubectl scale deployments/kubernetes-bootcamp --replicas=3
deployment.extensions/kubernetes-bootcamp scaled
 
$ kubectl get deployments
NAME                  READY   UP-TO-DATE   AVAILABLE   AGE
kubernetes-bootcamp   3/3     3            3           6m4s

查看当前pod也增加到3个

?
$ kubectl get pods
NAME                                   READY   STATUS    RESTARTS   AGE
kubernetes-bootcamp-6c5cfd894b-698g2   1/1     Running   0          7m49s
kubernetes-bootcamp-6c5cfd894b-9d6sn   1/1     Running   0          2m3s
kubernetes-bootcamp-6c5cfd894b-tcp94   1/1     Running   0          2m3s

通过 curl 访问应用，可以看到每次请求发送到不同的 Pod，三个副本轮询处理，这样就实现了负载均衡。

?
$ curl minikube:30207
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-6c5cfd894b-9d6sn | v=1
$ curl minikube:30207
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-6c5cfd894b-9d6sn | v=1
$ curl minikube:30207
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-6c5cfd894b-tcp94 | v=1
$ curl minikube:30207
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-6c5cfd894b-tcp94 | v=1
$ curl minikube:30207
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-6c5cfd894b-698g2 | v=1
#备注，已经实现了负载均衡功能。

通过scale down命令删除副本

?
$ kubectl get deployments
NAME                  READY   UP-TO-DATE   AVAILABLE   AGE
kubernetes-bootcamp   3/3     3            3           11m
 
$ kubectl get pods
NAME                                   READY   STATUS    RESTARTS   AGE
kubernetes-bootcamp-6c5cfd894b-698g2   1/1     Running   0          12m
kubernetes-bootcamp-6c5cfd894b-9d6sn   1/1     Running   0          6m19s
kubernetes-bootcamp-6c5cfd894b-tcp94   1/1     Running   0          6m19s
 
#通过scale down删除一个副本
$ kubectl scale deployments/kubernetes-bootcamp --replicas=2
 
deployment.extensions/kubernetes-bootcamp scaled
$ kubectl get pods
NAME                                   READY   STATUS        RESTARTS   AGE
kubernetes-bootcamp-6c5cfd894b-698g2   1/1     Running       0          13m
kubernetes-bootcamp-6c5cfd894b-9d6sn   1/1     Running       0          7m42s
kubernetes-bootcamp-6c5cfd894b-tcp94   1/1     Terminating   0          7m42s  #其中一个副本被删除了

滚动更新

当前应用使用的 image 版本为 v1，执行如下命令将其升级到 v2：

?
$ kubectl get pods  #这里需要等20秒左右，才能更新完成
NAME                                   READY   STATUS        RESTARTS   AGE
kubernetes-bootcamp-5bf4d5689b-km8dq   1/1     Running       0          39s
kubernetes-bootcamp-5bf4d5689b-wlrmn   1/1     Running       0          38s
kubernetes-bootcamp-6c5cfd894b-698g2   0/1     Terminating   0          15m
kubernetes-bootcamp-6c5cfd894b-9d6sn   0/1     Terminating   0          9m41s
 
$ kubectl get pods
NAME                                   READY   STATUS    RESTARTS   AGE
kubernetes-bootcamp-5bf4d5689b-km8dq   1/1     Running   0          42s
kubernetes-bootcamp-5bf4d5689b-wlrmn   1/1     Running   0          41s

通过 kubectl get pods 可以观察滚动更新的过程：v1 的 Pod 被逐个删除，同时启动了新的 v2 Pod。更新完成后访问新版本应用。

?
$ curl minikube:30207
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-5bf4d5689b-wlrmn | v=2
 
$ curl minikube:30207
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-5bf4d5689b-km8dq | v=2

现在是V2版本，需要进行回退成V1版本

?
$ kubectl rollout undo deployments/kubernetes-bootcamp
deployment.extensions/kubernetes-bootcamp rolled back
 
$ kubectl get pods
NAME                                   READY   STATUS        RESTARTS   AGE
kubernetes-bootcamp-5bf4d5689b-km8dq   1/1     Terminating   0          4m43s
kubernetes-bootcamp-5bf4d5689b-wlrmn   1/1     Terminating   0          4m42s
kubernetes-bootcamp-6c5cfd894b-mrcn5   1/1     Running       0          10s
kubernetes-bootcamp-6c5cfd894b-nz2jx   1/1     Running       0          9s
 
$ curl minikube:30207
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-6c5cfd894b-qw8dq | v=1

4、Kubernetes 集群的重要概念

?
Cluster
Cluster 是计算、存储和网络资源的集合，Kubernetes 利用这些资源运行各种基于容器的应用。
 
Master
Master 是 Cluster 的大脑，它的主要职责是调度，即决定将应用放在哪里运行。Master 运行 Linux 操作系统，可以是物理机或者虚拟机。为了实现高可用，可以运行多个 Master。
 
Node
Node 的职责是运行容器应用。Node 由 Master 管理，Node 负责监控并汇报容器的状态，并根据 Master 的要求管理容器的生命周期。Node 运行在 Linux 操作系统，可以是物理机或者是虚拟机。
 
Pod
Pod 是 Kubernetes 的最小工作单元。每个 Pod 包含一个或多个容器。Pod 中的容器会作为一个整体被 Master 调度到一个 Node 上运行。
 
Kubernetes 引入 Pod 主要基于下面两个目的：
 
可管理性。
有些容器天生就是需要紧密联系，一起工作。Pod 提供了比容器更高层次的抽象，将它们封装到一个部署单元中。Kubernetes 以 Pod 为最小单位进行调度、扩展、共享资源、管理生命周期。
 
通信和资源共享。
Pod 中的所有容器使用同一个网络 namespace，即相同的 IP 地址和 Port 空间。它们可以直接用 localhost 通信。同样的，这些容器可以共享存储，当 Kubernetes 挂载 volume 到 Pod，本质上是将 volume 挂载到 Pod 中的每一个容器。
 
Pods 有两种使用方式：
运行单一容器。
one-container-per-Pod 是 Kubernetes 最常见的模型，这种情况下，只是将单个容器简单封装成 Pod。即便是只有一个容器，Kubernetes 管理的也是 Pod 而不是直接管理容器。
 
运行多个容器。
但问题在于：哪些容器应该放到一个 Pod 中？
答案是：这些容器联系必须 非常紧密，而且需要 直接共享资源。
 
Controller
Kubernetes 通常不会直接创建 Pod，而是通过 Controller 来管理 Pod 的。Controller 中定义了 Pod 的部署特性，比如有几个副本，在什么样的 Node 上运行等。为了满足不同的业务场景，Kubernetes 提供了多种 Controller，包括 Deployment、ReplicaSet、DaemonSet、StatefuleSet、Job 等，我们逐一讨论。
 
Deployment 是最常用的 Controller，比如前面在线教程中就是通过创建 Deployment 来部署应用的。Deployment 可以管理 Pod 的多个副本，并确保 Pod 按照期望的状态运行。
 
ReplicaSet 实现了 Pod 的多副本管理。使用 Deployment 时会自动创建 ReplicaSet，也就是说 Deployment 是通过 ReplicaSet 来管理 Pod 的多个副本，我们通常不需要直接使用 ReplicaSet。
 
DaemonSet 用于每个 Node 最多只运行一个 Pod 副本的场景。正如其名称所揭示的，DaemonSet 通常用于运行 daemon。
 
StatefuleSet 能够保证 Pod 的每个副本在整个生命周期中名称是不变的。而其他 Controller 不提供这个功能，当某个 Pod 发生故障需要删除并重新启动时，Pod 的名称会发生变化。同时 StatefuleSet 会保证副本按照固定的顺序启动、更新或者删除。
 
Job 用于运行结束就删除的应用。而其他 Controller 中的 Pod 通常是长期持续运行。
 
Service
Deployment 可以部署多个副本，每个 Pod 都有自己的 IP，外界如何访问这些副本呢？
 
通过 Pod 的 IP 吗？
要知道 Pod 很可能会被频繁地销毁和重启，它们的 IP 会发生变化，用 IP 来访问不太现实。
 
答案是 Service。
Kubernetes Service 定义了外界访问一组特定 Pod 的方式。Service 有自己的 IP 和端口，Service 为 Pod 提供了负载均衡。
 
Kubernetes 运行容器（Pod）与访问容器（Pod）这两项任务分别由 Controller 和 Service 执行。
 
Namespace
 
如果有多个用户或项目组使用同一个 Kubernetes Cluster，如何将他们创建的 Controller、Pod 等资源分开呢？
 
答案就是 Namespace。
Namespace 可以将一个物理的 Cluster 逻辑上划分成多个虚拟 Cluster，每个 Cluster 就是一个 Namespace。不同 Namespace 里的资源是完全隔离的。
 
Kubernetes 默认创建了两个 Namespace。
$ kubectl get namespace
NAME          STATUS   AGE
default       Active   26m
kube-public   Active   26m
kube-system   Active   26m
 
default -- 创建资源时如果不指定，将被放到这个 Namespace 中。
 
kube-system -- Kubernetes 自己创建的系统资源将放到这个 Namespace 中。

5、Kubernetes Cluste

Kubernetes Cluster 由 Master 和 Node 组成，节点上运行着若干 Kubernetes 服务。

#k8s-master  1个节点

#k8s-node1、k8s-node2  多个node节点

所有的节点都已经 Ready，Kubernetes Cluster 创建成功。

Master 节点

Master 是 Kubernetes Cluster 的大脑，运行着如下 Daemon 服务：kube-apiserver、kube-scheduler、kube-controller-manager、etcd 和 Pod 网络（例如 flannel）。

API Server（kube-apiserver）

API Server 提供 HTTP/HTTPS RESTful API，即 Kubernetes API。API Server 是 Kubernetes Cluster 的前端接口，各种客户端工具（CLI 或 UI）以及 Kubernetes 其他组件可以通过它管理 Cluster 的各种资源。

Scheduler（kube-scheduler）

Scheduler 负责决定将 Pod 放在哪个 Node 上运行。Scheduler 在调度时会充分考虑 Cluster 的拓扑结构，当前各个节点的负载，以及应用对高可用、性能、数据亲和性的需求。

Controller Manager（kube-controller-manager）

Controller Manager 负责管理 Cluster 各种资源，保证资源处于预期的状态。Controller Manager 由多种 controller 组成，包括 replication controller、endpoints controller、namespace controller、serviceaccounts controller 等。

不同的 controller 管理不同的资源。例如 replication controller 管理 Deployment、StatefulSet、DaemonSet 的生命周期，namespace controller 管理 Namespace 资源。

etcd

etcd 负责保存 Kubernetes Cluster 的配置信息和各种资源的状态信息。当数据发生变化时，etcd 会快速地通知 Kubernetes 相关组件。

Pod 网络

Pod 要能够相互通信，Kubernetes Cluster 必须部署 Pod 网络，flannel 是其中一个可选方案。

Node节点

 Node 是 Pod 运行的地方，Kubernetes 支持 Docker、rkt 等容器 Runtime。 Node上运行的 Kubernetes 组件有 kubelet、kube-proxy 和 Pod 网络（例如 flannel）。

kubelet

kubelet 是 Node 的 agent，当 Scheduler 确定在某个 Node 上运行 Pod 后，会将 Pod 的具体配置信息（image、volume 等）发送给该节点的 kubelet，kubelet 根据这些信息创建和运行容器，并向 Master 报告运行状态。

kube-proxy

service 在逻辑上代表了后端的多个 Pod，外界通过 service 访问 Pod。service 接收到的请求是如何转发到 Pod 的呢？这就是 kube-proxy 要完成的工作。

每个 Node 都会运行 kube-proxy 服务，它负责将访问 service 的 TCP/UPD 数据流转发到后端的容器。如果有多个副本，kube-proxy 会实现负载均衡。

Pod 网络

Pod 要能够相互通信，Kubernetes Cluster 必须部署 Pod 网络，flannel 是其中一个可选方案。

Kubernetes 组件本身也运行在 Pod 里，执行如下命令：

kubectl get pod --all-namespaces -o wide

 

三、kubernetes架构，演示各个组件之间是如何协作的。
2.1、建一个httpd的pod,有两个副本
$ kubectl run httpd-app --image=httpd --replicas=2
kubectl run --generator=deployment/apps.v1 is DEPRECATED and will be removed in a future version. Use kubectl run --generator=run-pod/v1 or kubectl create instead.
deployment.apps/httpd-app created

#查看deployment
$ kubectl get deployment
NAME READY UP-TO-DATE AVAILABLE AGE
httpd-app 0/2 2 0 10s
nginx-deployment 2/2 2 2 7m15s

#查看pod运行状态
$ kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
httpd-app-f9ccf4675-4dzk5 1/1 Running 0 6m6s 172.18.0.7 minikube <none> <none>
httpd-app-f9ccf4675-56ztr 1/1 Running 0 6m6s 172.18.0.6 minikube <none> <none>

2.2、部署过程

 

① kubectl 发送部署请求到 API Server。

② API Server 通知 Controller Manager 创建一个 deployment 资源。

③ Scheduler 执行调度任务，将两个副本 Pod 分发到 k8s-node1 和 k8s-node2。

④ k8s-node1 和 k8s-node2 上的 kubelet 在各自的节点上创建并运行 Pod。

 

四、讲解Deployment

Kubernetes 开发了 Deployment、ReplicaSet、DaemonSet、StatefuleSet、Job 等多种 Controller

 示例：

 Deployment：

?
#将部署包含两个副本的 Deployment nginx-deployment，容器的 image 为 nginx:1.7.9。kubectl run nginx-deployment --image=nginx:1.7.9 --replicas=2
kubectl run --generator=deployment/apps.v1 is DEPRECATED and will be removed in a future version. Use kubectl run --generator=run-pod/v1 or kubectl create instead.
 
#kubectl get deployment 命令可以查看 nginx-deployment 的状态，输出显示两个副本正常运行。
$ kubectl get deployment nginx-deployment
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   2/2     2            2           57s

#用kubectl describe deployment 了解更详细的信息

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
$ kubectl describe deployment
Name:                   httpd-app
Namespace:              default
CreationTimestamp:      Fri, 10 May 2019 06:36:03 +0000
Labels:                 run=httpd-app
Annotations:            deployment.kubernetes.io/revision: 1
Selector:               run=httpd-app
Replicas:               2 desired | 2 updated | 2 total | 2 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  run=httpd-app
  Containers:
   httpd-app:
    Image:        httpd
    Port:         <none>
    Host Port:    <none>
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    True    NewReplicaSetAvailable
OldReplicaSets:  <none>
NewReplicaSet:   httpd-app-f9ccf4675 (2/2 replicas created)
Events:
  Type    Reason             Age   From                   Message
  ----    ------             ----  ----                   -------
  Normal  ScalingReplicaSet  15m   deployment-controller  Scaled up replica set httpd-app-f9ccf4675 to 2
 
 
Name:                   nginx-deployment
Namespace:              default
CreationTimestamp:      Fri, 10 May 2019 06:28:58 +0000
Labels:                 run=nginx-deployment
Annotations:            deployment.kubernetes.io/revision: 1
Selector:               run=nginx-deployment
Replicas:               2 desired | 2 updated | 2 total | 2 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  run=nginx-deployment
  Containers:
   nginx-deployment:
    Image:        nginx:1.7.9
    Port:         <none>
    Host Port:    <none>
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    True    NewReplicaSetAvailable
OldReplicaSets:  <none>
NewReplicaSet:   nginx-deployment-578fb949d8 (2/2 replicas created)
Events:
  Type    Reason             Age   From                   Message
  ----    ------             ----  ----                   -------
  Normal  ScalingReplicaSet  22m   deployment-controller  Scaled up replica set nginx-deployment-578fb949d8 to 2

#备注：创建了一个 ReplicaSet nginx-deployment-1260880958，Events 是 Deployment 的日志，记录了 ReplicaSet 的启动过程　

?
# Deployment 通过 ReplicaSet 来管理 Pod
 
$ kubectl get replicaset
NAME                          DESIRED   CURRENT   READY   AGE
httpd-app-f9ccf4675           2         2         2       18m
nginx-deployment-578fb949d8   2         2         2       25m

#查看副本详细信息

?
$ kubectl describe replicaset
Name:           httpd-app-f9ccf4675
Namespace:      default
Selector:       pod-template-hash=f9ccf4675,run=httpd-app
Labels:         pod-template-hash=f9ccf4675
                run=httpd-app
Annotations:    deployment.kubernetes.io/desired-replicas: 2
                deployment.kubernetes.io/max-replicas: 3
                deployment.kubernetes.io/revision: 1
Controlled By:  Deployment/httpd-app
Replicas:       2 current / 2 desired
Pods Status:    2 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
  Labels:  pod-template-hash=f9ccf4675
           run=httpd-app
  Containers:
   httpd-app:
    Image:        httpd
    Port:         <none>
    Host Port:    <none>
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Events:
  Type    Reason            Age   From                   Message
  ----    ------            ----  ----                   -------
  Normal  SuccessfulCreate  19m   replicaset-controller  Created pod: httpd-app-f9ccf4675-4dzk5
  Normal  SuccessfulCreate  19m   replicaset-controller  Created pod: httpd-app-f9ccf4675-56ztr
 
 
Name:           nginx-deployment-578fb949d8
Namespace:      default
Selector:       pod-template-hash=578fb949d8,run=nginx-deployment
Labels:         pod-template-hash=578fb949d8
                run=nginx-deployment
Annotations:    deployment.kubernetes.io/desired-replicas: 2
                deployment.kubernetes.io/max-replicas: 3
                deployment.kubernetes.io/revision: 1
Controlled By:  Deployment/nginx-deployment
Replicas:       2 current / 2 desired
Pods Status:    2 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
  Labels:  pod-template-hash=578fb949d8
           run=nginx-deployment
  Containers:
   nginx-deployment:
    Image:        nginx:1.7.9
    Port:         <none>
    Host Port:    <none>
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Events:
  Type    Reason            Age   From                   Message
  ----    ------            ----  ----                   -------
  Normal  SuccessfulCreate  26m   replicaset-controller  Created pod: nginx-deployment-578fb949d8-56bfz
  Normal  SuccessfulCreate  26m   replicaset-controller  Created pod: nginx-deployment-578fb949d8-fbdvd

#总结创建过程

?
1、用户通过 kubectl 创建 Deployment。
2、Deployment 创建 ReplicaSet。
3、ReplicaSet 创建 Pod。

　　

备注：从上图也可以看出，对象的命名方式是：子对象的名字 = 父对象名字 + 随机字符串或数字。

 

五、通过 kubectl run 创建的 Deployment

 Kubernetes 支持两种方式创建资源：

1. 用 kubectl 命令直接创建，比如：

kubectl run nginx-deployment --image=nginx:1.7.9 --replicas=2

2、在命令行中通过参数指定资源的属性。

 通过配置文件和 kubectl apply 创建。

cat nginx.yml

① apiVersion 是当前配置格式的版本。
② kind 是要创建的资源类型，这里是 Deployment。
③ metadata 是该资源的元数据，name 是必需的元数据项。
④ spec 部分是该 Deployment 的规格说明。
⑤ replicas 指明副本数量，默认为 1。
⑥ template 定义 Pod 的模板，这是配置文件的重要部分。
⑦ metadata 定义 Pod 的元数据，至少要定义一个 label。label 的 key 和 value 可以任意指定。
⑧ spec 描述 Pod 的规格，此部分定义 Pod 中每一个容器的属性，name 和 image 是必需的。

执行命令创建：

 

通过 kubectl get 查看 nginx-deployment 的各种资源：

Deployment、ReplicaSet、Pod 都已经就绪。如果要删除这些资源，执行 kubectl delete deployment nginx-deployment 或者 kubectl delete -f nginx.yml。

 总结：

a、用户命令的方式，适合临时测试

b、用配置文件的方式：

  1. 配置文件描述了 What，即应用最终要达到的状态。

  2. 配置文件提供了创建资源的模板，能够重复部署。

  3. 可以像管理代码一样管理部署。

  4. 适合正式的、跨环境的、规模化部署。

  5. 这种方式要求熟悉配置文件的语法，有一定难度。

后面我们都将采用配置文件的方式，大家需要尽快熟悉和掌握。

 

 六、伸缩（Scale Up/Down）是指在线增加或减少 Pod 的副本数。

Deployment nginx-deployment 初始是两个副本。

k8s-node1 和 k8s-node2 上各跑了一个副本。现在修改 nginx.yml，将副本改成 5 个。

再次执行 kubectl apply：

三个新副本被创建并调度到 k8s-node1 和 k8s-node2 上。

出于安全考虑，默认配置下 Kubernetes 不会将 Pod 调度到 Master 节点。如果希望将 k8s-master 也当作 Node 使用，可以执行如下命令：

kubectl taint node k8s-master node-role.kubernetes.io/master-

如果要恢复 Master Only 状态，执行如下命令：

kubectl taint node k8s-master node-role.kubernetes.io/master="":NoSchedule

接下来修改配置文件，将副本数减少为 3 个，重新执行 kubectl apply：

可以看到两个副本被删除，最终保留了 3 个副本。

 

七、模拟 k8s-node2 故障，关闭该节点。

我们有 3 个 nginx 副本分别运行在 k8s-node1 和 k8s-node2 上。现在模拟 k8s-node2 故障，关闭该节点。

等待一段时间，Kubernetes 会检查到 k8s-node2 不可用，将 k8s-node2 上的 Pod 标记为 Unknown 状态，并在 k8s-node1 上新创建两个 Pod，维持总副本数为 3。

当 k8s-node2 恢复后，Unknown 的 Pod 会被删除，不过已经运行的 Pod 不会重新调度回 k8s-node2。

删除 nginx-deployment：

 

八、label功能介绍

默认配置下，Scheduler 会将 Pod 调度到所有可用的 Node。不过有些情况我们希望将 Pod 部署到指定的 Node，比如将有大量磁盘 I/O 的 Pod 部署到配置了 SSD 的 Node；或者 Pod 需要 GPU，需要运行在配置了 GPU 的节点上。

Kubernetes 是通过 label 来实现这个功能的。

label 是 key-value 对，各种资源都可以设置 label，灵活添加各种自定义属性。比如执行如下命令标注 k8s-node1 是配置了 SSD 的节点。

kubectl label node k8s-node1 disktype=ssd

然后通过 kubectl get node --show-labels 查看节点的 label。

disktype=ssd 已经成功添加到 k8s-node1，除了 disktype，Node 还有几个 Kubernetes 自己维护的 label。

有了 disktype 这个自定义 label，接下来就可以指定将 Pod 部署到 k8s-node1。编辑 nginx.yml：

在 Pod 模板的 spec 里通过 nodeSelector 指定将此 Pod 部署到具有 label disktype=ssd 的 Node 上。

部署 Deployment 并查看 Pod 的运行节点：

全部 6 个副本都运行在 k8s-node1 上，符合我们的预期。

要删除 label disktype，执行如下命令：

kubectl label node k8s-node1 disktype-

 - 即删除。

不过此时 Pod 并不会重新部署，依然在 k8s-node1 上运行。

除非在 nginx.yml 中删除 nodeSelector 设置，然后通过 kubectl apply 重新部署。

Kubernetes 会删除之前的 Pod 并调度和运行新的 Pod。

Deployment 部署的副本 Pod 会分布在各个 Node 上，每个 Node 都可能运行好几个副本。DaemonSet 的不同之处在于：每个 Node 上最多只能运行一个副本。

DaemonSet 的典型应用场景有：

  1. 在集群的每个节点上运行存储 Daemon，比如 glusterd 或 ceph。

  2. 在每个节点上运行日志收集 Daemon，比如 flunentd 或 logstash。

  3. 在每个节点上运行监控 Daemon，比如 Prometheus Node Exporter 或 collectd。

其实 Kubernetes 自己就在用 DaemonSet 运行系统组件。执行如下命令：

kubectl get daemonset --namespace=kube-system


DaemonSet kube-flannel-ds 和 kube-proxy 分别负责在每个节点上运行 flannel 和 kube-proxy 组件。

因为 flannel 和 kube-proxy 属于系统组件，需要在命令行中通过 --namespace=kube-system 指定 namespace kube-system。如果不指定则只返回默认 namespace default 中的资源。

 

九、本节详细分析两个 k8s 自己的 DaemonSet：kube-flannel-ds 和 kube-proxy 。

kube-flannel-ds

下面我们通过分析 kube-flannel-ds 来学习 DaemonSet。

还记得之前是如何部署 flannel 网络的吗？我们执行了如下两个命令：

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

flannel 的 DaemonSet 就定义在 kube-flannel.yml 中：

注：配置文件的完整内容要复杂些，为了更好地学习 DaemonSet，这里只保留了最重要的内容。

① DaemonSet 配置文件的语法和结构与 Deployment 几乎完全一样，只是将 kind 设为 DaemonSet。

② hostNetwork 指定 Pod 直接使用的是 Node 的网络，相当于 docker run --network=host。考虑到 flannel 需要为集群提供网络连接，这个要求是合理的。

③ containers 定义了运行 flannel 服务的两个容器。

我们再来分析另一个 DaemonSet kube-proxy。

kube-proxy

由于无法拿到 kube-proxy 的 YAML 文件，只能运行如下命令查看其配置：

kubectl edit daemonset kube-proxy --namespace=kube-system

同样为了便于理解，这里只保留了最重要的信息。

① kind: DaemonSet 指定这是一个 DaemonSet 类型的资源。

② containers 定义了 kube-proxy 的容器。

③ status 是当前 DaemonSet 的运行时状态，这个部分是 kubectl edit特有的。其实 Kubernetes 集群中每个当前运行的资源都可以通过 kubectl edit 查看其配置和运行状态，比如 kubectl edit deployment nginx-deployment。

 

十、如何运行自己的 DaemonSet

以 Prometheus Node Exporter 为例演示如何运行自己的 DaemonSet。

Prometheus 是流行的系统监控方案，Node Exporter 是 Prometheus 的 agent，以 Daemon 的形式运行在每个被监控节点上。

如果是直接在 Docker 中运行 Node Exporter 容器，命令为：

docker run -d \
  -v "/proc:/host/proc" \
  -v "/sys:/host/sys" \
  -v "/:/rootfs" \
  --net=host \  prom/node-exporter \
  --path.procfs /host/proc \
  --path.sysfs /host/sys \
  --collector.filesystem.ignored-mount-points "^/(sys|proc|dev|host|etc)($|/)"

将其转换为 DaemonSet 的 YAML 配置文件 node_exporter.yml：

① 直接使用 Host 的网络。
② 设置容器启动命令。
③ 通过 Volume 将 Host 路径 /proc、/sys 和 / 映射到容器中。我们将在后面详细讨论 Volume。

执行 kubectl apply -f node_exporter.yml：

DaemonSet node-exporter-daemonset 部署成功，k8s-node1 和 k8s-node2 上分别运行了一个 node exporter Pod。

 

十一、容器按照持续运行的时间进行分类

容器按照持续运行的时间可分为两类：服务类容器和工作类容器。

服务类容器通常持续提供服务，需要一直运行，比如 http server，daemon 等。工作类容器则是一次性任务，比如批处理程序，完成后容器就退出。

Kubernetes 的 Deployment、ReplicaSet 和 DaemonSet 都用于管理服务类容器；对于工作类容器，我们用 Job。

先看一个简单的 Job 配置文件 myjob.yml：

① batch/v1 是当前 Job 的 apiVersion。

② 指明当前资源的类型为 Job。

③ restartPolicy 指定什么情况下需要重启容器。对于 Job，只能设置为 Never 或者 OnFailure。对于其他 controller（比如 Deployment）可以设置为 Always 。

通过 kubectl apply -f myjob.yml 启动 Job。

kubectl get job 查看 Job 的状态：

DESIRED 和 SUCCESSFUL 都为 1，表示按照预期启动了一个 Pod，并且已经成功执行。kubectl get pod 查看 Pod 的状态：

因为 Pod 执行完毕后容器已经退出，需要用 --show-all 才能查看 Completed 状态的 Pod。

kubectl logs 可以查看 Pod 的标准输出：

 

十一、Job执行失败的解决方法

如果Job执行失败了会怎么样呢？

修改 myjob.yml，故意引入一个错误：

646.png

先删除之前的 Job：

648.png

如果将 restartPolicy 设置为 OnFailure 会怎么样？下面我们实践一下，修改 myjob.yml 后重新启动。

运行新的 Job 并查看状态：

647.png

当前 SUCCESSFUL 的 Pod 数量为 0，查看 Pod 的状态：

649.png

可以看到有多个 Pod，状态均不正常。kubectl describe pod 查看某个 Pod 的启动日志：

650.png

日志显示没有可执行程序，符合我们的预期。

下面解释一个现象：为什么 kubectl get pod 会看到这么多个失败的 Pod？

原因是：当第一个 Pod 启动时，容器失败退出，根据 restartPolicy: Never，此失败容器不会被重启，但 Job DESIRED 的 Pod 是 1，目前 SUCCESSFUL 为 0，不满足，所以 Job controller 会启动新的 Pod，直到 SUCCESSFUL 为 1。对于我们这个例子，SUCCESSFUL 永远也到不了 1，所以 Job controller 会一直创建新的 Pod。为了终止这个行为，只能删除 Job。

648.png

如果将 restartPolicy 设置为 OnFailure 会怎么样？下面我们实践一下，修改 myjob.yml 后重新启动。

651.png

Job 的 SUCCESSFUL Pod 数量还是为 0，看看 Pod 的情况：

652.png

这里只有一个 Pod，不过 RESTARTS 为 3，而且不断增加，说明 OnFailure 生效，容器失败后会自动重启。

 

十二、提高 Job 执行效率的方法。

我们希望能同时运行多个 Pod，提高 Job 的执行效率。这个可以通过 parallelism 设置。

这里我们将并行的 Pod 数量设置为 2，实践一下：

Job 一共启动了两个 Pod，而且 AGE 相同，可见是并行运行的。

我们还可以通过 completions 设置 Job 成功完成 Pod 的总数：

上面配置的含义是：每次运行两个 Pod，直到总共有 6 个 Pod 成功完成。实践一下：

DESIRED 和 SUCCESSFUL 均为 6，符合预期。如果不指定 completions 和 parallelism，默认值均为 1。

上面的例子只是为了演示 Job 的并行特性，实际用途不大。不过现实中确实存在很多需要并行处理的场景。比如批处理程序，每个副本（Pod）都会从任务池中读取任务并执行，副本越多，执行时间就越短，效率就越高。这种类似的场景都可以用 Job 来实现。

 

十三、如何定时执行 Job

Linux 中有 cron 程序定时执行任务，Kubernetes 的 CronJob 提供了类似的功能，可以定时执行 Job。CronJob 配置文件示例如下：

① batch/v2alpha1 是当前 CronJob 的 apiVersion。

② 指明当前资源的类型为 CronJob。

③ schedule 指定什么时候运行 Job，其格式与 Linux cron 一致。这里 */1 * * * * 的含义是每一分钟启动一次。

④ jobTemplate 定义 Job 的模板，格式与前面 Job 一致。

接下来通过 kubectl apply 创建 CronJob。

失败了。这是因为 Kubernetes 默认没有 enable CronJob 功能，需要在 kube-apiserver 中加入这个功能。方法很简单，修改 kube-apiserver 的配置文件 /etc/kubernetes/manifests/kube-apiserver.yaml：

kube-apiserver 本身也是个 Pod，在启动参数中加上 --runtime-config=batch/v2alpha1=true 即可。

然后重启 kubelet 服务：

systemctl restart kubelet.service

kubelet 会重启 kube-apiserver Pod。通过 kubectl api-versions 确认 kube-apiserver 现在已经支持 batch/v2alpha1：

再次创建CronJob：

这次成功了。通过 kubectl get cronjob 查看 CronJob 的状态：

等待几分钟，然后通过 kubectl get jobs 查看 Job 的执行情况：

可以看到每隔一分钟就会启动一个 Job。执行 kubectl logs 可查看某个 Job 的运行日志：

小结

运行容器化应用是 Kubernetes 最重要的核心功能。为满足不同的业务需要，Kubernetes 提供了多种 Controller，包括 Deployment、DaemonSet、Job、CronJob 等。本章我们通过实践详细学习了这些 Controller，并讨论了它们的特性和应用场景。

 

十四、讲解 Service

我们不应该期望 Kubernetes Pod 是健壮的，而是要假设 Pod 中的容器很可能因为各种原因发生故障而死掉。Deployment 等 controller 会通过动态创建和销毁 Pod 来保证应用整体的健壮性。换句话说，Pod 是脆弱的，但应用是健壮的。

每个 Pod 都有自己的 IP 地址。当 controller 用新 Pod 替代发生故障的 Pod 时，新 Pod 会分配到新的 IP 地址。这样就产生了一个问题：

如果一组 Pod 对外提供服务（比如 HTTP），它们的 IP 很有可能发生变化，那么客户端如何找到并访问这个服务呢？

Kubernetes 给出的解决方案是 Service。

创建 Service

Kubernetes Service 从逻辑上代表了一组 Pod，具体是哪些 Pod 则是由 label 来挑选。Service 有自己 IP，而且这个 IP 是不变的。客户端只需要访问 Service 的 IP，Kubernetes 则负责建立和维护 Service 与 Pod 的映射关系。无论后端 Pod 如何变化，对客户端不会有任何影响，因为 Service 没有变。

来看个例子，创建下面的这个 Deployment：

我们启动了三个 Pod，运行 httpd 镜像，label 是 run: httpd，Service 将会用这个 label 来挑选 Pod。

Pod 分配了各自的 IP，这些 IP 只能被 Kubernetes Cluster 中的容器和节点访问。

接下来创建 Service，其配置文件如下：

① v1 是 Service 的 apiVersion。

② 指明当前资源的类型为 Service。

③ Service 的名字为 httpd-svc。

④ selector 指明挑选那些 label 为 run: httpd 的 Pod 作为 Service 的后端。

⑤ 将 Service 的 8080 端口映射到 Pod 的 80 端口，使用 TCP 协议。

执行 kubectl apply 创建 Service httpd-svc。

httpd-svc 分配到一个 CLUSTER-IP 10.99.229.179。可以通过该 IP 访问后端的 httpd Pod。

根据前面的端口映射，这里要使用 8080 端口。另外，除了我们创建的 httpd-svc，还有一个 Service kubernetes，Cluster 内部通过这个 Service 访问 kubernetes API Server。

通过 kubectl describe 可以查看 httpd-svc 与 Pod 的对应关系。

Endpoints 罗列了三个 Pod 的 IP 和端口。我们知道 Pod 的 IP 是在容器中配置的，那么 Service 的 Cluster IP 又是配置在哪里的呢？CLUSTER-IP 又是如何映射到 Pod IP 的呢？

 

十五、Service IP 原理

Service Cluster IP 是一个虚拟 IP，是由 Kubernetes 节点上的 iptables 规则管理的。

可以通过 iptables-save 命令打印出当前节点的 iptables 规则，因为输出较多，这里只截取与 httpd-svc Cluster IP 10.99.229.179 相关的信息：

这两条规则的含义是：

  1. 如果 Cluster 内的 Pod（源地址来自 10.244.0.0/16）要访问 httpd-svc，则允许。

  2. 其他源地址访问 httpd-svc，跳转到规则 KUBE-SVC-RL3JAE4GN7VOGDGP。

KUBE-SVC-RL3JAE4GN7VOGDGP 规则如下：

  1. 1/3 的概率跳转到规则 KUBE-SEP-C5KB52P4BBJQ35PH。

  2. 1/3 的概率（剩下 2/3 的一半）跳转到规则 KUBE-SEP-HGVKQQZZCF7RV4IT。

  3. 1/3 的概率跳转到规则 KUBE-SEP-XE25WGVXLHEIRVO5。

上面三个跳转的规则如下：

即将请求分别转发到后端的三个 Pod。通过上面的分析，我们得到如下结论：

iptables 将访问 Service 的流量转发到后端 Pod，而且使用类似轮询的负载均衡策略。

另外需要补充一点：Cluster 的每一个节点都配置了相同的 iptables 规则，这样就确保了整个 Cluster 都能够通过 Service 的 Cluster IP 访问 Service。

除了直接通过 Cluster IP 访问到 Service，DNS 是更加便捷的方式。

 

十六、DNS访问Service

在 Cluster 中，除了可以通过 Cluster IP 访问 Service，Kubernetes 还提供了更为方便的 DNS 访问。

kubeadm 部署时会默认安装 kube-dns 组件。

kube-dns 是一个 DNS 服务器。每当有新的 Service 被创建，kube-dns 会添加该 Service 的 DNS 记录。Cluster 中的 Pod 可以通过 <SERVICE_NAME>.<NAMESPACE_NAME> 访问 Service。

比如可以用 httpd-svc.default 访问 Service httpd-svc。

如上所示，我们在一个临时的 busybox Pod 中验证了 DNS 的有效性。另外，由于这个 Pod 与 httpd-svc 同属于 default namespace，可以省略 default 直接用 httpd-svc 访问 Service。

用 nslookup 查看 httpd-svc 的 DNS 的信息。

DNS 服务器是 kube-dns.kube-system.svc.cluster.local，这实际上就是 kube-dns 组件，它本身是部署在 kube-system namespace 中的一个 Service。

httpd-svc.default.svc.cluster.local 是 httpd-svc 的完整域名。

如果要访问其他 namespace 中的 Service，就必须带上 namesapce 了。kubectl get namespace 查看已有的 namespace。

在 kube-public 中部署 Service httpd2-svc，配置如下：

通过 namespace: kube-public 指定资源所属的 namespace。多个资源可以在一个 YAML 文件中定义，用 --- 分割。执行 kubectl apply 创建资源：

查看 kube-public 的 Service：

在 busybox Pod 中访问 httpd2-svc：

因为属于不同的 namespace，必须使用 httpd2-svc.kube-public 才能访问到。

Kubernetes 集群内部可以通过 Cluster IP 和 DNS 访问 Service。

 

十七、外网如何访问Service

除了 Cluster 内部可以访问 Service，很多情况我们也希望应用的 Service 能够暴露给 Cluster 外部。Kubernetes 提供了多种类型的 Service，默认是 ClusterIP。

ClusterIP 
Service 通过 Cluster 内部的 IP 对外提供服务，只有 Cluster 内的节点和 Pod 可访问，这是默认的 Service 类型，前面实验中的 Service 都是 ClusterIP。

NodePort 
Service 通过 Cluster 节点的静态端口对外提供服务。Cluster 外部可以通过 <NodeIP>:<NodePort> 访问 Service。

LoadBalancer 
Service 利用 cloud provider 特有的 load balancer 对外提供服务，cloud provider 负责将 load balancer 的流量导向 Service。目前支持的 cloud provider 有 GCP、AWS、Azur 等。

下面我们来实践 NodePort，Service httpd-svc 的配置文件修改如下：

添加 type: NodePort，重新创建 httpd-svc。

Kubernetes 依然会为 httpd-svc 分配一个 ClusterIP，不同的是：

  1. EXTERNAL-IP 为 nodes，表示可通过 Cluster 每个节点自身的 IP 访问 Service。

  2. PORT(S) 为 8080:32312。8080 是 ClusterIP 监听的端口，32312 则是节点上监听的端口。Kubernetes 会从 30000-32767 中分配一个可用的端口，每个节点都会监听此端口并将请求转发给 Service。

下面测试 NodePort 是否正常工作。

通过三个节点 IP + 32312 端口都能够访问 httpd-svc。

接下来我们深入探讨一个问题：Kubernetes 是如何将 <NodeIP>:<NodePort> 映射到 Pod 的呢？

与 ClusterIP 一样，也是借助了 iptables。与 ClusterIP 相比，每个节点的 iptables 中都增加了下面两条规则：

规则的含义是：访问当前节点 32312 端口的请求会应用规则 KUBE-SVC-RL3JAE4GN7VOGDGP，内容为：

其作用就是负载均衡到每一个 Pod。

NodePort 默认是的随机选择，不过我们可以用 nodePort 指定某个特定端口。

现在配置文件中就有三个 Port 了：
nodePort 是节点上监听的端口。
port 是 ClusterIP 上监听的端口。
targetPort 是 Pod 监听的端口。

最终，Node 和 ClusterIP 在各自端口上接收到的请求都会通过 iptables 转发到 Pod 的 targetPort。

应用新的 nodePort 并验证：

nodePort: 30000 已经生效了。

小结

本章我们讨论访问应用的机制 Service，学习了如何创建 Service；Service 的三种类型 ClusterIP、NodePort 和 LoadBalancer，以及它们各自的适用场景。

 

十八、Rolling Update

滚动更新是一次只更新一小部分副本，成功后，再更新更多的副本，最终完成所有副本的更新。滚动更新的最大的好处是零停机，整个更新过程始终有副本在运行，从而保证了业务的连续性。

下面我们部署三副本应用，初始镜像为 httpd:2.2.31，然后将其更新到 httpd:2.2.32。

httpd:2.2.31 的配置文件如下：

通过 kubectl apply 部署。

部署过程如下：

  1. 创建 Deployment httpd

  2. 创建 ReplicaSet httpd-551879778

  3. 创建三个 Pod

  4. 当前镜像为 httpd:2.2.31

将配置文件中 httpd:2.2.31 替换为 httpd:2.2.32，再次执行 kubectl apply。

我们发现了如下变化：

  1. Deployment httpd 的镜像更新为 httpd:2.2.32

  2. 新创建了 ReplicaSet httpd-1276601241，镜像为 httpd:2.2.32，并且管理了三个新的 Pod。

  3. 之前的 ReplicaSet httpd-551879778 里面已经没有任何 Pod。

结论是：ReplicaSet httpd-551879778 的三个 httpd:2.2.31 Pod 已经被 ReplicaSet httpd-1276601241 的三个 httpd:2.2.32 Pod 替换了。

具体过程可以通过 kubectl describe deployment httpd 查看。

每次只更新替换一个 Pod：

  1. ReplicaSet httpd-1276601241 增加一个 Pod，总数为 1。

  2. ReplicaSet httpd-551879778 减少一个 Pod，总数为 2。

  3. ReplicaSet httpd-1276601241 增加一个 Pod，总数为 2。

  4. ReplicaSet httpd-551879778 减少一个 Pod，总数为 1。

  5. ReplicaSet httpd-1276601241 增加一个 Pod，总数为 3。

  6. ReplicaSet httpd-551879778 减少一个 Pod，总数为 0。

每次替换的 Pod 数量是可以定制的。Kubernetes 提供了两个参数 maxSurge 和 maxUnavailable 来精细控制 Pod 的替换数量，我们将在后面结合 Health Check 特性一起讨论。

 

十九、回滚

kubectl apply 每次更新应用时 Kubernetes 都会记录下当前的配置，保存为一个 revision（版次），这样就可以回滚到某个特定 revision。

默认配置下，Kubernetes 只会保留最近的几个 revision，可以在 Deployment 配置文件中通过 revisionHistoryLimit 属性增加 revision 数量。

下面实践回滚功能。应用有如下三个配置文件 httpd.v1.yml，httpd.v2.yml 和 httpd.v3.yml，分别对应不同的 httpd 镜像 2.4.16，2.4.17 和 2.4.18：

通过 kubectl apply 部署并更新应用：

--record 的作用是将当前命令记录到 revision 记录中，这样我们就可以知道每个 revison 对应的是哪个配置文件。通过 kubectl rollout history deployment httpd 查看 revison 历史记录。

CHANGE-CAUSE 就是 --record 的结果。如果要回滚到某个版本，比如 revision 1，可以执行命令 kubectl rollout undo deployment httpd --to-revision=1：

此时，revison 历史记录也会发生相应变化。

revison 1 变成了 revison 4。不过我们可以通过 CHANGE-CAUSE 知道每个 revison 的具体含义。所以一定要在执行 kubectl apply 时加上 --record参数。

 

二十、Health Check（健康检查）

强大的自愈能力是 Kubernetes 这类容器编排引擎的一个重要特性。自愈的默认实现方式是自动重启发生故障的容器。除此之外，用户还可以利用 Liveness 和 Readiness 探测机制设置更精细的健康检查，进而实现如下需求：

  1. 零停机部署。

  2. 避免部署无效的镜像。

  3. 更加安全的滚动升级。

下面通过实践学习 Kubernetes 的 Health Check 功能。

默认的健康检查

我们首先学习 Kubernetes 默认的健康检查机制：

每个容器启动时都会执行一个进程，此进程由 Dockerfile 的 CMD 或 ENTRYPOINT 指定。如果进程退出时返回码非零，则认为容器发生故障，Kubernetes 就会根据 restartPolicy 重启容器。

下面我们模拟一个容器发生故障的场景，Pod 配置文件如下：

Pod 的 restartPolicy 设置为 OnFailure，默认为 Always。

sleep 10; exit 1 模拟容器启动 10 秒后发生故障。

执行 kubectl apply 创建 Pod，命名为 healthcheck。

过几分钟查看 Pod 的状态：

可看到容器当前已经重启了 3 次。

在上面的例子中，容器进程返回值非零，Kubernetes 则认为容器发生故障，需要重启。但有不少情况是发生了故障，但进程并不会退出。比如访问 Web 服务器时显示 500 内部错误，可能是系统超载，也可能是资源死锁，此时 httpd 进程并没有异常退出，在这种情况下重启容器可能是最直接最有效的解决方案，那我们如何利用 Health Check 机制来处理这类场景呢？

 

二十一、Liveness 探测

Liveness 探测让用户可以自定义判断容器是否健康的条件。如果探测失败，Kubernetes 就会重启容器。

还是举例说明，创建如下 Pod：

启动进程首先创建文件 /tmp/healthy，30 秒后删除，在我们的设定中，如果 /tmp/healthy 文件存在，则认为容器处于正常状态，反正则发生故障。

livenessProbe 部分定义如何执行 Liveness 探测：

  1. 探测的方法是：通过 cat 命令检查 /tmp/healthy 文件是否存在。如果命令执行成功，返回值为零，Kubernetes 则认为本次 Liveness 探测成功；如果命令返回值非零，本次 Liveness 探测失败。

  2. initialDelaySeconds: 10 指定容器启动 10 之后开始执行 Liveness 探测，我们一般会根据应用启动的准备时间来设置。比如某个应用正常启动要花 30 秒，那么 initialDelaySeconds 的值就应该大于 30。

  3. periodSeconds: 5 指定每 5 秒执行一次 Liveness 探测。Kubernetes 如果连续执行 3 次 Liveness 探测均失败，则会杀掉并重启容器。

下面创建 Pod liveness：

从配置文件可知，最开始的 30 秒，/tmp/healthy 存在，cat 命令返回 0，Liveness 探测成功，这段时间 kubectl describe pod liveness 的 Events部分会显示正常的日志。

35 秒之后，日志会显示 /tmp/healthy 已经不存在，Liveness 探测失败。再过几十秒，几次探测都失败后，容器会被重启。

 

二十二、Readiness 探测

除了 Liveness 探测，Kubernetes Health Check 机制还包括 Readiness 探测。

用户通过 Liveness 探测可以告诉 Kubernetes 什么时候通过重启容器实现自愈；Readiness 探测则是告诉 Kubernetes 什么时候可以将容器加入到 Service 负载均衡池中，对外提供服务。

Readiness 探测的配置语法与 Liveness 探测完全一样，下面是个例子：

这个配置文件只是将前面例子中的 liveness 替换为了 readiness，我们看看有什么不同的效果。

Pod readiness 的 READY 状态经历了如下变化：

  1. 刚被创建时，READY 状态为不可用。

  2. 15 秒后（initialDelaySeconds + periodSeconds），第一次进行 Readiness 探测并成功返回，设置 READY 为可用。

  3. 30 秒后，/tmp/healthy 被删除，连续 3 次 Readiness 探测均失败后，READY 被设置为不可用。

通过 kubectl describe pod readiness 也可以看到 Readiness 探测失败的日志。

下面对 Liveness 探测和 Readiness 探测做个比较：

  1. Liveness 探测和 Readiness 探测是两种 Health Check 机制，如果不特意配置，Kubernetes 将对两种探测采取相同的默认行为，即通过判断容器启动进程的返回值是否为零来判断探测是否成功。

  2. 两种探测的配置方法完全一样，支持的配置参数也一样。不同之处在于探测失败后的行为：Liveness 探测是重启容器；Readiness 探测则是将容器设置为不可用，不接收 Service 转发的请求。

  3. Liveness 探测和 Readiness 探测是独立执行的，二者之间没有依赖，所以可以单独使用，也可以同时使用。用 Liveness 探测判断容器是否需要重启以实现自愈；用 Readiness 探测判断容器是否已经准备好对外提供服务。

二十三、在 Scale Up 中使用 Health Check

对于多副本应用，当执行 Scale Up 操作时，新副本会作为 backend 被添加到 Service 的负载均衡中，与已有副本一起处理客户的请求。考虑到应用启动通常都需要一个准备阶段，比如加载缓存数据，连接数据库等，从容器启动到正真能够提供服务是需要一段时间的。我们可以通过 Readiness 探测判断容器是否就绪，避免将请求发送到还没有 ready 的 backend。

下面是示例应用的配置文件。

重点关注 readinessProbe 部分。这里我们使用了不同于 exec 的另一种探测方法 -- httpGet。Kubernetes 对于该方法探测成功的判断条件是 http 请求的返回代码在 200-400 之间。

schema 指定协议，支持 HTTP（默认值）和 HTTPS。
path 指定访问路径。
port 指定端口。

上面配置的作用是：

  1. 容器启动 10 秒之后开始探测。

  2. 如果 http://[container_ip]:8080/healthy 返回代码不是 200-400，表示容器没有就绪，不接收 Service web-svc 的请求。

  3. 每隔 5 秒再探测一次。

  4. 直到返回代码为 200-400，表明容器已经就绪，然后将其加入到 web-svc 的负责均衡中，开始处理客户请求。

  5. 探测会继续以 5 秒的间隔执行，如果连续发生 3 次失败，容器又会从负载均衡中移除，直到下次探测成功重新加入。

对于 http://[container_ip]:8080/healthy，应用则可以实现自己的判断逻辑，比如检查所依赖的数据库是否就绪，示例代码如下：

① 定义 /healthy 的处理函数。

② 连接数据库并执行测试 SQL。

③ 测试成功，正常返回，代码 200。

④ 测试失败，返回错误代码 503。

⑤ 在 8080 端口监听。

对于生产环境中重要的应用都建议配置 Health Check，保证处理客户请求的容器都是准备就绪的 Service backend。

以上是 Health Check 在 Scale Up 中的应用。

 

二十四、在Rolling Update 中使用Health Check 

上一节讨论了 Health Check 在 Scale Up 中的应用，Health Check 另一个重要的应用场景是 Rolling Update。试想一下下面的情况：

现有一个正常运行的多副本应用，接下来对应用进行更新（比如使用更高版本的 image），Kubernetes 会启动新副本，然后发生了如下事件：

  1. 正常情况下新副本需要 10 秒钟完成准备工作，在此之前无法响应业务请求。

  2. 但由于人为配置错误，副本始终无法完成准备工作（比如无法连接后端数据库）。

先别继续往下看，现在请花一分钟思考这个问题：如果没有配置 Health Check，会出现怎样的情况？

因为新副本本身没有异常退出，默认的 Health Check 机制会认为容器已经就绪，进而会逐步用新副本替换现有副本，其结果就是：当所有旧副本都被替换后，整个应用将无法处理请求，无法对外提供服务。如果这是发生在重要的生产系统上，后果会非常严重。

如果正确配置了 Health Check，新副本只有通过了 Readiness 探测，才会被添加到 Service；如果没有通过探测，现有副本不会被全部替换，业务仍然正常进行。

下面通过例子来实践 Health Check 在 Rolling Update 中的应用。

用如下配置文件 app.v1.yml 模拟一个 10 副本的应用：

10 秒后副本能够通过 Readiness 探测。

接下来滚动更新应用，配置文件 app.v2.yml 如下：

很显然，由于新副本中不存在 /tmp/healthy，是无法通过 Readiness 探测的。验证如下：

这个截图包含了大量的信息，值得我们详细分析。

先关注 kubectl get pod 输出：

  1. 从 Pod 的 AGE 栏可判断，最后 5 个 Pod 是新副本，目前处于 NOT READY 状态。

  2. 旧副本从最初 10 个减少到 8 个。

再来看 kubectl get deployment app 的输出：

  1. DESIRED 10 表示期望的状态是 10 个 READY 的副本。

  2. CURRENT 13 表示当前副本的总数：即 8 个旧副本 + 5 个新副本。

  3. UP-TO-DATE 5 表示当前已经完成更新的副本数：即 5 个新副本。

  4. AVAILABLE 8 表示当前处于 READY 状态的副本数：即 8个旧副本。

在我们的设定中，新副本始终都无法通过 Readiness 探测，所以这个状态会一直保持下去。

上面我们模拟了一个滚动更新失败的场景。不过幸运的是：Health Check 帮我们屏蔽了有缺陷的副本，同时保留了大部分旧副本，业务没有因更新失败受到影响。

接下来我们要回答：为什么新创建的副本数是 5 个，同时只销毁了 2 个旧副本？

原因是：滚动更新通过参数 maxSurge 和 maxUnavailable 来控制副本替换的数量。

maxSurge

此参数控制滚动更新过程中副本总数的超过 DESIRED 的上限。maxSurge 可以是具体的整数（比如 3），也可以是百分百，向上取整。maxSurge 默认值为 25%。

在上面的例子中，DESIRED 为 10，那么副本总数的最大值为：
roundUp(10 + 10 * 25%) = 13

所以我们看到 CURRENT 就是 13。

maxUnavailable

此参数控制滚动更新过程中，不可用的副本相占 DESIRED 的最大比例。 maxUnavailable 可以是具体的整数（比如 3），也可以是百分百，向下取整。maxUnavailable 默认值为 25%。

在上面的例子中，DESIRED 为 10，那么可用的副本数至少要为：
10 - roundDown(10 * 25%) = 8

所以我们看到 AVAILABLE 就是 8。

maxSurge 值越大，初始创建的新副本数量就越多；maxUnavailable 值越大，初始销毁的旧副本数量就越多。

理想情况下，我们这个案例滚动更新的过程应该是这样的：

  1. 首先创建 3 个新副本使副本总数达到 13 个。

  2. 然后销毁 2 个旧副本使可用的副本数降到 8 个。

  3. 当这 2 个旧副本成功销毁后，可再创建 2 个新副本，使副本总数保持为 13 个。

  4. 当新副本通过 Readiness 探测后，会使可用副本数增加，超过 8。

  5. 进而可以继续销毁更多的旧副本，使可用副本数回到 8。

  6. 旧副本的销毁使副本总数低于 13，这样就允许创建更多的新副本。

  7. 这个过程会持续进行，最终所有的旧副本都会被新副本替换，滚动更新完成。

而我们的实际情况是在第 4 步就卡住了，新副本无法通过 Readiness 探测。这个过程可以在 kubectl describe deployment app 的日志部分查看。

如果滚动更新失败，可以通过 kubectl rollout undo 回滚到上一个版本。

如果要定制 maxSurge 和 maxUnavailable，可以如下配置：

小结

本章我们讨论了 Kubernetes 健康检查的两种机制：Liveness 探测和 Readiness 探测，并实践了健康检查在 Scale Up 和 Rolling Update 场景中的应用。

 

二十五、Kubernetes 如何管理存储资源 

首先我们会学习 Volume，以及 Kubernetes 如何通过 Volume 为集群中的容器提供存储；然后我们会实践几种常用的 Volume 类型并理解它们各自的应用场景；最后，我们会讨论 Kubernetes 如何通过 Persistent Volume 和 Persistent Volume Claim 分离集群管理员与集群用户的职责，并实践 Volume 的静态供给和动态供给。

Volume

本节我们讨论 Kubernetes 的存储模型 Volume，学习如何将各种持久化存储映射到容器。

我们经常会说：容器和 Pod 是短暂的。
其含义是它们的生命周期可能很短，会被频繁地销毁和创建。容器销毁时，保存在容器内部文件系统中的数据都会被清除。

为了持久化保存容器的数据，可以使用 Kubernetes Volume。

Volume 的生命周期独立于容器，Pod 中的容器可能被销毁和重建，但 Volume 会被保留。

本质上，Kubernetes Volume 是一个目录，这一点与 Docker Volume 类似。当 Volume 被 mount 到 Pod，Pod 中的所有容器都可以访问这个 Volume。Kubernetes Volume 也支持多种 backend 类型，包括 emptyDir、hostPath、GCE Persistent Disk、AWS Elastic Block Store、NFS、Ceph 等，完整列表可参考 https://kubernetes.io/docs/concepts/storage/volumes/#types-of-volumes

Volume 提供了对各种 backend 的抽象，容器在使用 Volume 读写数据的时候不需要关心数据到底是存放在本地节点的文件系统中呢还是云硬盘上。对它来说，所有类型的 Volume 都只是一个目录。

我们将从最简单的 emptyDir 开始学习 Kubernetes Volume。

emptyDir

emptyDir 是最基础的 Volume 类型。正如其名字所示，一个 emptyDir Volume 是 Host 上的一个空目录。

emptyDir Volume 对于容器来说是持久的，对于 Pod 则不是。当 Pod 从节点删除时，Volume 的内容也会被删除。但如果只是容器被销毁而 Pod 还在，则 Volume 不受影响。

也就是说：emptyDir Volume 的生命周期与 Pod 一致。

Pod 中的所有容器都可以共享 Volume，它们可以指定各自的 mount 路径。下面通过例子来实践 emptyDir，配置文件如下：

这里我们模拟了一个 producer-consumer 场景。Pod 有两个容器 producer和 consumer，它们共享一个 Volume。producer 负责往 Volume 中写数据，consumer 则是从 Volume 读取数据。

① 文件最底部 volumes 定义了一个 emptyDir 类型的 Volume shared-volume。

② producer 容器将 shared-volume mount 到 /producer_dir 目录。

③ producer 通过 echo 将数据写到文件 hello 里。

④ consumer 容器将 shared-volume mount 到 /consumer_dir 目录。

⑤ consumer 通过 cat 从文件 hello 读数据。

执行如下命令创建 Pod：

kubectl logs 显示容器 consumer 成功读到了 producer 写入的数据，验证了两个容器共享 emptyDir Volume。

因为 emptyDir 是 Docker Host 文件系统里的目录，其效果相当于执行了 docker run -v /producer_dir 和 docker run -v /consumer_dir。通过 docker inspect 查看容器的详细配置信息，我们发现两个容器都 mount 了同一个目录：

这里 /var/lib/kubelet/pods/3e6100eb-a97a-11e7-8f72-0800274451ad/volumes/kubernetes.io~empty-dir/shared-volume 就是 emptyDir 在 Host 上的真正路径。

emptyDir 是 Host 上创建的临时目录，其优点是能够方便地为 Pod 中的容器提供共享存储，不需要额外的配置。但它不具备持久性，如果 Pod 不存在了，emptyDir 也就没有了。根据这个特性，emptyDir 特别适合 Pod 中的容器需要临时共享存储空间的场景，比如前面的生产者消费者用例。

 

二十六、 hostPath Volume

hostPath Volume 的作用是将 Docker Host 文件系统中已经存在的目录 mount 给 Pod 的容器。大部分应用都不会使用 hostPath Volume，因为这实际上增加了 Pod 与节点的耦合，限制了 Pod 的使用。不过那些需要访问 Kubernetes 或 Docker 内部数据（配置文件和二进制库）的应用则需要使用 hostPath。

比如 kube-apiserver 和 kube-controller-manager 就是这样的应用，通过

kubectl edit --namespace=kube-system pod kube-apiserver-k8s-master

查看 kube-apiserver Pod 的配置，下面是 Volume 的相关部分：

这里定义了三个 hostPath volume k8s、certs 和 pki，分别对应 Host 目录 /etc/kubernetes、/etc/ssl/certs 和 /etc/pki。

如果 Pod 被销毁了，hostPath 对应的目录也还会被保留，从这点看，hostPath 的持久性比 emptyDir 强。不过一旦 Host 崩溃，hostPath 也就没法访问了。

 

二十七、 外部 Storage Provider

 

如果 Kubernetes 部署在诸如 AWS、GCE、Azure 等公有云上，可以直接使用云硬盘作为 Volume，下面是 AWS Elastic Block Store 的例子：

要在 Pod 中使用 ESB volume，必须先在 AWS 中创建，然后通过 volume-id 引用。其他云硬盘的使用方法可参考各公有云厂商的官方文档。

Kubernetes Volume 也可以使用主流的分布式存，比如 Ceph、GlusterFS 等，下面是 Ceph 的例子：

Ceph 文件系统的 /some/path/in/side/cephfs 目录被 mount 到容器路径 /test-ceph。

相对于 emptyDir 和 hostPath，这些 Volume 类型的最大特点就是不依赖 Kubernetes。Volume 的底层基础设施由独立的存储系统管理，与 Kubernetes 集群是分离的。数据被持久化后，即使整个 Kubernetes 崩溃也不会受损。

当然，运维这样的存储系统通常不是项简单的工作，特别是对可靠性、高可用和扩展性有较高要求时。

Volume 提供了非常好的数据持久化方案，不过在可管理性上还有不足。

 

二十八、PV & PVC

Volume 提供了非常好的数据持久化方案，不过在可管理性上还有不足。

拿前面 AWS EBS 的例子来说，要使用 Volume，Pod 必须事先知道如下信息：

  1. 当前 Volume 来自 AWS EBS。

  2. EBS Volume 已经提前创建，并且知道确切的 volume-id。

Pod 通常是由应用的开发人员维护，而 Volume 则通常是由存储系统的管理员维护。开发人员要获得上面的信息：

  1. 要么询问管理员。

  2. 要么自己就是管理员。

这样就带来一个管理上的问题：应用开发人员和系统管理员的职责耦合在一起了。如果系统规模较小或者对于开发环境这样的情况还可以接受。但当集群规模变大，特别是对于生成环境，考虑到效率和安全性，这就成了必须要解决的问题。

Kubernetes 给出的解决方案是 PersistentVolume 和 PersistentVolumeClaim。

PersistentVolume (PV) 是外部存储系统中的一块存储空间，由管理员创建和维护。与 Volume 一样，PV 具有持久性，生命周期独立于 Pod。

PersistentVolumeClaim (PVC) 是对 PV 的申请 (Claim)。PVC 通常由普通用户创建和维护。需要为 Pod 分配存储资源时，用户可以创建一个 PVC，指明存储资源的容量大小和访问模式（比如只读）等信息，Kubernetes 会查找并提供满足条件的 PV。

有了 PersistentVolumeClaim，用户只需要告诉 Kubernetes 需要什么样的存储资源，而不必关心真正的空间从哪里分配，如何访问等底层细节信息。这些 Storage Provider 的底层信息交给管理员来处理，只有管理员才应该关心创建 PersistentVolume 的细节信息。

Kubernetes 支持多种类型的 PersistentVolume，比如 AWS EBS、Ceph、NFS 等，完整列表请参考 https://kubernetes.io/docs/concepts/storage/persistent-volumes/#types-of-persistent-volumes

 

二十八、NFS PersistentVolume

本节通过 NFS 实践。

作为准备工作，我们已经在 k8s-master 节点上搭建了一个 NFS 服务器，目录为 /nfsdata：

下面创建一个 PV mypv1，配置文件 nfs-pv1.yml 如下：

① capacity 指定 PV 的容量为 1G。

② accessModes 指定访问模式为 ReadWriteOnce，支持的访问模式有：
ReadWriteOnce – PV 能以 read-write 模式 mount 到单个节点。
ReadOnlyMany – PV 能以 read-only 模式 mount 到多个节点。
ReadWriteMany – PV 能以 read-write 模式 mount 到多个节点。

③ persistentVolumeReclaimPolicy 指定当 PV 的回收策略为 Recycle，支持的策略有：
Retain – 需要管理员手工回收。
Recycle – 清除 PV 中的数据，效果相当于执行 rm -rf /thevolume/*。
Delete – 删除 Storage Provider 上的对应存储资源，例如 AWS EBS、GCE PD、Azure Disk、OpenStack Cinder Volume 等。

④ storageClassName 指定 PV 的 class 为 nfs。相当于为 PV 设置了一个分类，PVC 可以指定 class 申请相应 class 的 PV。

⑤ 指定 PV 在 NFS 服务器上对应的目录。

创建 mypv1：

STATUS 为 Available，表示 mypv1 就绪，可以被 PVC 申请。

接下来创建 PVC mypvc1，配置文件 nfs-pvc1.yml 如下：

PVC 就很简单了，只需要指定 PV 的容量，访问模式和 class。

创建 mypvc1：

从 kubectl get pvc 和 kubectl get pv 的输出可以看到 mypvc1 已经 Bound 到 mypv1，申请成功。

接下来就可以在 Pod 中使用存储了，Pod 配置文件 pod1.yml 如下：

与使用普通 Volume 的格式类似，在 volumes 中通过 persistentVolumeClaim 指定使用 mypvc1 申请的 Volume。

创建 mypod1：

验证 PV 是否可用：

可见，在 Pod 中创建的文件 /mydata/hello 确实已经保存到了 NFS 服务器目录 /nfsdata/pv1 中。

如果不再需要使用 PV，可用删除 PVC 回收 PV。

 

二十九、回收PV

当 PV 不再需要时，可通过删除 PVC 回收。

当 PV 不再需要时，可通过删除 PVC 回收。

当 PVC mypvc1 被删除后，我们发现 Kubernetes 启动了一个新 Pod recycler-for-mypv1，这个 Pod 的作用就是清除 PV mypv1 的数据。此时 mypv1 的状态为 Released，表示已经解除了与 mypvc1 的 Bound，正在清除数据，不过此时还不可用。

当数据清除完毕，mypv1 的状态重新变为 Available，此时则可以被新的 PVC 申请。

/nfsdata/pv1 中的 hello 文件已经被删除了。

因为 PV 的回收策略设置为 Recycle，所以数据会被清除，但这可能不是我们想要的结果。如果我们希望保留数据，可以将策略设置为 Retain。

通过 kubectl apply 更新 PV：

回收策略已经变为 Retain，通过下面步骤验证其效果：

① 重新创建 mypvc1。

② 在 mypv1 中创建文件 hello。

③ mypv1 状态变为 Released。

④ Kubernetes 并没有启动 Pod recycler-for-mypv1。

⑤ PV 中的数据被完整保留。

虽然 mypv1 中的数据得到了保留，但其 PV 状态会一直处于 Released，不能被其他 PVC 申请。为了重新使用存储资源，可以删除并重新创建 mypv1。删除操作只是删除了 PV 对象，存储空间中的数据并不会被删除。

新建的 mypv1 状态为 Available，已经可以被 PVC 申请。

PV 还支持 Delete 的回收策略，会删除 PV 在 Storage Provider 上对应存储空间。NFS 的 PV 不支持 Delete，支持 Delete 的 Provider 有 AWS EBS、GCE PD、Azure Disk、OpenStack Cinder Volume 等。

 

三十、PV 动态供给

前面的例子中，我们提前创建了 PV，然后通过 PVC 申请 PV 并在 Pod 中使用，这种方式叫做静态供给（Static Provision）。

与之对应的是动态供给（Dynamical Provision），即如果没有满足 PVC 条件的 PV，会动态创建 PV。相比静态供给，动态供给有明显的优势：不需要提前创建 PV，减少了管理员的工作量，效率高。

动态供给是通过 StorageClass 实现的，StorageClass 定义了如何创建 PV，下面是两个例子。

StorageClass standard：

StorageClass slow：

这两个 StorageClass 都会动态创建 AWS EBS，不同在于 standard 创建的是 gp2 类型的 EBS，而 slow 创建的是 io1 类型的 EBS。不同类型的 EBS 支持的参数可参考 AWS 官方文档。

StorageClass 支持 Delete 和 Retain 两种 reclaimPolicy，默认是 Delete。

与之前一样，PVC 在申请 PV 时，只需要指定 StorageClass 和容量以及访问模式，比如：

除了 AWS EBS，Kubernetes 支持其他多种动态供给 PV 的 Provisioner，完整列表请参考 https://kubernetes.io/docs/concepts/storage/storage-classes/#provisioner

 

三十一、MySQL 如何使用 PV 和 PVC

本节演示如何为 MySQL 数据库提供持久化存储，步骤为：

  1. 创建 PV 和 PVC。

  2. 部署 MySQL。

  3. 向 MySQL 添加数据。

  4. 模拟节点宕机故障，Kubernetes 将 MySQL 自动迁移到其他节点。

  5. 验证数据一致性。

首先创建 PV 和 PVC，配置如下：

mysql-pv.yml

mysql-pvc.yml

创建 mysql-pv 和 mysql-pvc：

接下来部署 MySQL，配置文件如下：

PVC mysql-pvc Bound 的 PV mysql-pv 将被 mount 到 MySQL 的数据目录 var/lib/mysql。

MySQL 被部署到 k8s-node2，下面通过客户端访问 Service mysql：

kubectl run -it --rm --image=mysql:5.6 --restart=Never mysql-client -- mysql -h mysql -ppassword


更新数据库：

① 切换到数据库 mysql。

② 创建数据库表 my_id。

③ 插入一条数据。

④ 确认数据已经写入。

关闭 k8s-node2，模拟节点宕机故障。

一段时间后，Kubernetes 将 MySQL 迁移到 k8s-node1。

验证数据的一致性：

MySQL 服务恢复，数据也完好无损。

小结

本章我们讨论了 Kubernetes 如何管理存储资源。

emptyDir 和 hostPath 类型的 Volume 很方便，但可持久性不强，Kubernetes 支持多种外部存储系统的 Volume。

PV 和 PVC 分离了管理员和普通用户的职责，更适合生产环境。我们还学习了如何通过 StorageClass 实现更高效的动态供给。

最后，我们演示了如何在 MySQL 中使用 PersistentVolume 实现数据持久性。

 

三十二、用k8s管理机密信息 （例始用户和密码，不直接写在镜像中，这样不安全，通过Secret方案解决这个问题。）

应用启动过程中可能需要一些敏感信息，比如访问数据库的用户名密码或者秘钥。将这些信息直接保存在容器镜像中显然不妥，Kubernetes 提供的解决方案是 Secret。

Secret 会以密文的方式存储数据，避免了直接在配置文件中保存敏感信息。Secret 会以 Volume 的形式被 mount 到 Pod，容器可通过文件的方式使用 Secret 中的敏感数据；此外，容器也可以环境变量的方式使用这些数据。

Secret 可通过命令行或 YAML 创建。比如希望 Secret 中包含如下信息：

  1. 用户名 admin

  2. 密码 123456

创建 Secret

有四种方法创建 Secret：

1. 通过 --from-literal：

kubectl create secret generic mysecret --from-literal=username=admin --from-literal=password=123456

每个 --from-literal 对应一个信息条目。

2. 通过 --from-file：

echo -n admin > ./username
echo -n 123456 > ./password
kubectl create secret generic mysecret --from-file=./username --from-file=./password

每个文件内容对应一个信息条目。

3. 通过 --from-env-file：

cat << EOF > env.txt
username=admin
password=123456
EOF
kubectl create secret generic mysecret --from-env-file=env.txt

文件 env.txt 中每行 Key=Value 对应一个信息条目。

4. 通过 YAML 配置文件：

文件中的敏感数据必须是通过 base64 编码后的结果。

执行 kubectl apply 创建 Secret：

 

 三十三、查看Secret （查看用户和密码）

可以通过 kubectl get secret 查看存在的 secret。

显示有两个数据条目，kubectl describe secret 查看条目的 Key：

如果还想查看 Value，可以用 kubectl edit secret mysecret：

然后通过 base64 将 Value 反编码：

下节学习如何在 Pod 中使用 Secret。

 

三十四、volume方式使用Secret

Pod 可以通过 Volume 或者环境变量的方式使用 Secret，今天先学习 Volume 方式。

Pod 的配置文件如下所示：

① 定义 volume foo，来源为 secret mysecret。

② 将 foo mount 到容器路径 /etc/foo，可指定读写权限为 readOnly。

创建 Pod 并在容器中读取 Secret：

767.png

可以看到，Kubernetes 会在指定的路径 /etc/foo 下为每条敏感数据创建一个文件，文件名就是数据条目的 Key，这里是 /etc/foo/username 和 /etc/foo/password，Value 则以明文存放在文件中。

我们也可以自定义存放数据的文件名，比如将配置文件改为：

这时数据将分别存放在 /etc/foo/my-group/my-username 和 /etc/foo/my-group/my-password 中。

以 Volume 方式使用的 Secret 支持动态更新：Secret 更新后，容器中的数据也会更新。

将 password 更新为 abcdef，base64 编码为 YWJjZGVm

更新 Secret。

几秒钟或，新的 password 会同步到容器。

以上是通过 Volume 使用 Secret。

 

三十五、通过环境变量使用 Secret

通过 Volume 使用 Secret，容器必须从文件读取数据，会稍显麻烦，Kubernetes 还支持通过环境变量使用 Secret。

Pod 配置文件示例如下：

创建 Pod 并读取 Secret。

通过环境变量 SECRET_USERNAME 和 SECRET_PASSWORD 成功读取到 Secret 的数据。

需要注意的是，环境变量读取 Secret 很方便，但无法支撑 Secret 动态更新。

Secret 可以为 Pod 提供密码、Token、私钥等敏感数据；对于一些非敏感数据，比如应用的配置信息，则可以用 ConfigMap。

 

三十六、用 ConfigMap 管理配置

 

Secret 可以为 Pod 提供密码、Token、私钥等敏感数据；对于一些非敏感数据，比如应用的配置信息，则可以用 ConfigMap。

ConfigMap 的创建和使用方式与 Secret 非常类似，主要的不同是数据以明文的形式存放。

与 Secret 一样，ConfigMap 也支持四种创建方式：

1. 通过 --from-literal：

kubectl create configmap myconfigmap --from-literal=config1=xxx --from-literal=config2=yyy

每个 --from-literal 对应一个信息条目。

2. 通过 --from-file：

echo -n xxx > ./config1
echo -n yyy > ./config2
kubectl create configmap myconfigmap --from-file=./config1 --from-file=./config2

每个文件内容对应一个信息条目。

3. 通过 --from-env-file：

cat << EOF > env.txt
config1=xxx
config2=yyy
EOF
kubectl create configmap myconfigmap --from-env-file=env.txt

文件 env.txt 中每行 Key=Value 对应一个信息条目。

4. 通过 YAML 配置文件：
 
文件中的数据直接以明文输入。

与 Secret 一样，Pod 也可以通过 Volume 或者环境变量的方式使用 Secret。

Volume 方式：

环境变量方式：

大多数情况下，配置信息都以文件形式提供，所以在创建 ConfigMap 时通常采用 --from-file 或 YAML 方式，读取 ConfigMap 时通常采用 Volume 方式。

比如给 Pod 传递如何记录日志的配置信息：

可以采用 --from-file 形式，则将其保存在文件 logging.conf 中，然后执行命令：

kubectl create configmap myconfigmap --from-file=./logging.conf

如果采用 YAML 配置文件，其内容则为：

注意别漏写了 Key logging.conf 后面的 | 符号。

创建并查看 ConfigMap：

在 Pod 中使用此 ConfigMap，配置文件为：

① 在 volume 中指定存放配置信息的文件相对路径为 myapp/logging.conf。

② 将 volume mount 到容器的 /etc 目录。

创建 Pod 并读取配置信息：

配置信息已经保存到 /etc/myapp/logging.conf 文件中。与 Secret 一样，Volume 形式的 ConfigMap 也支持动态更新，留给大家自己实践。

小结

本章我们学习了如何向 Pod 传递配置信息。如果信息需要加密，可使用 Secret；如果是一般的配置信息，则可使用 ConfigMap。

Secret 和 ConfigMap 支持四种定义方法。Pod 在使用它们时，可以选择 Volume 方式或环境变量方式，不过只有 Volume 方式支持动态更新。

 

 三十七、why Helm?

本章我们将学习 Helm，Kubernetes 的包管理器。

每个成功的软件平台都有一个优秀的打包系统，比如 Debian、Ubuntu 的 apt，Redhat、Centos 的 yum。而 Helm 则是 Kubernetes 上的包管理器。

本章我们将讨论为什么需要 Helm，它的架构和组件，以及如何使用 Helm。

Why Helm

Helm 到底解决了什么问题？为什么 Kubernetes 需要 Helm？

答案是：Kubernetes 能够很好地组织和编排容器，但它缺少一个更高层次的应用打包工具，而 Helm 就是来干这件事的。

先来看个例子。
比如对于一个 MySQL 服务， Kubernetes 需要部署下面这些对象：

  1. Service，让外界能够访问到 MySQL。

  2. Secret，定义 MySQL 的密码。

  3. PersistentVolumeClaim，为 MySQL 申请持久化存储空间。

  4. Deployment，部署 MySQL Pod，并使用上面的这些支持对象。

我们可以将上面这些配置保存到对象各自的文件中，或者集中写进一个配置文件，然后通过 kubectl apply -f 部署。

到目前为止，Kubernetes 对服务的部署支持得都挺好，如果应用只由一个或几个这样的服务组成，上面的部署方式完全足够了。

但是，如果我们开发的是微服务架构的应用，组成应用的服务可能多达十个甚至几十上百个，这种组织和管理应用的方式就不好使了：

  1. 很难管理、编辑和维护如此多的服务。每个服务都有若干配置，缺乏一个更高层次的工具将这些配置组织起来。

  2. 不容易将这些服务作为一个整体统一发布。部署人员需要首先理解应用都包含哪些服务，然后按照逻辑顺序依次执行 kubectl apply。即缺少一种工具来定义应用与服务，以及服务与服务之间的依赖关系。

  3. 不能高效地共享和重用服务。比如两个应用都要用到 MySQL 服务，但配置的参数不一样，这两个应用只能分别拷贝一套标准的 MySQL 配置文件，修改后通过 kubectl apply 部署。也就是说不支持参数化配置和多环境部署。

  4. 不支持应用级别的版本管理。虽然可以通过 kubectl rollout undo 进行回滚，但这只能针对单个 Deployment，不支持整个应用的回滚。

  5. 不支持对部署的应用状态进行验证。比如是否能通过预定义的账号访问 MySQL。虽然 Kubernetes 有健康检查，但那是针对单个容器，我们需要应用（服务）级别的健康检查。

Helm 能够解决上面这些问题，Helm 帮助 Kubernetes 成为微服务架构应用理想的部署平台。

 

 三十八、Helm 架构

在实践之前，我们先来看看 Helm 的架构。

Helm 有两个重要的概念：chart 和 release。

chart 是创建一个应用的信息集合，包括各种 Kubernetes 对象的配置模板、参数定义、依赖关系、文档说明等。chart 是应用部署的自包含逻辑单元。可以将 chart 想象成 apt、yum 中的软件安装包。

release 是 chart 的运行实例，代表了一个正在运行的应用。当 chart 被安装到 Kubernetes 集群，就生成一个 release。chart 能够多次安装到同一个集群，每次安装都是一个 release。

Helm 是包管理工具，这里的包就是指的 chart。Helm 能够：

  1. 从零创建新 chart。

  2. 与存储 chart 的仓库交互，拉取、保存和更新 chart。

  3. 在 Kubernetes 集群中安装和卸载 release。

  4. 更新、回滚和测试 release。

Helm 包含两个组件：Helm 客户端 和 Tiller 服务器。

Helm 客户端是终端用户使用的命令行工具，用户可以：

  1. 在本地开发 chart。

  2. 管理 chart 仓库。

  3. 与 Tiller 服务器交互。

  4. 在远程 Kubernetes 集群上安装 chart。

  5. 查看 release 信息。

  6. 升级或卸载已有的 release。

Tiller 服务器运行在 Kubernetes 集群中，它会处理 Helm 客户端的请求，与 Kubernetes API Server 交互。Tiller 服务器负责：

  1. 监听来自 Helm 客户端的请求。

  2. 通过 chart 构建 release。

  3. 在 Kubernetes 中安装 chart，并跟踪 release 的状态。

  4. 通过 API Server 升级或卸载已有的 release。

简单的讲：Helm 客户端负责管理 chart；Tiller 服务器负责管理 release。

 

三十九、部署 Helm

 

本节我们将安装和部署 Helm 客户端和 Tiller 服务器。

Helm 客户端

通常，我们将 Helm 客户端安装在能够执行 kubectl 命令的节点上，只需要下面一条命令：

curl https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get | bash

执行 helm version 验证。

目前只能查看到客户端的版本，服务器还没有安装。

helm 有很多子命令和参数，为了提高使用命令行的效率，通常建议安装 helm 的 bash 命令补全脚本，方法如下：

helm completion bash > .helmrcecho "source .helmrc" >> .bashrc

重新登录后就可以通过 Tab 键补全 helm 子命令和参数了。

Tiller 服务器

Tiller 服务器安装非常简单，只需要执行 helm init：

Tiller 本身也是作为容器化应用运行在 Kubernetes Cluster 中的：

可以看到 Tiller 的 Service、Deployment 和 Pod。

现在， helm version 已经能够查看到服务器的版本信息了。

Helm 部署完毕，下一节开始使用 Helm。

 

 四十、使用Helm

Helm 安装成功后，可执行 helm search 查看当前可安装的 chart。

这个列表很长，这里只截取了一部分。大家不禁会问，这些 chart 都是从哪里来的？

前面说过，Helm 可以像 apt 和 yum 管理软件包一样管理 chart。apt 和 yum 的软件包存放在仓库中，同样的，Helm 也有仓库。

Helm 安装时已经默认配置好了两个仓库：stable 和 local。stable 是官方仓库，local 是用户存放自己开发的 chart 的本地仓库。

helm search 会显示 chart 位于哪个仓库，比如 local/cool-chart 和 stable/acs-engine-autoscaler。

用户可以通过 helm repo add 添加更多的仓库，比如企业的私有仓库，仓库的管理和维护方法请参考官网文档 https://docs.helm.sh

与 apt 和 yum 一样，helm 也支持关键字搜索：

包括 DESCRIPTION 在内的所有信息，只要跟关键字匹配，都会显示在结果列表中。

安装 chart 也很简单，执行如下命令可以安装 MySQL。

helm install stable/mysql

如果看到如下报错，通常是因为 Tiller 服务器的权限不足。

执行如下命名添加权限：

kubectl create serviceaccount --namespace kube-system tiller
kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller
kubectl patch deploy --namespace kube-system tiller-deploy -p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}'

然后再次执行

helm install stable/mysql

输出分为三部分：

① chart 本次部署的描述信息：

NAME 是 release 的名字，因为我们没用 -n 参数指定，Helm 随机生成了一个，这里是 fun-zorse。

NAMESPACE 是 release 部署的 namespace，默认是 default，也可以通过 --namespace 指定。

STATUS 为 DEPLOYED，表示已经将 chart 部署到集群。

② 当前 release 包含的资源：Service、Deployment、Secret 和 PersistentVolumeClaim，其名字都是 fun-zorse-mysql，命名的格式为 ReleasName-ChartName。

③ NOTES 部分显示的是 release 的使用方法。比如如何访问 Service，如何获取数据库密码，以及如何连接数据库等。

通过 kubectl get 可以查看组成 release 的各个对象：

因为我们还没有准备 PersistentVolume，当前 release 还不可用。

helm list 显示已经部署的 release，helm delete 可以删除 release。

Helm 的使用方法像极了 apt 和 yum，用 Helm 来管理 Kubernetes 应用非常方便。

 

 四十一、Helm目录结构

 

chart 是 Helm 的应用打包格式。chart 由一系列文件组成，这些文件描述了 Kubernetes 部署应用时所需要的资源，比如 Service、Deployment、PersistentVolumeClaim、Secret、ConfigMap 等。

单个的 chart 可以非常简单，只用于部署一个服务，比如 Memcached；chart 也可以很复杂，部署整个应用，比如包含 HTTP Servers、 Database、消息中间件、cache 等。

chart 将这些文件放置在预定义的目录结构中，通常整个 chart 被打成 tar 包，而且标注上版本信息，便于 Helm 部署。

下面我们将详细讨论 chart 的目录结构以及包含的各类文件。

chart 目录结构

以前面 MySQL chart 为例。一旦安装了某个 chart，我们就可以在 ~/.helm/cache/archive 中找到 chart 的 tar 包。

解压后，MySQL chart 目录结构如下：

目录名就是 chart 的名字（不带版本信息），这里是 mysql，包含如下内容：

Chart.yaml 
YAML 文件，描述 chart 的概要信息。

name 和 version 是必填项，其他都是可选。

README.md 
Markdown 格式的 README 文件，相当于 chart 的使用文档，此文件为可选。

LICENSE 
文本文件，描述 chart 的许可信息，此文件为可选。

requirements.yaml 
chart 可能依赖其他的 chart，这些依赖关系可通过 requirements.yaml 指定，比如：

在安装过程中，依赖的 chart 也会被一起安装。

values.yaml 
chart 支持在安装的时根据参数进行定制化配置，而 values.yaml 则提供了这些配置参数的默认值。

templates 目录 
各类 Kubernetes 资源的配置模板都放置在这里。Helm 会将 values.yaml 中的参数值注入到模板中生成标准的 YAML 配置文件。

模板是 chart 最重要的部分，也是 Helm 最强大的地方。模板增加了应用部署的灵活性，能够适用不同的环境，我们后面会详细讨论。

templates/NOTES.txt 
chart 的简易使用文档，chart 安装成功后会显示此文档内容。

与模板一样，可以在 NOTE.txt 中插入配置参数，Helm 会动态注入参数值。

 

四十二、chart 模板

 

Helm 通过模板创建 Kubernetes 能够理解的 YAML 格式的资源配置文件，我们将通过例子来学习如何使用模板。

以 templates/secrets.yaml 为例：

从结构看，文件的内容非常像 Secret 配置，只是大部分属性值变成了{{ xxx }}。这些 {{ xxx }} 实际上是模板的语法。Helm 采用了 Go 语言的模板来编写 chart。Go 模板非常强大，支持变量、对象、函数、流控制等功能。下面我们通过解析 templates/secrets.yaml 快速学习模板。

① {{ template "mysql.fullname" . }} 定义 Secret 的 name。
关键字 template 的作用是引用一个子模板 mysql.fullname。这个子模板是在 templates/_helpers.tpl 文件中定义的。

这个定义还是很复杂的，因为它用到了模板语言中的对象、函数、流控制等概念。现在看不懂没关系，这里我们学习的重点是：如果存在一些信息多个模板都会用到，则可在 templates/_helpers.tpl 中将其定义为子模板，然后通过 templates 函数引用。

这里 mysql.fullname 是由 release 与 chart 二者名字拼接组成。

根据 chart 的最佳实践，所有资源的名称都应该保持一致，对于我们这个 chart，无论 Secret 还是 Deployment、PersistentVolumeClaim、Service，它们的名字都是子模板 mysql.fullname 的值。

② Chart 和 Release 是 Helm 预定义的对象，每个对象都有自己的属性，可以在模板中使用。如果使用下面命令安装 chart：

helm install stable/mysql -n my

那么：
{{ .Chart.Name }} 的值为 mysql。
{{ .Chart.Version }} 的值为 0.3.0。
{{ .Release.Name }} 的值为 my。
{{ .Release.Service }} 始终取值为 Tiller。
{{ template "mysql.fullname" . }} 计算结果为 my-mysql。

③ 这里指定 mysql-root-password 的值，不过使用了 if-else 的流控制，其逻辑为：
如果 .Values.mysqlRootPassword 有值，则对其进行 base64 编码；否则随机生成一个 10 位的字符串并编码。

Values 也是预定义的对象，代表的是 values.yaml 文件。而 .Values.mysqlRootPassword 则是 values.yaml 中定义的 mysqlRootPassword 参数：

因为 mysqlRootPassword 被注释掉了，没有赋值，所以逻辑判断会走 else，即随机生成密码。

randAlphaNum、b64enc、quote 都是 Go 模板语言支持的函数，函数之间可以通过管道 | 连接。{{ randAlphaNum 10 | b64enc | quote }} 的作用是首先随机产生一个长度为 10 的字符串，然后将其 base64 编码，最后两边加上双引号。

templates/secrets.yaml 这个例子展示了 chart 模板主要的功能，我们最大的收获应该是：模板将 chart 参数化了，通过 values.yaml 可以灵活定制应用。

无论多复杂的应用，用户都可以用 Go 模板语言编写出 chart。无非是使用到更多的函数、对象和流控制。对于初学者，我的建议是尽量参考官方的 chart。根据二八定律，这些 chart 已经覆盖了绝大部分情况，而且采用了最佳实践。如何遇到不懂的函数、对象和其他语法，可参考官网文档 https://docs.helm.sh

有了上面 chart 结构和模板的知识后，下节我们将重新实践一次 MySQL chart，相信会有更多收获。

 

 四十三、再次实践 MySQL chart 

 

学习了 chart 结构和模板的知识后，现在重新实践一次 MySQL chart，相信会有更多收获。

chart 安装前的准备

作为准备工作，安装之前需要先清楚 chart 的使用方法。这些信息通常记录在 values.yaml 和 README.md 中。除了下载源文件查看，执行 helm inspect values 可能是更方便的方法。

输出的实际上是 values.yaml 的内容。阅读注释就可以知道 MySQL chart 支持哪些参数，安装之前需要做哪些准备。其中有一部分是关于存储的：

chart 定义了一个 PersistentVolumeClaim，申请 8G 的 PersistentVolume。由于我们的实验环境不支持动态供给，所以得预先创建好相应的 PV，其配置文件 mysql-pv.yml 内容为：

创建 PV mysql-pv：

接下来就可以安装 chart 了。

定制化安装 chart

除了接受 values.yaml 的默认值，我们还可以定制化 chart，比如设置 mysqlRootPassword。

Helm 有两种方式传递配置参数：

  1. 指定自己的 values 文件。
    通常的做法是首先通过 helm inspect values mysql > myvalues.yaml生成 values 文件，然后设置 mysqlRootPassword，之后执行 helm install --values=myvalues.yaml mysql。

  2. 通过 --set 直接传入参数值，比如：

mysqlRootPassword 设置为 abc123。另外，-n 设置 release 为 my，各类资源的名称即为my-mysql。

通过 helm list 和 helm status 可以查看 chart 的最新状态。

PVC 已经 Bound，Deployment 也 AVAILABLE。

升级和回滚 release

release 发布后可以执行 helm upgrade 对其升级，通过 --values 或 --set应用新的配置。比如将当前的 MySQL 版本升级到 5.7.15：

等待一些时间，升级成功。

helm history 可以查看 release 所有的版本。通过 helm rollback 可以回滚到任何版本。

回滚成功，MySQL 恢复到 5.7.14。

到这里，相信大家已经会使用 chart 了。下一节我们学习如何开发自己的 chart。

 

四十四、开发自己的chart

 

Kubernetes 给我们提供了大量官方 chart，不过要部署微服务应用，还是需要开发自己的 chart，下面就来实践这个主题。

创建 chart

执行 helm create mychart 的命令创建 chart mychart：

Helm 会帮我们创建目录 mychart，并生成了各类 chart 文件。这样我们就可以在此基础上开发自己的 chart 了。

新建的 chart 默认包含一个 nginx 应用示例，values.yaml 内容如下：

开发时建议大家参考官方 chart 中的模板、values.yaml、Chart.yaml，里面包含了大量最佳实践和最常用的函数、流控制，这里就不一一展开了。

调试 chart

只要是程序就会有 bug，chart 也不例外。Helm 提供了 debug 的工具：helm lint 和 helm install --dry-run --debug。

helm lint 会检测 chart 的语法，报告错误以及给出建议。

比如我们故意在 values.yaml 的第 8 行漏掉了一个 :，

helm lint mychart 会指出这个语法错误。

mychart 目录被作为参数传递给 helm lint。错误修复后则能通过检测。

helm install --dry-run --debug 会模拟安装 chart，并输出每个模板生成的 YAML 内容。

我们可以检视这些输出，判断是否与预期相符。

同样，mychart 目录作为参数传递给 helm install --dry-run --debug。

 

四十五、管理和安装chart

安装 chart

当我们觉得准备就绪，就可以安装 chart，Helm 支持四种安装方法：

  1. 安装仓库中的 chart，例如：helm install stable/nginx

  2. 通过 tar 包安装，例如：helm install ./nginx-1.2.3.tgz

  3. 通过 chart 本地目录安装，例如：helm install ./nginx

  4. 通过 URL 安装，例如：helm install https://example.com/charts/nginx-1.2.3.tgz

这里我们使用本地目录安装：

当 chart 部署到 Kubernetes 集群，便可以对其进行更为全面的测试。

将 chart 添加到仓库

chart 通过测试后可以将其添加到仓库，团队其他成员就能够使用。任何 HTTP Server 都可以用作 chart 仓库，下面演示在 k8s-node1192.168.56.106 上搭建仓库。

  1. 在 k8s-node1 上启动一个 httpd 容器。

  2. 通过 helm package 将 mychart 打包。

  3. 执行 helm repo index 生成仓库的 index 文件。
     
    Helm 会扫描 myrepo 目录中的所有 tgz 包并生成 index.yaml。--url指定的是新仓库的访问路径。新生成的 index.yaml 记录了当前仓库中所有 chart 的信息：
     
    当前只有 mychart 这一个 chart。

  4. 将 mychart-0.1.0.tgz 和 index.yaml 上传到 k8s-node1 的 /var/www/charts 目录。

  5. 通过 helm repo add 将新仓库添加到 Helm。
     
    仓库命名为 newrepo，Helm 会从仓库下载 index.yaml。

  6. 现在已经可以 repo search 到 mychart 了。
     
    除了 newrepo/mychart，这里还有一个 local/mychart。这是因为在执行第 2 步打包操作的同时，mychart 也被同步到了 local 的仓库。

  7. 已经可以直接从新仓库安装 mychart 了。

  8. 如果以后仓库添加了新的 chart，需要用 helm repo update 更新本地的 index。
     
    这个操作相当于 Ubutun 的 apt-get update。

小结

本章我们学习了 Kubernetes 包管理器 Helm。

Helm 让我们能够像 apt 管理 deb 包那样安装、部署、升级和删除容器化应用。

Helm 由客户端和 Tiller 服务器组成。客户端负责管理 chart，服务器负责管理 release。

chart 是 Helm 的应用打包格式，它由一组文件和目录构成。其中最重要的是模板，模板中定义了 Kubernetes 各类资源的配置信息，Helm 在部署时通过 values.yaml 实例化模板。

Helm 允许用户开发自己的 chart，并为用户提供了调试工具。用户可以搭建自己的 chart 仓库，在团队中共享 chart。

Helm 帮助用户在 Kubernetes 上高效地运行和管理微服务架构应用，Helm 非常重要。

 

 四十六、 Kubernetes 网络模型

 

本节我们讨论 Kubernetes 网络这个重要主题。

Kubernetes 作为编排引擎管理着分布在不同节点上的容器和 Pod。Pod、Service、外部组件之间需要一种可靠的方式找到彼此并进行通信，Kubernetes 网络则负责提供这个保障。本章包括如下内容：

  1. Kubernetes 网络模型

  2. 各种网络方案

  3. Network Policy

Kubernetes 网络模型

Kubernetes 采用的是基于扁平地址空间的网络模型，集群中的每个 Pod 都有自己的 IP 地址，Pod 之间不需要配置 NAT 就能直接通信。另外，同一个 Pod 中的容器共享 Pod 的 IP，能够通过 localhost 通信。

这种网络模型对应用开发者和管理员相当友好，应用可以非常方便地从传统网络迁移到 Kubernetes。每个 Pod 可被看作是一个个独立的系统，而 Pod 中的容器则可被看做同一系统中的不同进程。

下面讨论在这个网络模型下集群中的各种实体如何通信。知识点前面都已经涉及，这里可当做复习和总结。

Pod 内容器之间的通信

当 Pod 被调度到某个节点，Pod 中的所有容器都在这个节点上运行，这些容器共享相同的本地文件系统、IPC 和网络命名空间。

不同 Pod 之间不存在端口冲突的问题，因为每个 Pod 都有自己的 IP 地址。当某个容器使用 localhost 时，意味着使用的是容器所属 Pod 的地址空间。

比如 Pod A 有两个容器 container-A1 和 container-A2，container-A1 在端口 1234 上监听，当 container-A2 连接到 localhost:1234，实际上就是在访问 container-A1。这不会与同一个节点上的 Pod B 冲突，即使 Pod B 中的容器 container-B1 也在监听 1234 端口。

Pod 之间的通信

Pod 的 IP 是集群可见的，即集群中的任何其他 Pod 和节点都可以通过 IP 直接与 Pod 通信，这种通信不需要借助任何的网络地址转换、隧道或代理技术。Pod 内部和外部使用的是同一个 IP，这也意味着标准的命名服务和发现机制，比如 DNS 可以直接使用。

Pod 与 Service 的通信

Pod 间可以直接通过 IP 地址通信，但前提是 Pod 得知道对方的 IP。在 Kubernetes 集群中， Pod 可能会频繁的销毁和创建，也就是说 Pod 的 IP 不是固定的。为了解决这个问题，Service 提供了访问 Pod 的抽象层。无论后端的 Pod 如何变化，Service 都作为稳定的前端对外提供服务。同时，Service 还提供了高可用和负载均衡功能，Service 负责将请求转发给正确的 Pod。

外部访问

无论是 Pod 的 IP 还是 Service 的 Cluster IP，它们只能在 Kubernetes 集群中可见，对集群之外的世界，这些 IP 都是私有的。

Kubernetes 提供了两种方式让外界能够与 Pod 通信：

  1. NodePort
    Service 通过 Cluster 节点的静态端口对外提供服务。外部可以通过 <NodeIP>:<NodePort> 访问 Service。

  2. LoadBalancer
    Service 利用 cloud provider 提供的 load balancer 对外提供服务，cloud provider 负责将 load balancer 的流量导向 Service。目前支持的 cloud provider 有 GCP、AWS、Azur 等。

以上就是 Kubernetes 网络模型的相关讨论。

 

 四十七、k8s各种网络方案

 

网络模型有了，如何实现呢？

为了保证网络方案的标准化、扩展性和灵活性，Kubernetes 采用了 Container Networking Interface（CNI）规范。

CNI 是由 CoreOS 提出的容器网络规范，它使用了插件（Plugin）模型创建容器的网络栈。

CNI 的优点是支持多种容器 runtime，不仅仅是 Docker。CNI 的插件模型支持不同组织和公司开发的第三方插件，这对运维人员来说很有吸引力，可以灵活选择适合的网络方案。

目前已有多种支持 Kubernetes 的网络方案，比如 Flannel、Calico、Canal、Weave Net 等。因为它们都实现了 CNI 规范，用户无论选择哪种方案，得到的网络模型都一样，即每个 Pod 都有独立的 IP，可以直接通信。区别在于不同方案的底层实现不同，有的采用基于 VxLAN 的 Overlay 实现，有的则是 Underlay，性能上有区别。再有就是是否支持 Network Policy。

 

 四十八、Network Policy

Network Policy 是 Kubernetes 的一种资源。Network Policy 通过 Label 选择 Pod，并指定其他 Pod 或外界如何与这些 Pod 通信。

默认情况下，所有 Pod 是非隔离的，即任何来源的网络流量都能够访问 Pod，没有任何限制。当为 Pod 定义了 Network Policy，只有 Policy 允许的流量才能访问 Pod。

不过，不是所有的 Kubernetes 网络方案都支持 Network Policy。比如 Flannel 就不支持，Calico 是支持的。我们接下来将用 Canal 来演示 Network Policy。Canal 这个开源项目很有意思，它用 Flannel 实现 Kubernetes 集群网络，同时又用 Calico 实现 Network Policy。

部署 Canal

部署 Canal 与部署其他 Kubernetes 网络方案非常类似，都是在执行了 kubeadm init 初始化 Kubernetes 集群之后通过 kubectl apply 安装相应的网络方案。也就是说，没有太好的办法直接切换使用不同的网络方案，基本上只能重新创建集群。

要销毁当前集群，最简单的方法是在每个节点上执行 kubeadm reset。然后就可以按照我们在前面 “部署 Kubernetes Cluster” 一章的 “初始化 Master” 小节中的方法初始化集群。

kubeadm init --apiserver-advertise-address 192.168.56.105 --pod-network-cidr=10.244.0.0/16

然后按照文档 https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/ 安装 Canal。文档列出了各种网络方案的安装方法：

执行如下命令部署 Canal

kubectl apply -f https://raw.githubusercontent.com/projectcalico/canal/master/k8s-install/1.7/rbac.yaml
kubectl apply -f https://raw.githubusercontent.com/projectcalico/canal/master/k8s-install/1.7/canal.yaml

部署成功后，可以查看到 Canal 相关组件：

Canal 作为 DaemonSet 部署到每个节点，地属于 kube-system 这个 namespace。

Canal 准备就绪，下节我们将实践 Network Policy。

 

 四十九、实践Network Policy

为了演示 Network Policy，我们先部署一个 httpd 应用，其配置文件 httpd.yaml 为：

httpd 有三个副本，通过 NodePort 类型的 Service 对外提供服务。部署应用：

当前没有定义任何 Network Policy，验证应用可以被访问：

  1. 启动一个 busybox Pod，可以访问 Service，也可以 Ping 到副本 Pod。

  2. 集群节点可以访问 Service， 也可以 Ping 到副本 Pod。

  3. 集群外（192.168.56.1）可以访问 Service。

现在创建如下 Network Policy：

① 定义将此 Network Policy 中的访问规则应用于 label 为 run: httpd 的 Pod，即 httpd 应用的三个副本 Pod。

② ingress 中定义只有 label 为 access: "true" 的 Pod 才能访问应用。

③ 只能访问 80 端口。

通过 kubectl apply 创建 Network Policy。

验证 Network Policy 的有效性：

  1. busybox Pod 已经不能访问 Service。

    如果 Pod 添加了 label access: "true" 就能访问到应用，但 Ping 已经被禁止。

  2. 集群节点已经不能访问 Service， 也 Ping 不到副本 Pod。

  3. 集群外（192.168.56.1）已经不能访问 Service。

如果希望让集群节点和集群外（192.168.56.1）也能够访问到应用，可以对 Network Policy 做如下修改：

应用新的 Network Policy：

现在，集群节点和集群外（192.168.56.1）已经能够访问了：

除了通过 ingress 限制进入的流量，也可以用 egress 限制外出的流量。大家可以参考官网相关文档和示例，这里就不赘述了。

小结

Kubernetes 采用的是扁平化的网络模型，每个 Pod 都有自己的 IP，并且可以直接通信。

CNI 规范使得 Kubernetes 可以灵活选择多种 Plugin 实现集群网络。

Network Policy 则赋予了 Kubernetes 强大的网络访问控制机制。

 

五十、Kubernetes Dashboard

前面章节 Kubernetes 所有的操作我们都是通过命令行工具 kubectl 完成的。为了提供更丰富的用户体验，Kubernetes 还开发了一个基于 Web 的 Dashboard，用户可以用 Kubernetes Dashboard 部署容器化的应用、监控应用的状态、执行故障排查任务以及管理 Kubernetes 各种资源。

在 Kubernetes Dashboard 中可以查看集群中应用的运行状态，也能够创建和修改各种 Kubernetes 资源，比如 Deployment、Job、DaemonSet 等。用户可以 Scale Up/Down Deployment、执行 Rolling Update、重启某个 Pod 或者通过向导部署新的应用。Dashboard 能显示集群中各种资源的状态以及日志信息。

可以说，Kubernetes Dashboard 提供了 kubectl 的绝大部分功能，大家可以根据情况进行选择。

安装

Kubernetes 默认没有部署 Dashboard，可通过如下命令安装：

kubectl create -f https://raw.githubusercontent.com/kubernetes/dashboard/master/src/deploy/recommended/kubernetes-dashboard.yaml

Dashboard 会在 kube-system namespace 中创建自己的 Deployment 和 Service。

因为 Service 是 ClusterIP 类型，为了方便使用，我们可通过 kubectl --namespace=kube-system edit service kubernetes-dashboard 修改成 NodePort 类型。

保存修改，此时已经为 Service 分配了端口 31614。

通过浏览器访问 Dashboard https://192.168.56.105:31614/，登录界面如下：

配置登录权限

Dashboard 支持 Kubeconfig 和 Token 两种认证方式，为了简化配置，我们通过配置文件 dashboard-admin.yaml 为 Dashboard 默认用户赋予 admin 权限。

执行 kubectl apply 使之生效。

现在直接点击登录页面的 SKIP 就可以进入 Dashboard 了。

下一节我们来使用 Kubernetes Dashboard。

 

五十一、使用Dashboard

Dashboard 界面结构

Dashboard 的界面很简洁，分为三个大的区域。

  1. 顶部操作区

    在这里用户可以搜索集群中的资源、创建资源或退出。

  2. 左边导航菜单
    通过导航菜单可以查看和管理集群中的各种资源。菜单项按照资源的层级分为两类：
    Cluster 级别的资源 
     
    Namespace 级别的资源 
     
    默认显示的是 default Namespace，可以进行切换：

  3. 中间主体区
    在导航菜单中点击了某类资源，中间主体区就会显示该资源所有实例，比如点击 Pods。

典型使用场景

接下来我们介绍几个 Dashboard 的典型使用场景。

部署 Deployment

点击顶部操作区的 + CREATE 按钮。

用户可以直接输入要部署应用的名字、镜像、副本数等信息；也可以上传 YAML 配置文件。如果是上传配置文件，则可以创建任意类型的资源，不仅仅是 Deployment。

在线操作

对于每种资源，都可以点击  按钮执行各种操作。

比如点击 View/edit YAML 可直接修改资源的配置，保存后立即生效，其效果与 kubectl edit 一样。

查看资源详细信息

点击某个资源实例的名字，可以查看到详细信息，其效果与 kubectl describe 一样。

查看 Pod 日志

在 Pod 及其父资源（DaemonSet、ReplicaSet 等）页面点击  按钮，可以查看 Pod 的日志，其效果与 kubectl logs 一样。

Kubernetes Dashboard 界面设计友好，自解释性强，可以看作 GUI 版的 kubectl，更多功能留给大家自己探索。

小结

本章介绍了Kubernetes Dashboard 的安装和使用方法。Dashboard能完成日常管理的大部分工作，可以作为命令行工具 kubectl 的有益补充。

 

五十二、用Weave Scope监控集群

 

创建 Kubernetes 集群并部署容器化应用只是第一步。一旦集群运行起来，我们需要确保一起正常，所有必要组件就位并各司其职，有足够的资源满足应用的需求。Kubernetes 是一个复杂系统，运维团队需要有一套工具帮助他们获知集群的实时状态，并为故障排查提供及时和准确的数据支持。

本章重点讨论 Kubernetes 常用的监控方案，下一章会讨论日志管理。

Weave Scope

Weave Scope 是 Docker 和 Kubernetes 可视化监控工具。Scope 提供了至上而下的集群基础设施和应用的完整视图，用户可以轻松对分布式的容器化应用进行实时监控和问题诊断。

安装 Scope

安装 Scope 的方法很简单，执行如下命令：

kubectl apply --namespace kube-system -f "https://cloud.weave.works/k8s/scope.yaml?k8s-version=$(kubectl version | base64 | tr -d '\n')"

部署成功后，有如下相关组件：

  1. DaemonSet weave-scope-agent，集群每个节点上都会运行的 scope agent 程序，负责收集数据。

  2. Deployment weave-scope-app，scope 应用，从 agent 获取数据，通过 Web UI 展示并与用户交互。

  3. Service weave-scope-app，默认是 ClusterIP 类型，为了方便已通过 kubectl edit 修改为 NodePort。

使用 Scope

浏览器访问 http://192.168.56.106:30693/，Scope 默认显示当前所有的 Controller（Deployment、DaemonSet 等）。

拓扑结构

Scope 会自动构建应用和集群的逻辑拓扑。比如点击顶部 PODS，会显示所有 Pod 以及 Pod 之间的依赖关系。

点击 HOSTS，会显示各个节点之间的关系。

实时资源监控

可以在 Scope 中查看资源的 CPU 和内存使用情况。

支持的资源有 Host、Pod 和 Container。

在线操作

Scope 还提供了便捷的在线操作功能，比如选中某个 Host，点击 >_ 按钮可以直接在浏览器中打开节点的命令行终端：

点击 Deployment 的 + 可以执行 Scale Up 操作：

可以查看 Pod 的日志：

可以 attach、restart、stop 容器，以及直接在 Scope 中排查问题：

强大的搜索功能

Scope 支持关键字搜索和定位资源。

还可以进行条件搜索，比如查找和定位 MEMORY > 100M 的 Pod。

Weave Scope 界面极其友好，操作简洁流畅，更多功能留给大家去探索。

 

五十三、用Heapster监控集群

Heapster 是 Kubernetes 原生的集群监控方案。Heapster 以 Pod 的形式运行，它会自动发现集群节点、从节点上的 Kubelet 获取监控数据。Kubelet 则是从节点上的 cAdvisor 收集数据。

Heapster 将数据按照 Pod 进行分组，将它们存储到预先配置的 backend 并进行可视化展示。Heapster 当前支持的 backend 有 InfluxDB（通过 Grafana 展示），Google Cloud Monitoring 等。Heapster 的整体架构如下图所示：

下面我们将实践由 Heapster、InfluxDB 和 Grafana 组成的监控方案。Kubelet 和 cAdvisor 是 Kubernetes 的自带组件，无需额外部署。

部署

Heapster 本身是一个 Kubernetes 应用，部署方法很简单，运行如下命令：

git clone https://github.com/kubernetes/heapster.git
kubectl apply -f heapster/deploy/kube-config/influxdb/
kubectl apply -f heapster/deploy/kube-config/rbac/heapster-rbac.yaml

Heapster 相关资源如下：

为便与访问，已通过 kubectl edit 将 Service monitoring-grafana 的类型修改为 NodePort。

使用

浏览器打开 Grafana 的 Web UI：http://192.168.56.105:32314/

Heapster 已经预先配置好了 Grafana 的 DataSource 和 Dashboard。

点击左上角 Home 菜单，可以看到预定义的两个 Dashboard Cluster 和 Pods。

点击 Cluster，可以查看集群中节点的 CPU、内存、网络和磁盘的使用情况。

在左上角可以切换查看不同节点的数据。

切换到 Pods Dashboard，可以查看 Pod 的监控数据，包括单个 Pod 的 CPU、内存、网络和磁盘使用情况。

在左上角可以切换到不同 Namespace 的 Pod。

Heapster 预定义的 Dashboard 很直观也很简单。如有必要，可以在 Grafana 中定义自己的 Dashboard 满足特定的业务需求。

 

五十四、Prometheus Operator

 

前面我们介绍了 Kubernetes 的两种监控方案 Weave Scope 和 Heapster，它们主要的监控对象是 Node 和 Pod。这些数据对 Kubernetes 运维人员是必须的，但还不够。我们通常还希望监控集群本身的运行状态，比如 Kubernetes 的 API Server、Scheduler、Controller Manager 等管理组件是否正常工作，负荷是否过大等？

本节我们将学习监控方案 Prometheus Operator，它能回答上面这些问题。

Prometheus Operator 是 CoreOS 开发的基于 Prometheus 的 Kubernetes 监控方案，也可能是目前功能最全面的开源方案。我们先通过截图了解一下它能干什么。

Prometheus Operator 通过 Grafana 展示监控数据，预定义了一系列的 Dashboard：

可以监控 Kubernetes 集群的整体健康状态：

整个集群的资源使用情况：

Kubernetes 各个管理组件的状态：

节点的资源使用情况：

Deployment 的运行状态：

Pod 的运行状态：

这些 Dashboard 展示了从集群到 Pod 的运行状况，能够帮助用户更好地运维 Kubernetes。而且 Prometheus Operator 迭代非常快，相信会继续开发出更多更好的功能，所以值得我们花些时间学习和实践。

通过上面这些内容相信对 Prometheus Operator 有了些感性的认识，下一节我们将讨论 Prometheus Operator 的架构。

 

 五十五、 Prometheus Operator 的架构

本节讨论 Prometheus Operator 的架构。
因为 Prometheus Operator 是基于 Prometheus 的，我们需要先了解一下 Prometheus。

Prometheus 架构

Prometheus 是一个非常优秀的监控工具。准确的说，应该是监控方案。Prometheus 提供了数据搜集、存储、处理、可视化和告警一套完整的解决方案。Prometheus 的架构如下图所示：

官网上的原始架构图比上面这张要复杂一些，为了避免注意力分散，这里只保留了最重要的组件。

Prometheus Server

Prometheus Server 负责从 Exporter 拉取和存储监控数据，并提供一套灵活的查询语言（PromQL）供用户使用。

Exporter

Exporter 负责收集目标对象（host, container...）的性能数据，并通过 HTTP 接口供 Prometheus Server 获取。

可视化组件

监控数据的可视化展现对于监控方案至关重要。以前 Prometheus 自己开发了一套工具，不过后来废弃了，因为开源社区出现了更为优秀的产品 Grafana。Grafana 能够与 Prometheus 无缝集成，提供完美的数据展示能力。

Alertmanager

用户可以定义基于监控数据的告警规则，规则会触发告警。一旦 Alermanager 收到告警，会通过预定义的方式发出告警通知。支持的方式包括 Email、PagerDuty、Webhook 等.

Prometheus Operator 架构

Prometheus Operator 的目标是尽可能简化在 Kubernetes 中部署和维护 Prometheus 的工作。其架构如下图所示：

图上的每一个对象都是 Kubernetes 中运行的资源。

Operator

Operator 即 Prometheus Operator，在 Kubernetes 中以 Deployment 运行。其职责是部署和管理 Prometheus Server，根据 ServiceMonitor 动态更新 Prometheus Server 的监控对象。

Prometheus Server

Prometheus Server 会作为 Kubernetes 应用部署到集群中。为了更好地在 Kubernetes 中管理 Prometheus，CoreOS 的开发人员专门定义了一个命名为 Prometheus 类型的 Kubernetes 定制化资源。我们可以把 Prometheus看作是一种特殊的 Deployment，它的用途就是专门部署 Prometheus Server。

Service

这里的 Service 就是 Cluster 中的 Service 资源，也是 Prometheus 要监控的对象，在 Prometheus 中叫做 Target。每个监控对象都有一个对应的 Service。比如要监控 Kubernetes Scheduler，就得有一个与 Scheduler 对应的 Service。当然，Kubernetes 集群默认是没有这个 Service 的，Prometheus Operator 会负责创建。

ServiceMonitor

Operator 能够动态更新 Prometheus 的 Target 列表，ServiceMonitor 就是 Target 的抽象。比如想监控 Kubernetes Scheduler，用户可以创建一个与 Scheduler Service 相映射的 ServiceMonitor 对象。Operator 则会发现这个新的 ServiceMonitor，并将 Scheduler 的 Target 添加到 Prometheus 的监控列表中。

ServiceMonitor 也是 Prometheus Operator 专门开发的一种 Kubernetes 定制化资源类型。

Alertmanager

除了 Prometheus 和 ServiceMonitor，Alertmanager 是 Operator 开发的第三种 Kubernetes 定制化资源。我们可以把 Alertmanager 看作是一种特殊的 Deployment，它的用途就是专门部署 Alertmanager 组件。

 

五十六、部署 Prometheus Operator

本节在实践时使用的是 Prometheus Operator 版本 v0.14.0。由于项目开发迭代速度很快，部署方法可能会更新，必要时请参考官方文档。

下载最新源码

git clone https://github.com/coreos/prometheus-operator.git
cd prometheus-operator

为方便管理，创建一个单独的 Namespace monitoring，Prometheus Operator 相关的组件都会部署到这个 Namespace。

kubectl create namespace monitoring

安装 Prometheus Operator Deployment

helm install --name prometheus-operator --set rbacEnable=true --namespace=monitoring helm/prometheus-operator

Prometheus Operator 所有的组件都打包成 Helm Chart，安装部署非常方便。如果对 Helm 不熟悉，可以参考前面相关章节。

安装 Prometheus、Alertmanager 和 Grafana

helm install --name prometheus --set serviceMonitorsSelector.app=prometheus --set ruleSelector.app=prometheus --namespace=monitoring helm/prometheus
helm install --name alertmanager --namespace=monitoring helm/alertmanager
helm install --name grafana --namespace=monitoring helm/grafana

可以通过 kubectl get prometheus 查看 Prometheus 类型的资源。

为了方便访问 Prometheus Server，这里已经将 Service 类型通过 kubectl edit 改为 NodePort。

同样可以查看 Alertmanager 和 Grafana 的相关资源。

Service 类型也都已经改为 NodePort。

安装 kube-prometheus

kube-prometheus 是一个 Helm Chart，打包了监控 Kubernetes 需要的所有 Exporter 和 ServiceMonitor。

helm install --name kube-prometheus --namespace=monitoring helm/kube-prometheus

每个 Exporter 会对应一个 Service，为 Pormetheus 提供 Kubernetes 集群的各类监控数据。

每个 Service 对应一个 ServiceMonitor，组成 Pormetheus 的 Target 列表。

如下是与 Prometheus Operator 相关的所有 Pod。

我们注意到有些 Exporter 没有运行 Pod，这是因为像 API Server、Scheduler、Kubelet 等 Kubernetes 内部组件原生就支持 Prometheus，只需要定义 Service 就能直接从预定义端口获取监控数据。

浏览器打开 Pormetheus 的 Web UI http://192.168.56.105:30413/targets

所有 Target 的状态都是 UP。

安装 Alert 规则

Prometheus Operator 提供了默认的 Alertmanager 告警规则，通过如下命令安装。

sed -ie 's/role: prometheus-rulefiles/app: prometheus/g' contrib/kube-prometheus/manifests/prometheus/prometheus-k8s-rules.yaml
sed -ie 's/prometheus: k8s/prometheus: prometheus/g' contrib/kube-prometheus/manifests/prometheus/prometheus-k8s-rules.yaml
sed -ie 's/job=\"kube-controller-manager/job=\"kube-prometheus-exporter-kube-controller-manager/g' contrib/kube-prometheus/manifests/prometheus/prometheus-k8s-rules.yaml
sed -ie 's/job=\"apiserver/job=\"kube-prometheus-exporter-kube-api/g' contrib/kube-prometheus/manifests/prometheus/prometheus-k8s-rules.yaml
sed -ie 's/job=\"kube-scheduler/job=\"kube-prometheus-exporter-kube-scheduler/g' contrib/kube-prometheus/manifests/prometheus/prometheus-k8s-rules.yaml
sed -ie 's/job=\"node-exporter/job=\"kube-prometheus-exporter-node/g' contrib/kube-prometheus/manifests/prometheus/prometheus-k8s-rules.yaml
kubectl apply -n monitoring -f contrib/kube-prometheus/manifests/prometheus/prometheus-k8s-rules.yaml

安装 Grafana Dashboard

Prometheus Operator 定义了显示监控数据的默认 Dashboard，通过如下命令安装。

sed -ie 's/grafana-dashboards-0/grafana-grafana/g' contrib/kube-prometheus/manifests/grafana/grafana-dashboards.yaml
sed -ie 's/prometheus-k8s.monitoring/prometheus-prometheus.monitoring/g' contrib/kube-prometheus/manifests/grafana/grafana-dashboards.yaml
kubectl apply -n monitoring -f contrib/kube-prometheus/manifests/grafana/grafana-dashboards.yaml

打开 Grafana 的 Web UI http://192.168.56.105:32342/

Grafana 的 DataSource 和 Dashboard 已自动配置。点击 Home 就可以使用我们在最开始讨论过的那些 Dashboard 了。

小结

本章我们实践了三种 Kubernetes 监控方案。

Weave Scope 可以展示集群和应用的完整视图。其出色的交互性让用户能够轻松对容器化应用进行实时监控和问题诊断。

Heapster 是 Kubernetes 原生的集群监控方案。预定义的 Dashboard 能够从 Cluster 和 Pods 两个层次监控 Kubernetes。

Prometheus Operator 可能是目前功能最全面的 Kubernetes 开源监控方案。除了能够监控 Node 和 Pod，还支持集群的各种管理组件，比如 API Server、Scheduler、Controller Manager 等。

Kubernetes 监控是一个快速发展的领域。随着 Kubernetes 的普及，一定会涌现出更多的优秀方案。

 

 五十七、Kubernetes 集群日志管理

Kubernetes 开发了一个 Elasticsearch 附加组件来实现集群的日志管理。这是一个 Elasticsearch、Fluentd 和 Kibana 的组合。Elasticsearch 是一个搜索引擎，负责存储日志并提供查询接口；Fluentd 负责从 Kubernetes 搜集日志并发送给 Elasticsearch；Kibana 提供了一个 Web GUI，用户可以浏览和搜索存储在 Elasticsearch 中的日志。

部署

Elasticsearch 附加组件本身会作为 Kubernetes 的应用在集群里运行，其 YAML 配置文件可从 https://github.com/kubernetes/kubernetes/tree/master/cluster/addons/fluentd-elasticsearch 获取。

可将这些 YAML 文件下载到本地目录，比如 addons ，通过 kubectl apply -f addons/ 部署。

这里有一点需要注意：后面我们会通过 NodePort 访问 Kibana，需要注释掉 kibana-deployment.yaml 中的环境变量 SERVER_BASEPATH，否则无法访问。

所有的资源都部署在 kube-system Namespace 里。

DaemonSet fluentd-es 从每个节点收集日志，然后发送给 Elasticsearch。

Elasticsearch 以 StatefulSet 资源运行，并通过 Service elasticsearch-logging 对外提供接口。这里已经将 Service 的类型通过 kubectl edit 修改为 NodePort。

可通过 http://192.168.56.106:32607/ 验证 Elasticsearch 已正常工作。

Kibana 以 Deployment 资源运行，用户可通过 Service kibana-logging 访问其 Web GUI。这里已经将 Service 的类型修改为 NodePort。

通过 http://192.168.56.106:30319/ 访问 Kibana。

Kibana 会显示 Index Pattern 创建页面。直接点击 Create，Kibana 会自动完成后续配置。

这时，点击左上角的 Discover 就可以查看和检索 Kubernetes 日志了。

Kubernetes 日志管理系统已经就绪，用户可以根据需要创建自己的 Dashboard，具体方法可参考 Kibana 官方文档。

小结

Elasticsearch 附加组件本身会作为 Kubernetes 的应用在集群里运行，以实现集群的日志管理。它是一个 Elasticsearch、Fluentd 和 Kibana 的组合。
Elasticsearch 是一个搜索引擎，负责存储日志并提供查询接口。
Fluentd 负责从 Kubernetes 搜集日志并发送给 Elasticsearch。
Kibana 提供了一个 Web GUI，用户可以浏览和搜索存储在 Elasticsearch 中的日志。

写在最后

作为 Kubernetes 的实战教程，我们已经到了该收尾的地方。

本教程涵盖了 Kubernetes 最最重要的技术：集群架构、容器化应用部署、Scale Up/Down、滚动更新、监控检查、集群网络、数据管理、监控和日志管理，通过大量的实验探讨了 Kubernetes 的运行机制。

这个教程的目标是使读者能够掌握实施和管理 Kubernetes 的必需技能，能够真正将 Kubernetes 用起来。

为了达到这个目标，每一章都设计了大量的实践操作环节，通过截图和日志帮助读者理解各个技术要点，同时为读者自己实践 Kubernetes 提供详尽的参考。

本教程对读者应该会有两个作用：

  1. 初学者可以按照章节顺序系统地学习 Kubernetes，并通过教程中的实验掌握 Kubernetes 的理论知识和实操技能。

  2. 有经验的运维人员可以将本教程当做参考材料，在实际工作中有针对性地查看相关知识点。

希望读者们能够通过本教程打下扎实基础，能够从容地运维 Kubernetes ，并结合所在公司和组织的实际需求搭建出实用的容器管理平台。

其它参考：

https://www.cnblogs.com/CloudMan6/tag/Kubernetes/default.html?page=3

 

 Prometheus Operator 的架构

posted @   努力哥  阅读(1675)  评论(1)  编辑  收藏  举报
编辑推荐：
· 10年+ .NET Coder 心语，封装的思维：从隐藏、稳定开始理解其本质意义
· .NET Core 中如何实现缓存的预热？
· 从 HTTP 原因短语缺失研究 HTTP/2 和 HTTP/3 的设计差异
· AI与.NET技术实操系列：向量存储与相似性搜索在 .NET 中的实现
· 基于Microsoft.Extensions.AI核心库实现RAG应用
阅读排行：
· TypeScript + Deepseek 打造卜卦网站：技术与玄学的结合
· 阿里巴巴 QwQ-32B真的超越了 DeepSeek R-1吗？
· 【译】Visual Studio 中新的强大生产力特性
· 10年+ .NET Coder 心语 ── 封装的思维：从隐藏、稳定开始理解其本质意义
· 【设计模式】告别冗长if-else语句：使用策略模式优化代码结构
历史上的今天：
2018-05-10 docker详解
2017-05-10 爬虫之爬汽车之家
点击右上角即可分享
微信分享提示
AI IDE Trae