Kubernetes(k8s) 凭借着其优良的架构,灵活的扩展能力,丰富的应用编排模型,成为了容器编排领域的事实标准。愈来愈多的企业拥抱这一趋势,选择 k8s 做为容器化应用的基础设施,逐渐将本身的核心服务迁移到 k8s 之上。html
可用性对基础设施而言相当重要。各大云计算厂商纷纷推出了高可用、可扩展的 k8s 托管服务,其中比较有表明性的有 Amazon EKS、Azure Kubernetes Service (AKS)、Google Kubernetes Engine、阿里云容器服务 Kubernetes 版等。node
虽然公有云托管的 k8s 服务百花齐放,但不少企业仍有自建集群的需求。正是这样的缘由,促进了一大批出色的 k8s 集群部署方案的诞生,他们的特色以下表所示。nginx
部署方案 | 特色 |
---|---|
Kubeadm | 1. 官方出品的部署工具,提供了 k8s 集群生命周期管理的领域知识。 |
2. 旨在成为更高级别工具的可组合构建块。 | |
Kubespray | 1. 支持在裸机和 AWS、GCE、Azure 等众多云平台上部署 k8s。 |
2. 基于 Ansible Playbook 定义 k8s 集群部署任务。
3. 支持大部分流行的 Linux 发行版。 |
| Kops | 1. 仅支持在 AWS、GCE 等少数云平台上部署 k8s。
2. 创建在状态同步模型上,用于 dry-run 和自动幂等性。
3. 可以自动生成 Terraform 配置。 |
| Rancher Kubernetes Engine(RKE) | 1. 著名的开源企业级容器管理平台 Rancher 提供的轻量级 k8s 安装工具。
2. 支持在裸机、虚拟机、公有云上部署和管理 k8s 集群。 |git
上述方案中,RKE 在易用性和灵活性上占有优点。本文接下来将介绍如何经过 RKE 部署一套高可用 k8s 集群,文中使用的 RKE 版本为v0.2.2
。github
首先须要了解高可用 k8s 集群的架构特色,下图是官方推荐的高可用集群架构图。docker
其核心思想是让 k8s master 节点中的各种组件具有高可用性,消除单点故障。api
此外,构建集群的时还须要注意下列问题。服务器
构建集群的第一步是将拥有的服务器按节点功能进行划分,下表展现了笔者环境下的节点规划状况。网络
IP | 角色 |
---|---|
192.168.0.10 | 部署节点 |
192.168.0.11 | k8s master - api-server, etcd, scheduler, controller-manager |
192.168.0.12 | k8s master - api-server, etcd, scheduler, controller-manager |
192.168.0.13 | k8s master - api-server, etcd, scheduler, controller-manager |
192.168.0.14 | k8s worker - kubelet, kube-proxy |
192.168.0.15 | k8s worker - kubelet, kube-proxy |
192.168.0.16 | k8s worker - kubelet, kube-proxy |
192.168.0.17 | k8s worker - kubelet, kube-proxy |
规划说明:架构
192.168.0.10
做为部署节点。若是机器数很少,能够将部署节点加入到 k8s 集群中。在完成节点规划后,须要进行环境准备工做,主要包含如下内容:
rancher/hyperkube
启动 k8s 组件,所以须要在 k8s 集群的各个节点(192.168.0.11 ~ 192.168.0.17 这 7 台机器)上安装 docker。在完成环境准备后,须要经过 cluster.yml 描述集群的组成和 k8s 的部署方式。
配置文件 cluster.yml 中的 nodes 配置项用于描述集群的组成。根据节点规划,对于 k8s master 节点,指定其角色为controlplane
和etcd
。对于 k8s worker 节点,指定其角色为worker
。
nodes: - address: 192.168.0.1 user: admin role: - controlplane - etcd ... - address: 192.168.0.7 user: admin role: - worker
K8s 的 worker node 除了运行 pod 类进程外,还会运行不少其余的重要进程,包括 k8s 管理进程,如 kubelet、dockerd,以及系统进程,如 systemd。这些进程对整个集群的稳定性相当重要,所以须要为他们专门预留必定的资源。
笔者环境中的 worker 设置以下:
在此场景下,节点可分配的 CPU 资源是 29 核,可分配的内存资源是 60.5Gi,可分配的磁盘资源是 88Gi。对于不可压缩资源,当 pod 的内存使用总量超过 60.5Gi 或者磁盘使用总量超过 88Gi 时,QoS 较低的 pod 将被优先驱逐。对于可压缩资源,若是节点上的全部进程都尽量多的使用 CPU,则 pod 类进程加起来不会使用超过 29 核的 CPU 资源。
上述资源预留设置在 cluster.yml 中具体形式以下。
services: kubelet: extra_args: cgroups-per-qos: True cgroup-driver: cgroupfs kube-reserved: cpu=1,memory=2Gi,ephemeral-storage=1Gi kube-reserved-cgroup: /runtime.service system-reserved: cpu=1,memory=1Gi,ephemeral-storage=1Gi system-reserved-cgroup: /system.slice enforce-node-allocatable: pods,kube-reserved,system-reserved eviction-hard: memory.available<500Mi,nodefs.available<10%
关于资源预留更详细的内容可参考文章 Reserve Compute Resources for System Daemons。
当 cluster.yml 文件配置完成后,能够经过命令rke up
完成集群的部署任务。下图展现了经过 RKE 部署的 k8s 集群架构图。
该架构有以下特色:
always
。这样当他们出现故障意外退出后,能被自动拉起。/opt/rke/etcd-snapshots
中。在完成了集群部署后,能够经过 API server 访问 k8s。因为环境中启动了多个 kube-apiserver 实例以实现高可用,须要为这些实例架设一个负载均衡器。这里在192.168.0.10
上部署了一台 nginx 实现了负载均衡的功能,nginx.conf 的具体配置以下。
... stream { upstream apiserver { server 192.168.0.11:6443 weight=5 max_fails=3 fail_timeout=60s; server 192.168.0.12:6443 weight=5 max_fails=3 fail_timeout=60s; server 192.168.0.13:6443 weight=5 max_fails=3 fail_timeout=60s; } server { listen 6443; proxy_connect_timeout 1s; proxy_timeout 10s; proxy_pass apiserver; } } ...
这时,经过负载均衡器提供的端口访问 API server 会出现异常Unable to connect to the server: x509: certificate is valid for xxx, not 192.168.0.10
。这里须要将负载均衡器的 IP 地址或域名加入到 API server 的 PKI 证书中,能够经过 cluster.yml 中的 authentication 配置项完成此功能。
authentication: strategy: x509 sans: - "192.168.0.10"
修改完 cluster.yml 后,运行命令rke cert-rotate
。
在完成上述全部步骤后,能够经过命令kubectl get nodes
查看节点状态。若是全部节点的状态均为 Ready,则表示集群部署成功。
NAME STATUS ROLES AGE VERSION 192.168.0.11 Ready controlplane,etcd 1d v1.13.5 192.168.0.12 Ready controlplane,etcd 1d v1.13.5 192.168.0.13 Ready controlplane,etcd 1d v1.13.5 192.168.0.14 Ready worker 1d v1.13.5 192.168.0.15 Ready worker 1d v1.13.5 192.168.0.16 Ready worker 1d v1.13.5 192.168.0.17 Ready worker 1d v1.13.5
Rancher Kubernetes Engine(RKE)为用户屏蔽了建立 k8s 集群的复杂细节,简化了部署步骤,下降了构建门槛。对于那些有自建 k8s 集群需求的企业是一个不错的选择。
本文为云栖社区原创内容,未经容许不得转载。