最近在给某个老项目做技术栈还原需要在Ubuntu 16.04的一批旧服务器上把Kubernetes 1.14.0集群重新搭起来。网上能找到的教程要么年份太新命令对不上旧版本要么只贴命令不讲原因遇到报错完全不知道从哪里下手。我前后花了两周时间推倒重来三次踩遍了版本兼容、镜像拉取、网络插件不启动这一类坑最后整理成这套可以直接照着抄的实战手册。这篇文章不是什么大而全的Kubernetes理论课就是一份针对Ubuntu 16.04 Kubernetes 1.14.0这个特定组合的搭建记录。适合谁看呢给那些还要维护旧集群、在离线或半离线环境里部署老版本K8s的运维和开发同学。第一次搭K8s的新手也可以看我会把每个关键参数为什么这么配都讲明白避免你搭完以后不知道怎么改。在开始之前先给你交个底Kubernetes 1.14.0是2019年发布的老版本了很多东西和现在的v1.29、v1.30差别很大。如果你是新项目我建议直接用新版本如果你跟我一样被旧环境绑住那这份手册里的每一行命令都是经过实机验证的。1. 为什么还在搭1.14版本选型与整体规划1.1 这套组合适合哪类场景先说一个现实问题为什么都这个年代了还要碰1.14.0我这次遇到的场景是某内部系统的技术栈还原整套生产环境就是用Ubuntu 16.04和K8s 1.14.0搭的。后面接手的团队不敢贸然升级因为涉及几十个存量应用和自定义调度策略升级意味着回归测试成本太高只能先在测试环境完整复现一套同版本集群。这其实是很多公司里的真实状态。你以为大家都在追新版本实际上大量存量系统还跑在能不动就不动的版本上。Kubernetes 1.14.0虽然老但它的架构骨架已经相当完整Pod、Deployment、Service、Ingress、RBAC、HPA这些核心概念都已经稳定。对于学习和了解K8s演进过程来说它反而是一套没那么复杂、更容易看懂的版本。1.2 节点角色与资源分配建议我这次搭建用的是3台节点1个master加2个worker。其实1.14.0对资源要求不高但如果你想用它跑真实业务建议至少按下面的规格来节点角色数量推荐配置最小配置核心职责master14核8G2核4Gapiserver、controller-manager、scheduler、etcdworker24核8G2核4Gkubelet、kube-proxy、业务Pod主节点的etcd是整个集群的大脑记忆中枢所有资源状态都存它里面。所以主节点磁盘尽量不要用机械硬盘有条件上SSD哪怕小一点也比机械盘稳。我就吃过这个亏当时etcd用的是普通SATA盘集群正常时没问题一压测就出现apiserver超时。1.3 版本兼容矩阵Ubuntu、Docker、Kubernetes怎么配版本兼容是这次搭建最大的坑没有之一。Ubuntu 16.04默认内核是4.4而高版本的Docker在某些内核特性上会有兼容问题。我实测下来以下这组搭配是最稳的操作系统Ubuntu 16.04.7 LTS建议把内核升级到4.15的HWE版本Docker版本18.06.3-ceKubernetes版本1.14.0网络插件Flannel 0.11.0为什么Docker锁18.06因为Kubernetes 1.14发布时官方支持的Docker版本范围是1.13.1到18.09.x18.06是经过最多生产环境验证的版本。我当时手贱装了Docker 19.03结果kubelet一直报unknown runtime类错误后来才发现是版本兼容问题。内核为什么建议升到4.15因为Kubernetes的iptables、overlayfs等功能在4.15的内核上表现更稳定而且Ubuntu 16.04的HWE内核本来就是官方提供的内核升级方案风险比你自己编译内核低得多。如果你确实不想升内核4.4内核也能跑但我在实验中发现网络插件初始化偶尔会慢几秒。2. 环境初始化改完这几个配置再装K8s2.1 系统基础配置与主机名处理拿到3台Ubuntu 16.04服务器后先别急着装东西。第一步是把主机名改好这个看起来不起眼实际上影响后面kubeadm init和join的过程。Kubernetes节点之间是通过主机名互相解析的如果主机名重复或者包含奇怪的字符节点注册时会出现各种怪异问题。我的三台机器分别叫k8s-master、k8s-node1、k8s-node2。修改主机名用如下命令hostnamectl set-hostname k8s-master然后编辑/etc/hosts把三台机器的内网IP写进去10.0.0.11 k8s-master 10.0.0.12 k8s-node1 10.0.0.13 k8s-node2注意/etc/hosts里一定要写内网IP别写公网IP。Kubernetes集群内部的组件通信走的是内网你写公网IP不仅慢还可能因为网络策略限制导致apiserver无法访问。2.2 关闭swap与调整内核参数这一步是新手最容易忽略的。Kubernetes从设计上就要求节点关闭swap因为kubelet在管理Pod内存时如果发现系统在用swap它无法准确判断Pod的真实内存使用情况会导致调度和驱逐策略失灵。swapoff -a sed -i /swap/s/^/#/ /etc/fstab注意swapoff -a只是临时关闭重启后就又回来了所以必须注释掉/etc/fstab里的swap条目。我当时就是只执行了swapoff忘记改fstab结果一重启kubelet又报failed to run kubelet。接着加载内核网络模块并调整网络参数。Kubernetes的Service转发依赖iptables而iptables需要对桥接的网络流量做处理cat EOF /etc/sysctl.d/k8s.conf net.bridge.bridge-nf-call-iptables 1 net.bridge.bridge-nf-call-ip6tables 1 net.ipv4.ip_forward 1 EOF modprobe br_netfilter sysctl --system用lsmod | grep br_netfilter验证一下模块是否加载成功。如果不成功检查一下内核是否支持实在不行就要走升级内核的路线。2.3 安装Docker版本锁定和镜像加速Ubuntu 16.04上安装指定版本的Docker推荐用apt-pin方式锁定版本免得以后apt upgrade的时候Docker被自动升级导致K8s挂掉。apt-get update apt-get install -y \ apt-transport-https \ ca-certificates \ curl \ software-properties-common curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - add-apt-repository deb [archamd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable然后查询可用版本锁定18.06.3apt-cache madison docker-ce apt-get install -y docker-ce18.06.3~ce~3-0~ubuntu装完之后先别急着启动把镜像加速配好。Kubernetes要拉一堆镜像国内网络环境直接访问公共仓库经常拖很久。修改/etc/docker/daemon.json{ exec-opts: [native.cgroupdriversystemd], registry-mirrors: [https://你的镜像加速地址] }这里我用了native.cgroupdriversystemd这是为了和后面kubelet的cgroup驱动保持一致。关于cgroup驱动的坑我单独在2.4里展开。配置完重启Dockersystemctl daemon-reload systemctl restart docker systemctl enable docker2.4 配置kubelet与统一cgroup驱动cgroup驱动不一致是Kubernetes集群最常见的隐藏炸弹。Docker默认的cgroup驱动是cgroupfs而kubelet在1.14版本默认推荐systemd作为cgroup驱动。如果两者不一致kubelet启动后执行健康检查会报failed to get cpu stats节点状态直接NotReady。解决思路有两种要么把Docker的cgroup驱动改成cgroupfs和kubelet默认一致要么把Docker设成systemd然后让kubelet也用systemd。我更推荐后者因为systemd对资源管理的控制更统一也符合现代Linux系统的习惯。我前面在daemon.json里已经写了native.cgroupdriversystemd所以Docker这边已经OK了。kubelet那边怎么办两种方式一种是在启动参数里加--cgroup-driversystemd另一种是写kubelet配置文件。1.14版本的kubelet支持从/etc/default/kubelet读取环境变量我采用的方式是创建这个文件cat EOF /etc/default/kubelet KUBELET_EXTRA_ARGS--cgroup-driversystemd EOF这个文件路径在不同版本里可能有差异Ubuntu的kubelet默认读取的就是这个路径。装完kubelet之后这个配置才会生效所以这一节的内容先准备好等第3节装完组件以后再启动服务。3. 安装kubeadm、kubelet、kubectl三个命令锁定版本3.1 添加软件源并固定版本Kubernetes的官方软件源地址在这些年没什么变化但旧版本Ubuntu上需要确认一下签名方式。我用的是标准的安装流程curl -fsSL https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add - cat EOF /etc/apt/sources.list.d/kubernetes.list deb https://apt.kubernetes.io/ kubernetes-xenial main EOF注意这里的kubernetes-xenialUbuntu 16.04的代号就是xenial。安装时必须指定版本号否则apt会装到最新版那和1.14.0的kubeadm根本对不上apt-get update apt-get install -y \ kubelet1.14.0-00 \ kubeadm1.14.0-00 \ kubectl1.14.0-00安装完成后做一个版本钉住操作防止以后执行apt upgrade的时候把这几个包升掉apt-mark hold kubelet kubeadm kubectl这个操作非常建议做。我有个朋友就是没锁定某天例行升级把kubelet升了一级整个集群全部失联最后花了半天才回滚。生产环境里这种低级错误最致命。3.2 验证安装结果和命令可用性装上以后先验证一下别急着initkubeadm version kubelet --version kubectl version --client正常会看到类似输出kubeadm version: version.Info{Major:1, Minor:14, GitVersion:v1.14.0, ...}如果你看到kubectl client版本和服务器版本不匹配不用慌。Kubernetes官方支持client版本和server版本之间有一个小版本的偏差。但我们的目标是完全一致避免不必要的坑所以三台机器统一装1.14.0是最省心的。另外把kubelet服务先启动并设置开机自启systemctl enable kubelet这个时候不用管kubelet是否启动成功因为还没有执行kubeadm init集群配置还不存在kubelet会一直报错。这是正常现象别被吓到。4. 控制平面初始化kubeadm init 参数逐个解析4.1 初始化命令的关键参数与网络规划主节点执行初始化是整个搭建过程最关键的一步。我用的命令是kubeadm init \ --kubernetes-versionv1.14.0 \ --apiserver-advertise-address10.0.0.11 \ --pod-network-cidr10.244.0.0/16 \ --image-repositoryregistry.aliyuncs.com/google_containers逐个解释这些参数--kubernetes-version指定要部署的版本。别省略这个参数否则kubeadm会从网络上查询最新版本并部署那样就不是1.14.0了。--apiserver-advertise-addressapiserver对外通告的地址。这里填master节点的内网IP必须保证其他节点能访问到这个IP。--pod-network-cidrPod网络的CIDR段。这一步取决于你选什么网络插件。我用的是FlannelFlannel默认就是10.244.0.0/16所以这里必须填这个网段。你如果用Calico这里就要填10.240.0.0/16之类的其他网段。填错了网络插件和kube-controller-manager之间会一直在分配不到Pod网段的循环里。--image-repository指定镜像仓库。因为Kubernetes 1.14.0发布比较早公共镜像仓库的网络状况在部分网络环境里不稳定我用阿里云的google_containers镜像仓库作为替代。这一步在实际环境中非常关键如果网络条件受限你还可以把镜像预先下载好导入到本地但那一套流程更麻烦能用仓库方案尽量用仓库方案。执行完后如果一切顺利最后几行会输出类似这样的内容Your Kubernetes control-plane has initialized successfully! To start using your cluster, you need to run the following as a regular user: mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config You should now deploy a pod network to the cluster. Run kubectl apply -f [podnetwork].yaml with one of the options listed at: https://kubernetes.io/docs/concepts/cluster-administration/addons/看到Your Kubernetes control-plane has initialized successfully!就说明控制平面起来了。4.2 kubeconfig配置与kube-proxy模式调整初始化完成后root用户下可以直接用/etc/kubernetes/admin.conf访问集群。但为了日常操作方便我把它复制到当前用户的.kube目录下mkdir -p $HOME/.kube cp -i /etc/kubernetes/admin.conf $HOME/.kube/config chown $(id -u):$(id -g) $HOME/.kube/config这一步不做的话你执行kubectl get nodes会报refused或no configuration错误。1.14.0版本里kube-proxy默认使用iptables模式。如果你对性能有更高要求可以改成ipvs模式。ipvs模式在大规模Service场景下比iptables更高效因为它使用的哈希表比iptables的链式规则查找快得多。修改方式是编辑kube-system命名空间下的kube-proxy ConfigMapkubectl -n kube-system edit configmap/kube-proxy找到mode: 这一行改成mode: ipvs然后重启kube-proxy的所有Pod。但要注意如果节点没有加载ip_vs相关内核模块改了也是白改。确保内核模块加载modprobe ip_vs modprobe ip_vs_rr modprobe ip_vs_wrr modprobe ip_vs_sh我在实际环境里没有强制改ipvs因为服务规模不大iptables模式完全够用。如果你只是搭测试环境我建议保持默认少一个变量就少一个问题。4.3 部署Flannel网络插件控制平面起来以后节点还是NotReady状态因为Pod网络没通。我用的是Flannel安装方式就是apply一个yaml文件kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/v0.11.0/Documentation/kube-flannel.yml这里强烈建议指定版本号不要用master分支的yaml。不同版本的K8s和不同版本的Flannel之间配置格式可能不兼容。我第一次就是用了master版本的yaml导致Flannel Pod一直在CrashLoopBackOff后来锁定了v0.11.0才正常。如果你的网络环境无法直接下载这个yaml文件可以在一台网络正常的机器上先下载好再通过scp传到服务器上然后kubectl apply -f kube-flannel.yml。yaml文件里的镜像也可能拉不下来解决方案是把镜像tag改成你在本地仓库里已有的版本或者提前把镜像pull下来。我当时是把yaml里的quay.io/coreos/flannel:v0.11.0-amd64改成了registry.cn-hangzhou.aliyuncs.com/xxx/flannel:v0.11.0-amd64因为公司内部搭了一个镜像中转。等Flannel Pod起来以后再等个几十秒让路由信息同步然后检查节点状态kubectl get nodes正常情况下能看到NAME STATUS ROLES AGE VERSION k8s-master Ready master 5m v1.14.0如果还是NotReady先别急看下一节的排查方法。4.4 检查控制平面组件状态控制平面本身的Pod都在kube-system命名空间下用下面命令检查kubectl get pods -n kube-system正常情况下应该看到类似这样的列表NAME READY STATUS RESTARTS AGE etcd-k8s-master 1/1 Running 0 6m kube-apiserver-k8s-master 1/1 Running 0 6m kube-controller-manager-k8s-master 1/1 Running 0 6m kube-scheduler-k8s-master 1/1 Running 0 6m kube-proxy-xxxxx 1/1 Running 0 6m coredns-xxxxxxxxxx-xxxxx 1/1 Running 0 6m kube-flannel-ds-xxxxx 1/1 Running 0 4m如果你看到某个组件一直CrashLoopBackOff记录下来容器名然后用kubectl logs -n kube-system pod名看日志。常见的情况是apiserver的证书没生成对或者etcd集群没同步好。1.14版本的kubeadm一般不会自己出问题出了问题基本是环境创建阶段哪一步漏了。5. 工作节点接入与集群验证5.1 获取join命令主节点Ready以后接下来把两个worker节点加进来。kubeadm init成功后的输出里已经带了join命令但如果你当时没保存输出可以用下面的命令重新生成kubeadm token create --print-join-command输出类似kubeadm join 10.0.0.11:6443 --token xxxxxx.xxxxxxxxxxxxxxxx --discovery-token-ca-cert-hash sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx这个命令里的token有效期默认是24小时。如果你距离init时间超过24小时token会过期需要重新执行上面那条命令生成新token。然后到每台worker节点上执行这条join命令。我在worker节点上执行之前确保已经完成了第2节里的所有操作swap关闭、内核参数、Docker安装、cgroup驱动设置、kubeadm/kubelet安装。重复的环境准备工作一个都不能少我当时图省事有一台worker没关swap结果join之后kubelet一直起不来排查了半小时才想起来。worker节点执行完join命令不会立即显示Ready。需要等待一会儿让kubelet启动、拉镜像、注册节点。在主节点上不断查看watch kubectl get nodes5.2 验证节点状态和部署测试应用等两个worker节点变成Ready之后集群就正式可用了。但我习惯再做一个简单的功能验证确保不是虚的Ready。首先验证DNS是否正常。创建两个测试Pod通过跨Pod访问来确认网络是通的apiVersion: apps/v1 kind: Deployment metadata: name: nginx-test spec: replicas: 2 selector: matchLabels: app: nginx-test template: metadata: labels: app: nginx-test spec: containers: - name: nginx image: nginx:1.14 ports: - containerPort: 80注意Kubernetes 1.14版本的apps/v1已经支持Deployment不需要再用旧的extensions/v1beta1。存成nginx-test.yaml后kubectl apply -f nginx-test.yaml kubectl get pods -o wide看到两个Pod分别跑在两个节点上并且状态都是Running说明调度正常。再创建一个Service暴露kubectl expose deployment nginx-test --port80 --typeNodePort kubectl get svc最后访问一下NodePort端口比如curl http://任意节点IP:3xxxxx能返回nginx欢迎页说明Pod网络、Service转发都通了。到这一步一个能跑业务的Kubernetes 1.14.0集群就算彻底搭完了。6. 常见问题与故障排查实录6.1 节点NotReady的几种典型原因我在搭建过程中反复遇到的最典型问题就是节点NotReady。归纳下来90%的情况出在这几个地方第一cgroup驱动不一致。Docker用cgroupfs、kubelet用systemd或者反过来都会导致kubelet健康检查失败。排查方法docker info | grep cgroup看Docker的驱动ps -ef | grep kubelet | grep cgroup看kubelet的驱动两者必须一致。第二网络插件没部署或网段不对。如果初始化的时候没指定--pod-network-cidrFlannel会失败或者初始化时指定了10.244.0.0/16以外的网段而Flannel默认用的还是10.244也会失败。排查方法kubectl logs -n kube-system -l appflannel看日志里面会直接报subnet分配错误。第三swap没关干净。查看/etc/fstab确保swap那行是被注释的。有些云平台的默认镜像里swap是通过systemd单元启动的光改fstab可能不够还要systemctl mask swap.target禁用整个swap单元。6.2 kubelet反复重启怎么定位kubelet重启是另一个高频问题。如果你的worker节点join以后kubelet一直在重启最直接的办法是看它的系统日志journalctl -u kubelet -f日志会告诉你kubelet为什么起不来。我遇到过一次日志里反复出现failed to set up init node那其实是Kubelet在尝试建立node对象时apiserver那边返回了证书校验失败。原因是我在worker节点的/etc/hosts里把master的IP写错了。所以join之前先确认三台机器之间能互相通信telnet一下6443端口最稳妥。6.3 问题排查速查表最后把我这次搭建中踩过的坑整理成一张速查表方便你排查问题时快速定位现象可能原因排查与解决kubeadm init卡在拉镜像网络受限、镜像仓库不稳定换用--image-repository指定可用仓库或提前导入镜像节点一直NotReady网络插件没起来或网段不匹配检查flannel Pod日志核对pod-network-cidrkubelet报cgroup错误Docker与kubelet驱动不一致统一cgroup驱动为systemdjoin后token失效初始化时间超过24小时用kubeadm token create重新生成apiserver访问超时主机记录错误、防火墙拦截检查/etc/hosts、放大超时时间Dashboard登录不了RBAC权限未配置为服务账号绑定cluster-admin角色这只是一张快速索引表详细原因还是要去翻对应组件的日志。Kubernetes排障的核心思路就一句话先看Pod状态再看日志最后看事件。个人在实际搭建中的体会Kubernetes 1.14.0这套东西其实不难真正难的都是环境层面的杂音。版本不匹配、配置不一致、网络不通这三个问题占了排障时间的八成以上。所以我的建议是动手之前先把3台机器的系统配置用脚本统一跑一遍然后一步一验证别一次性把所有组件装完再回头查问题。
最近在给某个老项目做技术栈还原需要在Ubuntu 16.04的一批旧服务器上把Kubernetes 1.14.0集群重新搭起来。网上能找到的教程要么年份太新命令对不上旧版本要么只贴命令不讲原因遇到报错完全不知道从哪里下手。我前后花了两周时间推倒重来三次踩遍了版本兼容、镜像拉取、网络插件不启动这一类坑最后整理成这套可以直接照着抄的实战手册。这篇文章不是什么大而全的Kubernetes理论课就是一份针对Ubuntu 16.04 Kubernetes 1.14.0这个特定组合的搭建记录。适合谁看呢给那些还要维护旧集群、在离线或半离线环境里部署老版本K8s的运维和开发同学。第一次搭K8s的新手也可以看我会把每个关键参数为什么这么配都讲明白避免你搭完以后不知道怎么改。在开始之前先给你交个底Kubernetes 1.14.0是2019年发布的老版本了很多东西和现在的v1.29、v1.30差别很大。如果你是新项目我建议直接用新版本如果你跟我一样被旧环境绑住那这份手册里的每一行命令都是经过实机验证的。1. 为什么还在搭1.14版本选型与整体规划1.1 这套组合适合哪类场景先说一个现实问题为什么都这个年代了还要碰1.14.0我这次遇到的场景是某内部系统的技术栈还原整套生产环境就是用Ubuntu 16.04和K8s 1.14.0搭的。后面接手的团队不敢贸然升级因为涉及几十个存量应用和自定义调度策略升级意味着回归测试成本太高只能先在测试环境完整复现一套同版本集群。这其实是很多公司里的真实状态。你以为大家都在追新版本实际上大量存量系统还跑在能不动就不动的版本上。Kubernetes 1.14.0虽然老但它的架构骨架已经相当完整Pod、Deployment、Service、Ingress、RBAC、HPA这些核心概念都已经稳定。对于学习和了解K8s演进过程来说它反而是一套没那么复杂、更容易看懂的版本。1.2 节点角色与资源分配建议我这次搭建用的是3台节点1个master加2个worker。其实1.14.0对资源要求不高但如果你想用它跑真实业务建议至少按下面的规格来节点角色数量推荐配置最小配置核心职责master14核8G2核4Gapiserver、controller-manager、scheduler、etcdworker24核8G2核4Gkubelet、kube-proxy、业务Pod主节点的etcd是整个集群的大脑记忆中枢所有资源状态都存它里面。所以主节点磁盘尽量不要用机械硬盘有条件上SSD哪怕小一点也比机械盘稳。我就吃过这个亏当时etcd用的是普通SATA盘集群正常时没问题一压测就出现apiserver超时。1.3 版本兼容矩阵Ubuntu、Docker、Kubernetes怎么配版本兼容是这次搭建最大的坑没有之一。Ubuntu 16.04默认内核是4.4而高版本的Docker在某些内核特性上会有兼容问题。我实测下来以下这组搭配是最稳的操作系统Ubuntu 16.04.7 LTS建议把内核升级到4.15的HWE版本Docker版本18.06.3-ceKubernetes版本1.14.0网络插件Flannel 0.11.0为什么Docker锁18.06因为Kubernetes 1.14发布时官方支持的Docker版本范围是1.13.1到18.09.x18.06是经过最多生产环境验证的版本。我当时手贱装了Docker 19.03结果kubelet一直报unknown runtime类错误后来才发现是版本兼容问题。内核为什么建议升到4.15因为Kubernetes的iptables、overlayfs等功能在4.15的内核上表现更稳定而且Ubuntu 16.04的HWE内核本来就是官方提供的内核升级方案风险比你自己编译内核低得多。如果你确实不想升内核4.4内核也能跑但我在实验中发现网络插件初始化偶尔会慢几秒。2. 环境初始化改完这几个配置再装K8s2.1 系统基础配置与主机名处理拿到3台Ubuntu 16.04服务器后先别急着装东西。第一步是把主机名改好这个看起来不起眼实际上影响后面kubeadm init和join的过程。Kubernetes节点之间是通过主机名互相解析的如果主机名重复或者包含奇怪的字符节点注册时会出现各种怪异问题。我的三台机器分别叫k8s-master、k8s-node1、k8s-node2。修改主机名用如下命令hostnamectl set-hostname k8s-master然后编辑/etc/hosts把三台机器的内网IP写进去10.0.0.11 k8s-master 10.0.0.12 k8s-node1 10.0.0.13 k8s-node2注意/etc/hosts里一定要写内网IP别写公网IP。Kubernetes集群内部的组件通信走的是内网你写公网IP不仅慢还可能因为网络策略限制导致apiserver无法访问。2.2 关闭swap与调整内核参数这一步是新手最容易忽略的。Kubernetes从设计上就要求节点关闭swap因为kubelet在管理Pod内存时如果发现系统在用swap它无法准确判断Pod的真实内存使用情况会导致调度和驱逐策略失灵。swapoff -a sed -i /swap/s/^/#/ /etc/fstab注意swapoff -a只是临时关闭重启后就又回来了所以必须注释掉/etc/fstab里的swap条目。我当时就是只执行了swapoff忘记改fstab结果一重启kubelet又报failed to run kubelet。接着加载内核网络模块并调整网络参数。Kubernetes的Service转发依赖iptables而iptables需要对桥接的网络流量做处理cat EOF /etc/sysctl.d/k8s.conf net.bridge.bridge-nf-call-iptables 1 net.bridge.bridge-nf-call-ip6tables 1 net.ipv4.ip_forward 1 EOF modprobe br_netfilter sysctl --system用lsmod | grep br_netfilter验证一下模块是否加载成功。如果不成功检查一下内核是否支持实在不行就要走升级内核的路线。2.3 安装Docker版本锁定和镜像加速Ubuntu 16.04上安装指定版本的Docker推荐用apt-pin方式锁定版本免得以后apt upgrade的时候Docker被自动升级导致K8s挂掉。apt-get update apt-get install -y \ apt-transport-https \ ca-certificates \ curl \ software-properties-common curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - add-apt-repository deb [archamd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable然后查询可用版本锁定18.06.3apt-cache madison docker-ce apt-get install -y docker-ce18.06.3~ce~3-0~ubuntu装完之后先别急着启动把镜像加速配好。Kubernetes要拉一堆镜像国内网络环境直接访问公共仓库经常拖很久。修改/etc/docker/daemon.json{ exec-opts: [native.cgroupdriversystemd], registry-mirrors: [https://你的镜像加速地址] }这里我用了native.cgroupdriversystemd这是为了和后面kubelet的cgroup驱动保持一致。关于cgroup驱动的坑我单独在2.4里展开。配置完重启Dockersystemctl daemon-reload systemctl restart docker systemctl enable docker2.4 配置kubelet与统一cgroup驱动cgroup驱动不一致是Kubernetes集群最常见的隐藏炸弹。Docker默认的cgroup驱动是cgroupfs而kubelet在1.14版本默认推荐systemd作为cgroup驱动。如果两者不一致kubelet启动后执行健康检查会报failed to get cpu stats节点状态直接NotReady。解决思路有两种要么把Docker的cgroup驱动改成cgroupfs和kubelet默认一致要么把Docker设成systemd然后让kubelet也用systemd。我更推荐后者因为systemd对资源管理的控制更统一也符合现代Linux系统的习惯。我前面在daemon.json里已经写了native.cgroupdriversystemd所以Docker这边已经OK了。kubelet那边怎么办两种方式一种是在启动参数里加--cgroup-driversystemd另一种是写kubelet配置文件。1.14版本的kubelet支持从/etc/default/kubelet读取环境变量我采用的方式是创建这个文件cat EOF /etc/default/kubelet KUBELET_EXTRA_ARGS--cgroup-driversystemd EOF这个文件路径在不同版本里可能有差异Ubuntu的kubelet默认读取的就是这个路径。装完kubelet之后这个配置才会生效所以这一节的内容先准备好等第3节装完组件以后再启动服务。3. 安装kubeadm、kubelet、kubectl三个命令锁定版本3.1 添加软件源并固定版本Kubernetes的官方软件源地址在这些年没什么变化但旧版本Ubuntu上需要确认一下签名方式。我用的是标准的安装流程curl -fsSL https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add - cat EOF /etc/apt/sources.list.d/kubernetes.list deb https://apt.kubernetes.io/ kubernetes-xenial main EOF注意这里的kubernetes-xenialUbuntu 16.04的代号就是xenial。安装时必须指定版本号否则apt会装到最新版那和1.14.0的kubeadm根本对不上apt-get update apt-get install -y \ kubelet1.14.0-00 \ kubeadm1.14.0-00 \ kubectl1.14.0-00安装完成后做一个版本钉住操作防止以后执行apt upgrade的时候把这几个包升掉apt-mark hold kubelet kubeadm kubectl这个操作非常建议做。我有个朋友就是没锁定某天例行升级把kubelet升了一级整个集群全部失联最后花了半天才回滚。生产环境里这种低级错误最致命。3.2 验证安装结果和命令可用性装上以后先验证一下别急着initkubeadm version kubelet --version kubectl version --client正常会看到类似输出kubeadm version: version.Info{Major:1, Minor:14, GitVersion:v1.14.0, ...}如果你看到kubectl client版本和服务器版本不匹配不用慌。Kubernetes官方支持client版本和server版本之间有一个小版本的偏差。但我们的目标是完全一致避免不必要的坑所以三台机器统一装1.14.0是最省心的。另外把kubelet服务先启动并设置开机自启systemctl enable kubelet这个时候不用管kubelet是否启动成功因为还没有执行kubeadm init集群配置还不存在kubelet会一直报错。这是正常现象别被吓到。4. 控制平面初始化kubeadm init 参数逐个解析4.1 初始化命令的关键参数与网络规划主节点执行初始化是整个搭建过程最关键的一步。我用的命令是kubeadm init \ --kubernetes-versionv1.14.0 \ --apiserver-advertise-address10.0.0.11 \ --pod-network-cidr10.244.0.0/16 \ --image-repositoryregistry.aliyuncs.com/google_containers逐个解释这些参数--kubernetes-version指定要部署的版本。别省略这个参数否则kubeadm会从网络上查询最新版本并部署那样就不是1.14.0了。--apiserver-advertise-addressapiserver对外通告的地址。这里填master节点的内网IP必须保证其他节点能访问到这个IP。--pod-network-cidrPod网络的CIDR段。这一步取决于你选什么网络插件。我用的是FlannelFlannel默认就是10.244.0.0/16所以这里必须填这个网段。你如果用Calico这里就要填10.240.0.0/16之类的其他网段。填错了网络插件和kube-controller-manager之间会一直在分配不到Pod网段的循环里。--image-repository指定镜像仓库。因为Kubernetes 1.14.0发布比较早公共镜像仓库的网络状况在部分网络环境里不稳定我用阿里云的google_containers镜像仓库作为替代。这一步在实际环境中非常关键如果网络条件受限你还可以把镜像预先下载好导入到本地但那一套流程更麻烦能用仓库方案尽量用仓库方案。执行完后如果一切顺利最后几行会输出类似这样的内容Your Kubernetes control-plane has initialized successfully! To start using your cluster, you need to run the following as a regular user: mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config You should now deploy a pod network to the cluster. Run kubectl apply -f [podnetwork].yaml with one of the options listed at: https://kubernetes.io/docs/concepts/cluster-administration/addons/看到Your Kubernetes control-plane has initialized successfully!就说明控制平面起来了。4.2 kubeconfig配置与kube-proxy模式调整初始化完成后root用户下可以直接用/etc/kubernetes/admin.conf访问集群。但为了日常操作方便我把它复制到当前用户的.kube目录下mkdir -p $HOME/.kube cp -i /etc/kubernetes/admin.conf $HOME/.kube/config chown $(id -u):$(id -g) $HOME/.kube/config这一步不做的话你执行kubectl get nodes会报refused或no configuration错误。1.14.0版本里kube-proxy默认使用iptables模式。如果你对性能有更高要求可以改成ipvs模式。ipvs模式在大规模Service场景下比iptables更高效因为它使用的哈希表比iptables的链式规则查找快得多。修改方式是编辑kube-system命名空间下的kube-proxy ConfigMapkubectl -n kube-system edit configmap/kube-proxy找到mode: 这一行改成mode: ipvs然后重启kube-proxy的所有Pod。但要注意如果节点没有加载ip_vs相关内核模块改了也是白改。确保内核模块加载modprobe ip_vs modprobe ip_vs_rr modprobe ip_vs_wrr modprobe ip_vs_sh我在实际环境里没有强制改ipvs因为服务规模不大iptables模式完全够用。如果你只是搭测试环境我建议保持默认少一个变量就少一个问题。4.3 部署Flannel网络插件控制平面起来以后节点还是NotReady状态因为Pod网络没通。我用的是Flannel安装方式就是apply一个yaml文件kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/v0.11.0/Documentation/kube-flannel.yml这里强烈建议指定版本号不要用master分支的yaml。不同版本的K8s和不同版本的Flannel之间配置格式可能不兼容。我第一次就是用了master版本的yaml导致Flannel Pod一直在CrashLoopBackOff后来锁定了v0.11.0才正常。如果你的网络环境无法直接下载这个yaml文件可以在一台网络正常的机器上先下载好再通过scp传到服务器上然后kubectl apply -f kube-flannel.yml。yaml文件里的镜像也可能拉不下来解决方案是把镜像tag改成你在本地仓库里已有的版本或者提前把镜像pull下来。我当时是把yaml里的quay.io/coreos/flannel:v0.11.0-amd64改成了registry.cn-hangzhou.aliyuncs.com/xxx/flannel:v0.11.0-amd64因为公司内部搭了一个镜像中转。等Flannel Pod起来以后再等个几十秒让路由信息同步然后检查节点状态kubectl get nodes正常情况下能看到NAME STATUS ROLES AGE VERSION k8s-master Ready master 5m v1.14.0如果还是NotReady先别急看下一节的排查方法。4.4 检查控制平面组件状态控制平面本身的Pod都在kube-system命名空间下用下面命令检查kubectl get pods -n kube-system正常情况下应该看到类似这样的列表NAME READY STATUS RESTARTS AGE etcd-k8s-master 1/1 Running 0 6m kube-apiserver-k8s-master 1/1 Running 0 6m kube-controller-manager-k8s-master 1/1 Running 0 6m kube-scheduler-k8s-master 1/1 Running 0 6m kube-proxy-xxxxx 1/1 Running 0 6m coredns-xxxxxxxxxx-xxxxx 1/1 Running 0 6m kube-flannel-ds-xxxxx 1/1 Running 0 4m如果你看到某个组件一直CrashLoopBackOff记录下来容器名然后用kubectl logs -n kube-system pod名看日志。常见的情况是apiserver的证书没生成对或者etcd集群没同步好。1.14版本的kubeadm一般不会自己出问题出了问题基本是环境创建阶段哪一步漏了。5. 工作节点接入与集群验证5.1 获取join命令主节点Ready以后接下来把两个worker节点加进来。kubeadm init成功后的输出里已经带了join命令但如果你当时没保存输出可以用下面的命令重新生成kubeadm token create --print-join-command输出类似kubeadm join 10.0.0.11:6443 --token xxxxxx.xxxxxxxxxxxxxxxx --discovery-token-ca-cert-hash sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx这个命令里的token有效期默认是24小时。如果你距离init时间超过24小时token会过期需要重新执行上面那条命令生成新token。然后到每台worker节点上执行这条join命令。我在worker节点上执行之前确保已经完成了第2节里的所有操作swap关闭、内核参数、Docker安装、cgroup驱动设置、kubeadm/kubelet安装。重复的环境准备工作一个都不能少我当时图省事有一台worker没关swap结果join之后kubelet一直起不来排查了半小时才想起来。worker节点执行完join命令不会立即显示Ready。需要等待一会儿让kubelet启动、拉镜像、注册节点。在主节点上不断查看watch kubectl get nodes5.2 验证节点状态和部署测试应用等两个worker节点变成Ready之后集群就正式可用了。但我习惯再做一个简单的功能验证确保不是虚的Ready。首先验证DNS是否正常。创建两个测试Pod通过跨Pod访问来确认网络是通的apiVersion: apps/v1 kind: Deployment metadata: name: nginx-test spec: replicas: 2 selector: matchLabels: app: nginx-test template: metadata: labels: app: nginx-test spec: containers: - name: nginx image: nginx:1.14 ports: - containerPort: 80注意Kubernetes 1.14版本的apps/v1已经支持Deployment不需要再用旧的extensions/v1beta1。存成nginx-test.yaml后kubectl apply -f nginx-test.yaml kubectl get pods -o wide看到两个Pod分别跑在两个节点上并且状态都是Running说明调度正常。再创建一个Service暴露kubectl expose deployment nginx-test --port80 --typeNodePort kubectl get svc最后访问一下NodePort端口比如curl http://任意节点IP:3xxxxx能返回nginx欢迎页说明Pod网络、Service转发都通了。到这一步一个能跑业务的Kubernetes 1.14.0集群就算彻底搭完了。6. 常见问题与故障排查实录6.1 节点NotReady的几种典型原因我在搭建过程中反复遇到的最典型问题就是节点NotReady。归纳下来90%的情况出在这几个地方第一cgroup驱动不一致。Docker用cgroupfs、kubelet用systemd或者反过来都会导致kubelet健康检查失败。排查方法docker info | grep cgroup看Docker的驱动ps -ef | grep kubelet | grep cgroup看kubelet的驱动两者必须一致。第二网络插件没部署或网段不对。如果初始化的时候没指定--pod-network-cidrFlannel会失败或者初始化时指定了10.244.0.0/16以外的网段而Flannel默认用的还是10.244也会失败。排查方法kubectl logs -n kube-system -l appflannel看日志里面会直接报subnet分配错误。第三swap没关干净。查看/etc/fstab确保swap那行是被注释的。有些云平台的默认镜像里swap是通过systemd单元启动的光改fstab可能不够还要systemctl mask swap.target禁用整个swap单元。6.2 kubelet反复重启怎么定位kubelet重启是另一个高频问题。如果你的worker节点join以后kubelet一直在重启最直接的办法是看它的系统日志journalctl -u kubelet -f日志会告诉你kubelet为什么起不来。我遇到过一次日志里反复出现failed to set up init node那其实是Kubelet在尝试建立node对象时apiserver那边返回了证书校验失败。原因是我在worker节点的/etc/hosts里把master的IP写错了。所以join之前先确认三台机器之间能互相通信telnet一下6443端口最稳妥。6.3 问题排查速查表最后把我这次搭建中踩过的坑整理成一张速查表方便你排查问题时快速定位现象可能原因排查与解决kubeadm init卡在拉镜像网络受限、镜像仓库不稳定换用--image-repository指定可用仓库或提前导入镜像节点一直NotReady网络插件没起来或网段不匹配检查flannel Pod日志核对pod-network-cidrkubelet报cgroup错误Docker与kubelet驱动不一致统一cgroup驱动为systemdjoin后token失效初始化时间超过24小时用kubeadm token create重新生成apiserver访问超时主机记录错误、防火墙拦截检查/etc/hosts、放大超时时间Dashboard登录不了RBAC权限未配置为服务账号绑定cluster-admin角色这只是一张快速索引表详细原因还是要去翻对应组件的日志。Kubernetes排障的核心思路就一句话先看Pod状态再看日志最后看事件。个人在实际搭建中的体会Kubernetes 1.14.0这套东西其实不难真正难的都是环境层面的杂音。版本不匹配、配置不一致、网络不通这三个问题占了排障时间的八成以上。所以我的建议是动手之前先把3台机器的系统配置用脚本统一跑一遍然后一步一验证别一次性把所有组件装完再回头查问题。
