A.1.2 系统环境及部署准备

如前所述，Kubernetes 当前仍处于快速迭代的周期中，其版本变化频繁、跨版本的特性变化较大，为了帮助读者确认各配置和功能的可用性，本书使用如下基础环境。

1. 各相关组件及主机环境

操作系统、容器引擎、etcd 及 kubernetes 的相关版本分别如下：

• OS: CentOS 7.4 x86_64
• Container runtime: Docker 18.09 ce
• Kubernetes: 1.14.0

各主机角色分配及 IP 地址如表 A-1所示。

2. 基础环境设置

Kubernetes 的正确运行依赖于一些基础环境的设定，如各节点时间通过网络时间服务保持同步和主机名称解析等，集群规模较大的实践场景中，主机名称解析通常由 DNS 服务器完成。本测试示例中，时间同步服务直接基于系统的默认配置从互联网的时间服务中获取，主机名称解析则由 hosts 文件进行。

(1) 主机名称解析

分布式系统环境中的多主机通信通常基于主机名称进行，这在 IP 地址存在变化的可能性时为主机提供了固定的访问入口，因此一般需要由专用的 DNS 服务负责解决各节点主机名。不过，考虑到此处部署的是测试集群，因此为了降低系统复杂度，这里将采用基于 hosts 的文件进行主机名称解析。编辑 Master 和各 Node 上的 /etc/hosts 文件，确保其内容如下：

172.16.0.6 master.renkeju.mobi master
172.16.0.7 node01.renkeju.mobi node01
172.16.0.8 node02.renkeju.mobi node02
172.16.0.9 node03.renkeju.mobi node03

(2) 主机时间同步

如果各主机可直接访问互联网，则直接启动各主机上的 chronyd 服务即可。否则徐奥使用本地网络中的时间服务器，例如，可以将 Master 配置为 chrondy server，而后其他节点均从 Master 同步时间：

**[terminal]
**[path  ~]]**[delimiter  # ]**[command systemctl start chronyd.service]
**[path  ~]]**[delimiter  # ]**[command systemctl enable chronyd.service]

(3) 关闭防火墙服务

各 Node 运行的 kube-proxy 组件均要借助 iptables 或 ipvs 构建 Service 资源对象，该资源对象是 Kubernetes 的核心资源之一。出于简化问题复杂度之需，这里需要事先关闭所有主机之上的 iptables 或 firewalld 服务。

**[terminal]
**[path  ~]]**[delimiter  # ]**[command systemctl stop firewalld.service iptables.service]
**[path  ~]]**[delimiter  # ]**[command systemctl disable firewalld.service]
**[path  ~]]**[delimiter  # ]**[command systemctl disable ipatbles.service]

(4) 关闭并禁用 SELinux

若当前启用了 SELinux，则需要临时设置其当前状态为 permissive：

**[terminal]
**[path  ~]]**[delimiter  # ]**[command setenforce 0]

另外，编辑 /etc/sysconfig/selinux 文件，以彻底禁用 SELinux：

**[terminal]
**[path  ~]]**[delimiter  # ]**[command sed -i 's@^\(SELINUX=\).*@\1disabled@' /etc/sysconfig/selinux]

(5) 禁用 Swap 设备（可选步骤）

kubeadm 默认会预先检查当前主机是否禁用了 Swap 设备，并在未禁用时强制终止部署过程。因此，在主机内存资源充裕的条件下，需要分两步完成。首先是关闭当前已启用的所有 Swap 设备：

**[terminal]
**[path  ~]]**[delimiter  # ]**[command swapoff -a]

而后编辑 /etc/fstab 配置文件，注释用于挂载 Swap 设备的所有行。不同系统环境默认启用的 Swap 设备是不尽相同的，请读者根据实际情况完成响应操作。另外，部署时也可以选不禁用 Swap，而是通过后文的 kubeadm init 及 kubeadm join 命令执行时额外使用相关的选项忽略检查错误。

(6) 启用 ipvs 内核模块（可选步骤）

Kubernetes 1.11 之后的版本默认支持使用 ipvs 代理模式的 Service 资源，但它依赖于 ipvs 相关的内核模块，而这些模块默认不会自动载入。因此，这里选择创建载入内核模块相关的脚本文件 /etc/sysconfig/modules/ipvs.modules ，设定于系统引导时自动载入的 ipvs 相关的内核模块，以支持使用 ipvs 代理模式的 Service 资源。文件内容如下：

#!/bin/bash
ipvs_mods_dir="/usr/lib/modules/$(uname -r)/kernel/net/netfilter/ipvs"
for i in $(ls $ipvs_mods_dir | grep -o "^[^.]*"); do
    /sbin/modinfo -F filename $i &> /dev/null
    if [ $? -eq 0 ]; then
        /sbin/modprobe $i
    fi
done

而后修改文件权限，并手动为当前系统环境加载内核模块：

**[terminal]
**[path  ~]]**[delimiter  # ]**[command chmod +x /etc/sysconfig/modules/ipvs.modules]
**[path  ~]]**[delimiter  # ]**[command /etc/sysconfig/modules/ipvs.modules]

不过，ipvs 仅负责实现负载均衡相关的任务，它无法完成 kube-proxy 中的包过滤及 SNAT 等功能，这些仍需要由 iptables 实现。另外，对于初学者来说，前期的测试并非必然要用到 ipvs 代理模式。部署时可以省略此步骤。