08 实战演练：玩转Kubernetes(1)

1. Kubernetes 技术要点回顾

  我会对前面学过的知识做一个比较全面的回顾，毕竟 Kubernetes 领域里有很多新名词、新术语、新架构，知识点多且杂，这样的总结复习就更有必要。

  接下来我还是先简要列举一下之前7篇 Kubernetes 要点，然后再综合运用这些知识，演示一个实战项目——还是搭建 WordPress 网站，不过这次不是在 Docker 里，而是在 Kubernetes 集群里。

1.1 容器编排

  容器技术开启了云原生的大潮，但成熟的容器技术，到生产环境的应用部署的时候，却显得“步履维艰”。因为容器只是针对单个进程的隔离和封装，而实际的应用场景却是要求许多的应用进程互相协同工作，其中的各种关系和需求非常复杂，在容器这个技术层次很难掌控。

  为了解决这个问题，容器编排（Container Orchestration）就出现了，它可以说是以前的运维工作在云原生世界的落地实践，本质上还是在集群里调度管理应用程序，只不过管理的主体由人变成了计算机，管理的目标由原生进程变成了容器和镜像。

  而现在，容器编排领域的王者就是——Kubernetes。

Kubernetes 源自 Borg 系统，它凝聚了 Google 的内部经验和 CNCF 的社区智慧，所以战胜了竞争对手 Apache Mesos 和 Docker Swarm，成为了容器编排领域的事实标准，也成为了云原生时代的基础操作系统，学习云原生就必须要掌握 Kubernetes。

1.2 Master/Node 架构及插件

  Kubernetes 的 Master/Node 架构是它具有自动化运维能力的关键，也对我们的学习至关重要，这里我再用另一张参考架构图来简略说明一下它的运行机制

1.2.1 Master/Node 架构

Kubernetes 把集群里的计算资源定义为节点（Node），其中又划分成控制面和数据面两类。

• 控制面是 Master 节点，负责管理集群和运维监控应用，里面的核心组件是 apiserver、etcd、scheduler、controller-manager。
• 数据面是 Worker 节点，受 Master 节点的管控，里面的核心组件是 kubelet、kube-proxy、container-runtime。

1.2.2 插件

此外，Kubernetes 还支持插件机制，能够灵活扩展各项功能，常用的插件有 DNS 和 Dashboard。

1.3 YAML 语言

  为了更好地管理集群和业务应用，Kubernetes 从现实世界中抽象出了许多概念，称为“API 对象”，描述这些对象就需要使用 YAML 语言。

  YAML 是 JSON 的超集，但语法更简洁，表现能力更强，更重要的是它以“声明式”来表述对象的状态，不涉及具体的操作细节，这样 Kubernetes 就能够依靠存储在 etcd 里集群的状态信息，不断地“调控”对象，直至实际状态与期望状态相同，这个过程就是 Kubernetes 的自动化运维管理

  使用 YAML 描述 API 对象也有固定的格式，必须写的“头字段”是“apiVersion”“kind”“metadata”，它们表示对象的版本、种类和名字等元信息。实体对象如 Pod、Job、CronJob 会再有“spec”字段描述对象的期望状态，最基本的就是容器信息，非实体对象如 ConfigMap、Secret 使用的是“data”字段，记录一些静态的字符串信息。

1.4 API 对象

  Kubernetes 里有很多的 API 对象

1.4.1 Pod对象

  Kubernetes其中最核心的对象是“Pod”，它捆绑了一组存在密切协作关系的容器，容器之间共享网络和存储，在集群里必须一起调度一起运行。通过 Pod 这个概念，Kubernetes 就简化了对容器的管理工作，其他的所有任务都是通过对 Pod 这个最小单位的再包装来实现的。

1.4.2 Job/CronJob 对象

  Job/CronJob 对应的是离线作业，它们逐层包装了 Pod，添加了作业控制和定时规则

1.4.3 ConfigMap/Secret 对象

  ConfigMap/Secret 对应的是配置信息，需要以环境变量或者存储卷的形式注入进 Pod，然后进程才能在运行时使用

1.5 Kubernetes 客户端工具

  和 Docker 类似，Kubernetes 也提供一个客户端工具，名字叫“kubectl”，它直接与 Master 节点的 apiserver 通信，把 YAML 文件发送给 RESTful 接口，从而触发 Kubernetes 的对象管理工作流程。

  kubectl 的命令很多，查看自带文档可以用 api-resources、explain ，查看对象状态可以用 get、describe、logs ，操作对象可以用 run、apply、exec、delete 等等

2. Kubernetes 搭建 WordPress 网站

  下面我们就在 Kubernetes 集群里再搭建出一个 WordPress 网站，用的镜像还是“入门篇”里的那三个应用：WordPress、MariaDB、Nginx，不过当时我们是直接以容器的形式来使用它们，现在要改成 Pod 的形式，让它们运行在 Kubernetes 里。

我还是画了一张简单的架构图，来说明这个系统的内部逻辑关系：

从这张图中你可以看到，网站的大体架构是没有变化的，毕竟应用还是那三个，它们的调用依赖关系也必然没有变化。

2.1 Kubernetes 系统和 Docker 系统的区别又在哪里?

  关键就在对应用的封装和网络环境这两点上。

  现在 WordPress、MariaDB 这两个应用被封装成了 Pod（由于它们都是在线业务，所以 Job/CronJob 在这里派不上用场），运行所需的环境变量也都被改写成 ConfigMap，统一用“声明式”来管理，比起 Shell 脚本更容易阅读和版本化管理。

  另外，Kubernetes 集群在内部维护了一个自己的专用网络，这个网络和外界隔离，要用特殊的“端口转发”方式来传递数据，还需要在集群之外用 Nginx 反向代理这个地址，这样才能实现内外沟通，对比 Docker 的直接端口映射，这里略微麻烦了一些。

2.2 WordPress 网站搭建步骤

了解基本架构之后，接下来我们就逐步搭建这个网站系统，总共需要 4 步。

2.2.1 编排 MariaDB 对象

  要编排 MariaDB 对象，它的具体运行需求可以参考“入门篇”的实战演练课，这里我就不再重复了。

2.2.1.1 定义< maria-cm >对象

  MariaDB 需要 4 个环境变量，比如数据库名、用户名、密码等，在 Docker 里我们是在命令行里使用参数 --env，而在 Kubernetes 里我们就应该使用 ConfigMap，为此需要定义一个 maria-cm 对象：

apiVersion: v1
kind: ConfigMap
metadata:
  name: maria-cm

data:
  DATABASE: 'db'
  USER: 'wp'
  PASSWORD: '123'
  ROOT_PASSWORD: '123'

2.2.1.2 定义 Pod 对象< maria-pod >

  然后我们定义 Pod 对象 maria-pod，把配置信息注入 Pod，让 MariaDB 运行时从环境变量读取这些信息：

  注意这里我们使用了一个新的字段“envFrom”，这是因为 ConfigMap 里的信息比较多，如果用 env.valueFrom 一个个地写会非常麻烦，容易出错，而 envFrom 可以一次性地把 ConfigMap 里的字段全导入进 Pod，并且能够指定变量名的前缀（即这里的 MARIADB_），非常方便。

apiVersion: v1
kind: Pod
metadata:
  name: maria-pod
  labels:
    app: wordpress
    role: database

spec:
  containers:
  - image: mariadb:10
    name: maria
    imagePullPolicy: IfNotPresent
    ports:
    - containerPort: 3306

    envFrom:
    - prefix: 'MARIADB_'
      configMapRef:
        name: maria-cm

2.2.1.3 创建对象

  使用 kubectl apply 创建这个对象之后，可以用 kubectl get pod 查看它的状态，如果想要获取 IP 地址需要加上参数 -o wide ：kubectl apply -f mariadb-pod.yml

kubectl apply -f mariadb-pod.yml
kubectl get pod -o wide

2.2.2 编排 WordPress 对象

2.2.3

2.2.4