简介容器编排技术是现代云原生应用部署的基石其核心原理是通过声明式配置自动化管理应用容器的生命周期、网络与存储。Kubernetes作为主流编排平台其高可用部署是保障服务稳定性的关键技术。针对国内网络环境拉取海外镜像困难这一普遍痛点结合Docker容器化带来的环境一致性优势本文深入解析了如何利用预先准备的离线资源包通过Kubespray这一基于Ansible的声明式工具高效、稳定地部署一套生产级高可用Kubernetes集群。方案涵盖了从资源包结构解析、负载均衡器配置到全离线环境下的镜像管理与集群初始化为运维工程师和DevOps实践者提供了一套清晰、可复现的工程实践路径。1. 项目缘起与核心价值最近在帮一个初创团队搭建内部开发测试环境他们需要一个稳定、可复现的Kubernetes集群。需求很明确要能快速拉起、支持多节点高可用、并且最好能适应国内网络环境。市面上部署K8S的工具不少kubeadm、RKE2、K3s各有千秋但考虑到团队后续有向生产环境演进的可能以及需要更精细化的控制我最终把目光投向了Kubespray。为什么是Kubespray简单说它不是一个“一键安装”的黑盒而是一个基于Ansible的、声明式的集群生命周期管理工具。它把K8S的各个组件etcd、kube-apiserver、controller-manager、scheduler等的部署、配置、升级都做成了可编排的剧本Playbook。这意味着你不仅能用它把集群搭起来还能清晰地知道每一个组件是怎么被配置和启动的出了问题也知道从哪个Ansible任务开始排查。这对于想深入理解K8S架构或者需要在特定网络环境下比如我们面临的国内网络进行定制化部署的团队来说价值巨大。然而Kubespray的官方文档和默认配置是针对全球互联网优化的直接在国内使用最大的拦路虎就是镜像拉取。无论是Docker Hub上的基础镜像还是gcr.io、k8s.gcr.io上的核心组件镜像拉取失败或速度极慢是常态。因此一个预先处理好所有依赖的“部署资源包”就成了破局的关键。这个资源包的核心任务就是把部署过程中所需的所有二进制文件、容器镜像、系统依赖包全部提前下载到本地形成一个离线的、完整的部署物料库。这样整个部署过程就完全与海外网络隔离速度和质量都有了保障。本文要分享的就是如何基于Docker容器化的环境利用这样一个定制化的Kubespray资源包一步步部署出一个高可用的K8S集群。我会重点拆解资源包的内部结构、Docker作为部署载体的优势、以及在整个流程中需要特别注意的坑点和调优技巧。无论你是运维工程师、DevOps实践者还是单纯想在自己机器上搞个稳定K8S玩玩的开发者这套方案都能给你提供一个清晰、可落地的参考。2. 部署方案全景与核心组件解析在深入实操之前我们必须先理解这个“基于Docker的Kubespray资源包部署方案”的全貌。它不是一个单一工具而是一个由多个层次组成的协作体系。理解每一层的职责是后续顺利操作和排错的基础。2.1 方案架构分层整个方案可以自底向上分为四层基础设施层这是我们的硬件或云主机资源。至少需要三台或更多奇数台如3、5、7满足基本配置的Linux服务器CentOS 7.9/Ubuntu 20.04作为K8S的节点。它们之间需要网络互通并且建议关闭Swap、设置正确的主机名和hosts解析。容器运行时层这是Kubespray默认且强依赖的一层。虽然Kubespray也支持containerd但Docker仍然是目前最成熟、兼容性最广的选择。注意这里说的Docker指的是在每个K8S节点包括Master和Worker上安装的Docker引擎用于运行Pod内的容器。它由Kubespray的Ansible剧本自动安装和配置。部署控制层这是本方案的核心创新点。我们不直接在宿主机上安装Ansible和Python依赖而是将所有部署工具Kubespray代码、Ansible、Python及相关模块封装在一个Docker镜像中。我们只需要在一台“部署机”可以是笔记本也可以是其中一台集群节点上运行这个容器容器内部就具备了完整的部署能力。这样做的好处是环境绝对一致、依赖隔离、一键清理彻底解决了“在我机器上好好的”这类环境问题。资源供给层这就是标题中提到的“部署资源包”。它是一个预先准备好的目录或压缩包里面包含了Kubespray项目代码特定版本的Kubespray如release-2.23。离线镜像仓库Registry数据使用docker save或skopeo等工具导出的所有必需容器镜像如kube-apiserver:v1.28.5,calico/node:v3.26.3,nginx-ingress-controller等并可能包含一个轻量级registry镜像如registry:2用于在集群内部搭建临时仓库。离线二进制文件与依赖包包括kubelet,kubectl,kubeadm虽然Kubespray不用它部署但会安装cni-plugins以及针对不同Linux发行版的系统依赖包如ebtables,socat,conntrack等的本地缓存。预配置的清单文件根据目标集群规划IP、主机名、角色预先修改好的inventory.ini或inventory.yaml文件。这四层的关系是我们在“部署机”上启动“部署控制层”的Docker容器该容器挂载“资源供给层”的本地目录然后通过SSH连接到“基础设施层”的各个节点在这些节点上安装配置“容器运行时层”Docker最后将资源包中的镜像和文件分发到各个节点完成K8S集群的部署。2.2 为何选择Docker作为部署载体很多教程会教你在部署机上用pip安装Ansible和依赖。这听起来简单实则暗坑无数Python版本冲突、Ansible版本不兼容、系统库缺失等等。使用Docker容器化部署控制环境优势非常明显环境一致性镜像里固定了Ansible、Python、Kubespray的版本在任何能运行Docker的机器上表现完全一致。零污染部署完成后直接删除容器即可不会在宿主机留下任何Python包或配置文件。快速重置如果部署过程中配置出错想从头再来直接删掉容器重新运行一个全新的即可基础环境瞬间重置。便于分享将部署镜像和资源包打包整个团队可以复用同一套部署工具极大降低了新人上手成本。2.3 高可用HA架构的实现方式Kubespray支持多种高可用模式对于生产级集群我们通常选择“负载均衡器”模式。这意味着你需要为kube-apiserver准备一个负载均衡器可以是硬件的F5、软件的HAProxyKeepalived或者云厂商的LB服务。负载均衡器后端指向所有Master节点的6443端口。在资源包的配置中你需要在inventory.yaml文件中明确指定apiserver_loadbalancer_domain_name或IP和loadbalancer_apiserver的地址。Kubespray在部署时会引导各个节点包括Worker的kubelet和kube-proxy通过这个负载均衡器地址来访问API Server从而实现Master节点故障时的无缝切换。如果只是测试环境Kubespray也提供了“本地负载均衡”模式它会在每个非Master节点上部署一个nginx或haproxy实例作为本地代理但这会增加节点配置的复杂性。对于我们的“方案一”建议即使是测试环境也使用一个独立的、简单的HAProxy实例作为负载均衡器这样更接近生产架构。3. 部署资源包的内部解剖与准备“资源包”是这个离线部署方案的灵魂。一个准备充分的资源包能让后续部署过程如行云流水。我们来彻底拆解它应该包含什么以及如何准备。3.1 资源包目录结构示例一个典型的、组织良好的资源包目录树可能如下所示kubespray-offline-package-v2.23-k8s-v1.28.5/ ├── kubespray/ # Kubespray项目代码目录 │ ├── ansible.cfg │ ├── cluster.yml │ ├── inventory/ # 存放库存文件 │ │ └── my-cluster/ │ │ ├── group_vars/ │ │ │ ├── all/all.yml │ │ │ ├── k8s_cluster/k8s-cluster.yml │ │ │ └── ... │ │ └── inventory.yaml # **核心集群节点清单** │ ├── roles/ │ └── ... ├── artifacts/ # 所有离线物料 │ ├── images/ # 容器镜像归档文件 │ │ ├── kube-apiserver_v1.28.5.tar │ │ ├── calico_node_v3.26.3.tar │ │ ├── registry_2.tar # 用于搭建本地仓库的registry镜像 │ │ └── ... (所有其他镜像) │ ├── binaries/ # 二进制文件 │ │ ├── kubernetes/ │ │ │ ├── kubelet-v1.28.5 │ │ │ ├── kubectl-v1.28.5 │ │ │ └── ... │ │ ├── cni/ │ │ │ └── cni-plugins-linux-amd64-v1.3.0.tgz │ │ └── docker/ │ │ └── docker-24.0.7.tgz # 可选Kubespray通常从repo安装 │ └── packages/ # 系统依赖包缓存 (针对不同OS) │ ├── centos-7/ │ │ └── x86_64/ # 存放.rpm包 │ └── ubuntu-20.04/ │ └── amd64/ # 存放.deb包 ├── scripts/ # 辅助脚本 │ ├── load-images.sh # 将镜像导入到本地Docker并推送到私有仓库 │ ├── deploy-haproxy.sh # 部署负载均衡器的脚本如需 │ └── generate-inventory.py # 根据节点信息生成inventory的脚本 └── README.md # 部署说明文档3.2 关键文件详解与配置要点1.inventory/my-cluster/inventory.yaml这是部署的蓝图必须根据你的实际环境精确修改。一个高可用集群的示例all: hosts: master-01: ansible_host: 192.168.1.101 ip: 192.168.1.101 access_ip: 192.168.1.101 master-02: ansible_host: 192.168.1.102 ip: 192.168.1.102 access_ip: 192.168.1.102 master-03: ansible_host: 192.168.1.103 ip: 192.168.1.103 access_ip: 192.168.1.103 worker-01: ansible_host: 192.168.1.201 ip: 192.168.1.201 access_ip: 192.168.1.201 worker-02: ansible_host: 192.168.1.202 ip: 192.168.1.202 access_ip: 192.168.1.202 children: kube_control_plane: hosts: master-01: master-02: master-03: kube_node: hosts: worker-01: worker-02: etcd: hosts: master-01: master-02: master-03: k8s_cluster: children: kube_control_plane: kube_node: calico_rr: hosts: {} vars: ansible_user: root # 或一个拥有sudo权限的用户 ansible_ssh_private_key_file: /kubespray/inventory/my-cluster/ssh_key # 容器内路径 # 高可用负载均衡器配置 apiserver_loadbalancer_domain_name: lb.k8s.local loadbalancer_apiserver: address: 192.168.1.100 # 你的负载均衡器VIP或域名 port: 6443 # 容器运行时 container_manager: docker # 网络插件 kube_network_plugin: calico # 关键配置使用本地仓库 gcr_image_repo: 192.168.1.10:5000 # 你的私有仓库地址 kube_image_repo: {{ gcr_image_repo }} docker_image_repo: {{ gcr_image_repo }} quay_image_repo: {{ gcr_image_repo }} # 禁止在线下载 skip_downloads: true注意ansible_ssh_private_key_file指向的是容器内的路径。你需要将你的SSH私钥文件也放入资源包并在运行容器时挂载进去。2.group_vars/k8s_cluster/k8s-cluster.yml这个文件用于定义K8S集群级别的参数。需要重点关注以下配置# 使用本地仓库拉取镜像 kubeadm_download_url: file:///kubespray/artifacts/binaries/kubernetes/{{ kubeadm_full_version }}.tar.gz kubelet_download_url: file:///kubespray/artifacts/binaries/kubernetes/{{ kubelet_full_version }}.tar.gz kubectl_download_url: file:///kubespray/artifacts/binaries/kubernetes/{{ kubectl_full_version }}.tar.gz cni_download_url: file:///kubespray/artifacts/binaries/cni/cni-plugins-linux-amd64-{{ cni_version }}.tgz # 定义镜像仓库指向我们即将搭建的本地仓库 docker_registry_mirrors: [] kubelet_image_repository: {{ gcr_image_repo }}3.artifacts/images/下的镜像准备这是最繁琐但最重要的一步。你需要在一个能访问外网的环境中使用Kubespray的contrib/offline目录下的脚本或者手动根据roles/download/defaults/main.yml中的镜像列表将所有镜像pull下来然后docker save成tar包。一个更高效的方法是使用Kubespray容器本身来准备# 1. 在一个有网的环境运行Kubespray工具容器 docker run --rm -it \ -v $(pwd)/kubespray-offline:/kubespray \ -v $(pwd)/inventory:/kubespray/inventory \ quay.io/kubespray/kubespray:v2.23.1 bash # 2. 在容器内运行下载任务这会下载所有文件到 /kubespray/{artifacts,extra} 下 ansible-playbook -i /kubespray/inventory/my-cluster/inventory.yaml \ --tags download \ --skip-tags upload,upgrade \ cluster.yml运行后检查/kubespray目录下生成的artifacts文件夹里面就包含了所有离线需要的镜像tar包和二进制文件。将其复制出来就构成了资源包的artifacts核心部分。4. 实战部署从零到高可用集群假设你已经准备好了上述资源包并且有三台干净的CentOS 7.9服务器192.168.1.101-103作为Master192.168.1.201-202作为Worker一台部署机192.168.1.10以及一个负载均衡器VIP192.168.1.100。下面开始一步步操作。4.1 前置检查与负载均衡器搭建在运行Kubespray之前必须确保基础设施就绪。在所有K8S节点101-103, 201-202上执行主机名与Hosts设置永久主机名如hostnamectl set-hostname master-01并在/etc/hosts中确保所有节点能通过主机名和IP互相解析。防火墙与SELinux关闭防火墙systemctl stop firewalld; systemctl disable firewalld或放行必要端口6443, 2379-2380, 10250, 10259, 10257等。将SELinux设置为permissive模式setenforce 0并修改/etc/selinux/config。Swap彻底关闭Swapswapoff -a并注释掉/etc/fstab中的swap行。内核参数加载必要模块br_netfilter, ip_vs等并设置sysctl参数net.bridge.bridge-nf-call-iptables1等。Kubespray的剧本会做这些但提前做好可避免意外。SSH互信在部署机10上生成SSH密钥对并将公钥分发到所有节点。这是Ansible工作的基础。搭建负载均衡器以HAProxy Keepalived为例部署在独立的机器或其中一个Master上这里以在192.168.1.10部署机上同时部署HAProxy和Keepalived为例提供一个简易配置。HAProxy配置 (/etc/haproxy/haproxy.cfg):global log /dev/log local0 maxconn 20000 user haproxy group haproxy defaults log global mode tcp timeout connect 5s timeout client 50s timeout server 50s frontend k8s-api bind 192.168.1.100:6443 default_backend k8s-api-servers backend k8s-api-servers balance roundrobin server master-01 192.168.1.101:6443 check server master-02 192.168.1.102:6443 check server master-03 192.168.1.103:6443 checkKeepalived配置 (/etc/keepalived/keepalived.conf):vrrp_instance VI_1 { state MASTER # 在其他备用节点上设为BACKUP interface eth0 # 你的网卡名 virtual_router_id 51 priority 100 # 备用节点设为更低值如90 advert_int 1 authentication { auth_type PASS auth_pass your_password } virtual_ipaddress { 192.168.1.100/24 dev eth0 } }启动服务systemctl start haproxy keepalived systemctl enable haproxy keepalived。现在VIP 192.168.1.100:6443应该已经指向三个Master的API Server。4.2 启动部署控制容器并导入资源在部署机192.168.1.10上确保Docker服务已启动。将准备好的资源包目录例如kubespray-offline-package上传到部署机。# 1. 进入资源包目录 cd /path/to/kubespray-offline-package # 2. 启动Kubespray部署容器 # 我们使用官方镜像并将资源包整个目录挂载到容器的 /kubespray 下 # 同时挂载SSH私钥和可能的自定义证书 docker run --rm -it \ --name kubespray-deployer \ -v $(pwd):/kubespray \ # 挂载整个资源包 -v /path/to/your/ssh_private_key:/kubespray/inventory/my-cluster/ssh_key:ro \ -v /etc/localtime:/etc/localtime:ro \ quay.io/kubespray/kubespray:v2.23.1 bash现在你进入了容器内部工作目录/kubespray下就是你准备好的所有物料。在容器内首先需要将离线镜像导入到本地Docker引擎并推送到一个私有仓库如果配置了的话。通常Kubespray支持两种离线模式模式A使用本地Docker镜像存档。Kubespray的docker角色可以直接从docker load导入的镜像运行。这要求每个节点都能访问到这些镜像tar包。你需要先将artifacts/images/*.tar文件分发到各个节点然后手动docker load或者编写一个Ansible任务来做这件事。模式B搭建内部私有仓库。这是更清晰、更接近生产实践的做法。我们在集群内部可以是一个临时容器启动一个Docker Registry将所有镜像推送到这个仓库然后在inventory.yaml中配置所有镜像从这个仓库拉取。这里演示模式B因为它更通用# 在容器内操作 cd /kubespray # 1. 启动一个临时的本地registry容器使用资源包里的镜像 docker load -i artifacts/images/registry_2.tar docker run -d -p 5000:5000 --name local-registry registry:2 # 2. 导入所有镜像并推送到本地仓库 for img_tar in artifacts/images/*.tar; do docker load -i $img_tar done # 重新给镜像打上本地仓库的tag并推送 # 例如假设我们的仓库地址是 192.168.1.10:5000 docker images | grep -v REPOSITORY | awk {print $1:$2} | while read image; do new_image192.168.1.10:5000/$(echo $image | cut -d/ -f2-) docker tag $image $new_image docker push $new_image done注意上述打tag的脚本比较简单假设原始镜像都是类似k8s.gcr.io/kube-apiserver:v1.28.5的格式。实际情况可能更复杂你可能需要根据镜像原始仓库名做更精细的处理。更好的方法是使用skopeo copy命令。4.3 执行Ansible部署剧本确保inventory/my-cluster/inventory.yaml中的gcr_image_repo等变量已正确设置为你的本地仓库地址如192.168.1.10:5000。现在开始正式的集群部署。Kubespray的部署是分阶段的建议先运行一个“事实收集”和“预检”任务# 在容器内/kubespray目录下 # 1. 测试Ansible连接 ansible -i inventory/my-cluster/inventory.yaml all -m ping # 2. 运行集群部署主剧本 # 使用 --skip-tags download 因为我们已离线 ansible-playbook -i inventory/my-cluster/inventory.yaml \ --private-key /kubespray/inventory/my-cluster/ssh_key \ --become --become-userroot \ --skip-tags download \ cluster.yml这个cluster.yml剧本会执行所有任务安装Docker、配置系统、部署etcd集群、部署K8S控制平面组件、部署网络插件Calico、部署CoreDNS、加入Worker节点等等。整个过程视网络和节点性能可能需要20分钟到1小时。关键观察点播放Playkubernetes/preinstall检查系统配置失败通常是因为前置检查未通过。播放container-engine/docker在所有节点安装Docker。播放etcd部署etcd集群这是高可用的基础确保3个节点都成功。播放kubernetes/control-plane部署kube-apiserver, controller-manager, scheduler。观察负载均衡器VIP是否被正确使用。播放network_plugin/calico部署Calico网络。完成后节点状态应变为Ready。4.4 部署后验证与配置剧本运行成功后我们需要进行验证。# 在任意Master节点如master-01上操作 # 1. 复制admin.conf到本地如果你在部署机上操作需要从容器或Master节点拷出来 # 在容器内这个文件通常生成在 /etc/kubernetes/admin.conf但会被Ansible复制到某个位置。 # 查看 inventory.yaml 中 kubeconfig_localhost: true 变量如果为真kubeconfig会生成在部署机容器内的当前目录。 # 我们假设它生成了。 # 2. 设置KUBECONFIG环境变量 export KUBECONFIG/kubespray/artifacts/cluster-config/admin.conf # 3. 使用kubectl检查集群状态 kubectl get nodes -o wide # 所有节点状态应为 Ready kubectl get pods -n kube-system -o wide # 检查核心组件coredns, calico, kube-proxy等是否全部Running kubectl get svc -n default # 检查是否有kubernetes服务 # 4. 测试集群网络 kubectl run busybox --image192.168.1.10:5000/busybox:1.35 --restartNever -- sleep 3600 kubectl exec busybox -- nslookup kubernetes.default.svc.cluster.local # 应能解析出Cluster IP高可用测试手动关闭一个Master节点如master-02的kube-apiserver进程或直接关机。然后从Worker节点或通过VIP继续执行kubectl get nodes命令应该依然能成功执行可能会有短暂超时证明负载均衡器将请求转发到了其他健康的Master节点。5. 深度排错与经验总结即使按照剧本一步步走在实际部署中依然会遇到各种问题。这里分享几个最常见的坑和排查思路。5.1 镜像拉取失败问题根因与解决这是离线部署中最常见的问题表象是Pod一直处于ImagePullBackOff或ErrImagePull状态。排查步骤kubectl describe pod pod-name -n namespace查看事件确认是哪个镜像拉取失败。kubectl get pods -n kube-system检查calico-node,coredns等系统Pod的状态。登录到对应节点执行docker images | grep image-name确认镜像是否已正确加载到本地。如果使用私有仓库在节点上执行docker pull your-registry/image:tag看是否能成功。检查节点Docker的daemon.json确认insecure-registries是否包含了你的私有仓库地址Kubespray通常会配置这个。根本原因与解决原因Ainventory.yaml中的*_image_repo变量未正确修改组件还在尝试从k8s.gcr.io拉取。解决确保gcr_image_repo,kube_image_repo,docker_image_repo,quay_image_repo全部指向你的本地仓库地址。并重新运行相关的Ansible标签如ansible-playbook ... --tags docker,network。原因B私有仓库未配置为不安全仓库节点Docker无法通过HTTP访问。解决Kubespray的roles/container-engine/docker任务会处理这个。检查group_vars/all/docker.yml中docker_insecure_registries列表是否包含你的仓库IP:PORT。然后重新运行--tags docker。原因C镜像Tag不匹配。Kubespray配置的镜像版本与你实际导入的版本不一致。解决核对roles/download/defaults/main.yml或group_vars/k8s_cluster/k8s-cluster.yml中定义的镜像版本如calico_version,coredns_version确保与你下载的tar包版本一致。5.2 节点NotReady网络插件与系统配置节点状态卡在NotReady通常是CNI插件如Calico未能成功初始化。排查步骤kubectl describe node node-name查看节点事件常见错误是network plugin is not ready。journalctl -u kubelet -f在问题节点上查看kubelet日志寻找与CNI相关的错误。docker ps | grep calico检查Calico相关容器是否在运行。ip route或route -n检查节点路由表Calico通常会添加路由条目。常见原因内核模块或IP转发未开启虽然Kubespray剧本会设置net.ipv4.ip_forward1但有时可能不生效。手动检查sysctl net.ipv4.ip_forward和net.bridge.bridge-nf-call-iptables。防火墙干扰特别是firewalld或iptables规则阻止了Calico的VXLAN或BGP流量默认为TCP 179, UDP 4789。在测试环境彻底关闭防火墙是最简单的选择。网卡选择错误Calico默认可能选择了错误的物理网卡如选择了docker0网桥。需要检查group_vars/k8s_cluster/k8s-cluster.yml中的calico_interface变量可以设置为interfaceeth.*或具体的IP地址。5.3 Ansible任务失败针对性重跑与调试某个Ansible任务失败如“安装docker失败”不要急于重跑整个cluster.yml。策略查看详细错误Ansible输出会显示失败的任务名和错误信息。仔细阅读通常是依赖包缺失、网络超时虽然离线但可能涉及系统包仓库、或配置文件错误。使用--tags和--start-at-task这是Ansible排错的神器。例如如果TASK [container-engine/docker : ensure docker packages are installed]失败你可以修复问题后仅重跑这个任务所在的角色ansible-playbook -i inventory.yaml --tags docker --start-at-taskensure docker packages are installed cluster.yml检查变量覆盖有时在group_vars或inventory中设置的变量可能被角色内的默认值或其它变量覆盖。使用ansible-playbook ... --extra-vars debug_varvalue可以临时覆盖测试。手动在目标节点执行登录到出错的节点尝试手动执行失败命令如yum install docker-ce -y看具体报错这往往能最快定位到系统级问题如磁盘满、yum源配置错误。5.4 个人实操心得与建议资源包版本锁定务必保持Kubespray版本、Kubernetes版本、镜像版本、二进制版本在资源包内绝对一致。每次更新任何一个组件最好重新生成完整的资源包。使用版本控制将inventory/my-cluster目录和修改过的group_vars文件纳入Git管理。这样集群的配置即代码可以追溯和回滚。分阶段部署对于生产环境不要一次性跑完cluster.yml。可以先运行--tags preinstall和--tags docker确保所有节点基础环境OK。再运行--tags etcd部署etcd集群验证其健康度。最后再部署控制平面和网络。分阶段跑更容易隔离问题。预留系统资源Master节点特别是etcd对磁盘IO和网络延迟非常敏感。确保使用SSD磁盘并避免etcd与其它IO密集型服务混部。给kube-apiserver预留足够内存至少2G。备份admin.conf部署成功后生成的admin.conf文件至关重要它包含了访问集群的证书和密钥。务必安全备份。你可以使用kubectl config view --flatten config命令生成一个包含所有上下文的配置文件方便在多集群间切换。这套基于Docker和定制资源包的Kubespray部署方案虽然前期准备资源包稍显繁琐但它换来的是部署过程的高度可重复性、环境的一致性和对国内网络环境的彻底免疫。一旦资源包就绪部署一个新的高可用集群就变成了一个小时内可完成的标准化操作。对于需要频繁搭建测试环境、或为交付项目构建标准化基础设施的团队来说这份前期投入是非常值得的。本文还有配套的精品资源点击获取