我们在上一篇已经将Dockerfile精简为了：

1
2

FROM nginx:alpine
COPY ./dist /usr/share/nginx/html

但相信你也发现了，内容中还是对web服务器有着强依赖。当我们想换成其他版本的Nginx镜像，或换成其他Web服务器，就必须修改源代码中的Dockerfile，重新制作镜像。
这种情况并非不可能。典型的场景之一：我们镜像所依赖的Nginx或tomcat版本出现了某个安全事故，而该问题可以通过将web服务器或web容器版本升级到最新版本解决。
所以我们希望能在Dockerfile中将Nginx的痕迹彻底抹除，只在Kubernetes的YAML中指定web服务器。

一个很自然的想法就是：我们使用一个默认的web服务器镜像。在使用该镜像的容器启动之前，将静态网站的文件拷贝到相应目录，就像在前一篇从ConfigMap获取配置文件一样。
这就是initContainer的作用。

1. initContainer

我们首先将镜像改为alpine，并修改COPY的路径：

1
2

FROM alpine:latest
COPY ./dist /html

重新编译为latest版本（这是为了强制每次重新拉取镜像）：

虽然我们已经成功地将一个静态网站成功地在Kubernetes里部署起来了，但还有很多细节可以完善。我们就在这一节里逐步优化。

1. ConfigMap

问题最明显的是。重温一下我们静态网站之前使用的Dockerfile：

1
2
3

FROM nginx:alpine
COPY default.conf /etc/nginx/conf.d/default.conf
COPY ./dist /usr/share/nginx/html

首先是Nginx配置default.conf。
网站的源代码不应该干涉网站怎么部署。到底部署在Apache，Nginx还是Node.js，是否要在部署的时候添加自定义Header，都不该是开发者关注的事情。我们也不希望修改网站的timeout配置还需要动到源代码。从耦合性的角度来看，这个Nginx网站的配置文件不应该放到源代码中。
对于这类配置文件，Kubernetes里有专门的对象ConfigMap来保存。

从ConfigMap这个名字就可以猜得到，它存储的是配置信息，存储的格式是Map类型，即键值对。
配置信息可以是像本篇中的Nginx config配置，可以设置环境变量，可以是Java的properties和application.yml配置文件，可以是Redis和MySQL的配置文件。它很适合需要在一套Kubernetes集群上部署多个环境（例如特性分支/sit/uat）的情况。（当然我们的Java应用将使用Spring Cloud Config配置中心，所以目前不会用ConfigMap管理配置）
本篇POC的ConfigMap如下：

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

apiVersion: v1
kind: ConfigMap
metadata:
  name: poc-web-config
  labels:
    app: poc-web
data:
  default.conf: |
    server {
        listen       80;
        server_name  localhost;

        charset utf-8;
        #access_log  /var/log/nginx/log/host.access.log  main;

        location / {
            root   /usr/share/nginx/html;
            index  index.html index.htm;
        }

        #error_page  404              /404.html;

        # redirect server error pages to the static page /50x.html
        #
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   /usr/share/nginx/html;
        }
    }

default.conf为key（键），下面的内容为value（值）。结构非常简单。
在Kubernetes中，ConfigMap是一种特殊的Volume（卷）：Projected Volume。可以认为ConfigMap是Kubernetes中的数据被投射（Project）到容器中的。
关于Volume我们会在后续展开讨论，这里只是先提一下：要在容器中使用volume，需要先在spec中定义，然后mount到容器中。所以添加了ConfigMap后的Deployment定义YAML如下：

在上一篇中，通过NodePort模式，其实我们已经可以将一系列Pod暴露给集群外。但Service最多只能做好OSI 4层的负载均衡。而OSI 7层的负载均衡需要交给Ingress。
简单解释一下，2层的负载均衡就是虚拟MAC地址接收请求；3层的负载均衡就是虚拟IP地址；4层就是基于IP + 端口；7层就涉及URI等应用层。
以下文会提到的Traefik官方的一张图来说明，Ingress的作用就是根据不同的域名，正确找到对应的后台的Service：

在Service接到请求后，再负责转交给Pod：

要使用Ingress需要先安装一个Ingress Controller。一般比较常用的有两个：Nginx Ingress Controller和Traefik Ingress Controller。在我做POC的过程中一开始选择Nginx Ingress Controller，但总是curl调不通，于是最终选择了Traefik。Traefik还多带了一个UI不错的后台管理admin dashboard。而Nginx的不少功能需要用Nginx Plus版的才有。虽然也很理解，毕竟Nginx也是要恰饭的。。。
需要说明一点：虽然Nginx本身可以同时担任静态网站web server和反向代理两种职责，但Nginx Ingress Controller只负责反向代理。
Ingress Controller除了这两个之外，还是有F5的、Kong的和Voyager等等。从这里就可以看到Kubernetes的一大特点：指定了方向，让各厂家和开源开发者发挥自己的特长来做实现。

1. Traefik Ingress安装

安装按照官方文档一步步做就行了。
先配置RBAC（关于RBAC我们之后详细介绍）：

1

kubectl apply -f https://raw.githubusercontent.com/containous/traefik/v1.7/examples/k8s/traefik-rbac.yaml

然后配置Ingress Controller和对应的Service，对外暴露http的80端口和admin的8080端口。
Ingress Controller有两种部署方式：Deployment和DaemonSet。DaemonSet是一种特殊的Pod：

• 在每个节点上有且仅有一个Pod实例
• 当有新Worker节点加入时，自动在新节点上创建；旧节点被删除后，上面的DaemonSet Pod会被自动回收

两种方式各有各的好处。官方文档上都有详细比较，并在最后很贴心地对选择困难症给了建议：遇事不决先用DaemonSet试试。那么作为POC我就却之不恭选择DaemonSet了。反正要吃后悔药也就是几个命令的事情。

Deployment只是保证了支撑服务的Pod的数量，但是没有解决如何访问这些服务的问题。一个Pod只是一个运行服务的实例，随时可能在一个节点上停止，在另一个节点以一个新的IP启动一个新的Pod。因此不能以确定的IP和端口号提供服务。
要稳定地提供服务，需要服务发现和负载均衡能力。服务发现是一个微服务中很基础的概念，即当服务提供者网络发生变化时，服务消费者能及时获得最新的位置信息。对于k8s来说，服务提供者就是Pod，提供服务发现能力的是Service。Deployment和Service分别负责Pod的部署和访问策略，互不相关。
所以从下面这张图也可以看出来，Service和Deployment并不是上下层级的关系。

1. Service YAML

一个简单的Service YAML模板如下：

1
2
3
4
5
6
7
8
9
10
11

apiVersion: v1
kind: Service
metadata:
  name: <endpoint-name>
spec:
  ports:
  - port: <port>
    name: <port-name>
    targetPort: <target-port-number>
  selector:
    app: <app-name>

可以看到它是由selector.app来选择需要暴露的Pod。spec.ports.port是service对外暴露的端口，而targetPort是Pod的端口。默认使用TCP协议。
对于我们的POC的网站，service YAML定义如下：

1
2
3
4
5
6
7
8
9
10
11

apiVersion: v1
kind: Service
metadata:
  name: poc-web-service
spec:
  ports:
  - port: 80
    name: web
    targetPort: 80
  selector:
    app: poc-web

当我们查看已部署的service的时候，可以看到该service对应的ip：

我们上一章部署都是通过神奇的kubectl命令。我们这章就探寻一下，当我们拍下kubectl命令到Pod成功启动之间，Kubernetes究竟做了一些什么事情。
先上一张总的架构图，下面提到每个组件的时候可以在这张架构图上找位置，以及和其他组件间的关联关系：

1. 全流程

1.1 Kubectl

kubectl是用于针对Kubernetes集群运行命令的命令行接口。
虽然我们是在Master节点上执行运行的kubectl，但其实kubectl也可以在本地安装，与k8s的api server远程通信交互。
kubectl在接到apply命令后，会先做一个基本的验证。如果要创建的资源不合法，或YAML格式错误，就会快速失败。
除了通过kubectl之外，也可以直接调用api，或通过dashboard UI等多种方式与api server通信。

在通信之前，kubectl需要先进行身份认证。认证信息保存在$HOME/.kube/config文件里，大致内容如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

[root@docker-4 .kube]# pwd
/root/.kube
[root@docker-4 .kube]# cat config
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: <证书授权信息>
    server: https://10.16.34.54:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: kubernetes-admin
  name: kubernetes-admin@kubernetes
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:
- name: kubernetes-admin
  user:
    client-certificate-data: <客户端证书数据>

config文件中的clusters.cluster.server就是要访问的api server的地址

1.2 kube-apiserver

本篇我们开始用k8s的方式部署静态网站镜像，并通过这个过程了解k8s为什么会抽象出那么多概念。

1. Node

k8s首先需要选定在哪一台或哪几台服务器上部署。
如我们在kubeadm部署k8s集群的时候就已知的，k8s集群是由1-N台Master节点和N个Worker节点组成的。

k8s的设计原则之一就是不挑Worker节点的硬件配置。毕竟当初Google搭Borg集群的时候淘到的服务器硬件各式各样都有。（想起来当初搭Hadoop的时候也有人问过我是不是什么硬件都可以。。。以Hadoop MapReduce的吃硬盘和网络程度，实体机+专用万兆宽带跑出来的性能比虚拟机快出好几倍。当然配置低也的确能跑起来不死。）
你手头的机器可能是什么歪瓜裂枣都有：

不管是实体机还是虚拟机，不管什么硬件配置，不管高的矮的胖的瘦的，k8s都将其一视同仁地抽象为一个Node（曾经也有一个专有名词minion）。

一个典型的Node信息如下（部分删减）：

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

Name:               docker-7
Roles:              worker
Conditions:
  Type             Status  LastHeartbeatTime                 LastTransitionTime                Reason                       Message
  ----             ------  -----------------                 ------------------                ------                       -------
  MemoryPressure   False   Fri, 21 Jun 2019 16:58:54 +0800   Fri, 21 Jun 2019 16:57:54 +0800   KubeletHasSufficientMemory   kubelet has sufficient memory available
  DiskPressure     False   Fri, 21 Jun 2019 16:58:54 +0800   Fri, 21 Jun 2019 16:57:54 +0800   KubeletHasNoDiskPressure     kubelet has no disk pressure
  PIDPressure      False   Fri, 21 Jun 2019 16:58:54 +0800   Fri, 21 Jun 2019 16:57:54 +0800   KubeletHasSufficientPID      kubelet has sufficient PID available
  Ready            True    Fri, 21 Jun 2019 16:58:54 +0800   Fri, 21 Jun 2019 16:57:54 +0800   KubeletReady                 kubelet is posting ready status
Addresses:
  InternalIP:  10.16.34.59
  Hostname:    docker-7
Capacity:
 cpu:                4
 ephemeral-storage:  101729776Ki
 hugepages-2Mi:      0
 memory:             8010576Ki
 pods:               110
Allocatable:
 cpu:                4
 ephemeral-storage:  93754161407
 hugepages-2Mi:      0
 memory:             7908176Ki
 pods:               110
Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource           Requests    Limits
  --------           --------    ------
  cpu                320m (8%)   300m (7%)
  memory             150Mi (1%)  150Mi (1%)
  ephemeral-storage  0 (0%)      0 (0%)

Master节点不断轮询更新每个Node的状态信息：“你还活着么？压力大不大？CPU/内存/存储已经分配了多少？还剩下多少？”
这样当Master节点为了新的容器需求征兵时，就能很容易地知道哪几个节点还够压榨。

2. Pod

我们先从比较简单的部分开始做。静态网站是一个比较合适的开端。独立，有界面方便验证，而且无状态。

1. 搭建Docker私有仓库

按照容器的思路，我们需要先做一个静态网站文件+Nginx的镜像，然后在服务器上把镜像拖下来后实例化为容器运行。

从安全和网络速度上考虑，我们做的这个镜像不太适合放到公网的Docker Hub上。所以要先搭个私有仓库。

我们先在一台虚机上按照kubeadm部署指南中的“2.1 安装Docker”和“2.2 启动Docker服务”两节安装docker。然后关闭防火墙。最后执行一句docker run就解决了：

1

docker run -d -p 5000:5000 --restart=always --name docker-registry registry

一开始没有关闭防火墙，在启动的时候报错了。再次启动的时候提示容器已存在。这时候只需要将docker run命令改为docker start命令就可以了。
PS. 如果是要在Windows上运行，要把端口从5000映射到5001，不然会因为和Docker Desktop端口冲突而容器启动失败。
我把Docker Registry私有仓库部署在10.16.34.197服务器上，于是现在访问http://10.16.34.197:5000/v2/_catalog，就可以看到当前还没有镜像：

1

{"repositories":[]}

我们有个需求要在打开合同PDF的时候，要将response的header里的Content-Disposition从

1

attachment;filename*="utf-8\' \'文件名"

改为

1

inline;filename*="utf-8\' \'文件名"

这样文件就可以直接在浏览器里预览打开，而不是直接下载。
理论上最好的方式自然是从应用端解决。但我们提供文件的内容管理服务器不提供这个配置选项。虽然是开源软件，但我也不想为了这个修改源代码。除此之外，为了避免影响其他和文件相关的功能，减少回归测试量，我们也不想把全局修改这个header值。
那么剩下的办法就只有从Nginx反向代理层找解决方案了。理想的解决方案是对xxx.domain.com域名（内容管理服务器的域名），所有URL中带PDF关键字和“?inline=1”参数的请求，修改header中Content-Disposition的值。（我们可以在前端请求的时候加?inline=1这个path variable）
我模糊记得Nginx可以带if条件，所以原本估计就是个小case。事实证明我估计错得离谱【捂脸】。。。如果要直接看结论的请跳转到最后一节。

教训1：Nginx“基本”不支持if里多个条件

我先找到了一段匹配文件后缀的正则表达式：

1

.*\.(后缀1|后缀2)$

在较为彻底地理解了Docker原理后，我曾经天真地以为再花差不多的时间就可以同样掌握k8s。直到我看到一张k8s的核心概念关系图：

Docker只是其中粉红色的那一小块（Container）的一部分。。。

我也曾考虑过按照我的理解总结k8s优于Docker Swarm之处，以及为什么k8s能赢下容器编排大战。但很快发现这意味着我还需要先去熟悉Docker Swarm，才能较为准确地进行分析。这又何苦呢？我们已经知道了结论：Kubernetes是容器编排之战的最终战胜者。就算Docker Swarm有再多的优点，我们也不会采用。

我还考虑过类似Docker系列那样，先从原理开始整理。但k8s涉及的原理范围更广，从各种存储介质到OSI七层原理，先研究透再写的话估计还得花一个月。

所以我们跳过枯燥的原理介绍，先进行最有趣的实战环节，做一个包含接近完整功能的POC（Proof of Concept，概念验证）。在POC的过程中，我们再来逐渐熟悉k8s的架构设计和原理。

POC目标

我们的目标是把现在基于虚拟机的部署方式和基于脚本的打包方式，尝试用Docker容器+Kubernetes实现。
部署的时候还需要考虑：

• 服务高可用
• 节点扩展与收缩
• 安全性
• 与代码版本管理平台（Gitlab）和持续集成系统（Gitlab CI/Jenkins）的整合
• 多版本应用维护
• 日志收集
• 监控
• 数据备份
• …其他等等

下面是一个我们当前应用架构的精简版：

一般情况下我不喜欢把部署手册放到blog里。绝大多数情况下官网已经足够详尽，而且blog很可能因为版本陈旧误人子弟。曾经我写过Nginx的二进制部署手册，早就被轻松愉快的yum安装扫进了废纸堆。而使用了Docker和K8s后yum安装方式也被迅速淘汰。Hadoop的部署也被Cloudera全自动化部署替代了。
但kubernetes的部署由于涉及科学上网的问题，把原本几个命令就能解决的问题搞得相当复杂。所以希望这篇也能多少对还在被GFW恶心的人有些帮助。（当然可能更简单的方式是部署在墙外，比如AWS上）

0. 部署目标和硬件准备

0.1 部署目标

由于是测试目的，就不部署高可用了。高可用的部署可以参见最后的参考资料。
物理拓扑结构是1 Master + 3 Worker（Worker数量可轻松扩展）。

0.2 硬件准备

部署的Kubernetes版本是v1.14.2（截止2019/5/29的最新版本），Docker的版本是Docker CE 18.09.6（也是截止2019/5/29的最新版本）。
服务器全是VMWare虚拟机。虚机的硬件和操作系统如下：

下面所有的命令都是在root账号下执行的。