kubespray离线创建kubernetes并与portal集成管理
source link: https://mp.weixin.qq.com/s?__biz=MzIwNDkwMjc1OQ%3D%3D&%3Bmid=2247484729&%3Bidx=1&%3Bsn=d4941b3be1e4fa0969752a7d14bc51fc
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
请点击上方 “民生运维人” 添加订阅！
一
引言
Kubernetes部署除了常规手动方式外，还有诸如Kubeadm、Kops、Breeze、Rancher、kubespray（原名为kargo）等多种自动化方式。那为什么选择kubespray部署kubernetes会更好呢？我们首先对比一下他们优缺点:
-
kubeadm
官方推荐方案，部署简单，包含init和join两个命令，成熟度不高，小问题比较多，比如修改K8SMaster节点IP后使用kubeadmjoin无法添加节点，比如很多系统参数需要手动修改等，还有部署完定位问题仅限几个docker命令等。2018年底才发布支持ha部署稳定版，老的版本只安装kubernetes组件。一些子功能，比如自托管或者配置文件 API 还在开发过程当中。由于kubeadm更像是一套完整的脚本封装，整个命令行都是通过 cobra 库构建的。所以想要扩展它、定制化开发或者延长证书，还是需要配合其它的方案一起做。
-
kops
kops是非常早就存在的一个项目，也是目前最靠谱的部署方案，目前Kops支持的操作系统主要有：Debian（默认），CoreOS，CentOS，而国际区默认的系统镜像“debian-jessie-amd64-hvm”在中国区并没有。那么要么从国际区搬一个回来，要么使用CoreOS。但是由于与各云平台整合度非常高，所以也不是很推荐。而且DNS和以来的文件下载都来源于国外指定地址，而且是专用于AWS的。所以这里不是很推荐。
-
Rancher
Rancher是一个开源的企业级容器管理平台，加入开源社区比较晚，通过 web 界面赋予完全的 docker 服务编排功能。他比较像paas层面的东西，相当在k8s上开发了一个界面管理调度容器，比较适合私有云测试。平台扩展方便，内置应用商店，支持独立编排，自带账户权限，跟k8s相比，Racher管理容器是以stack为一个任务组，且没有kubectl管理节点的多种功能。但是之前出现过LB单点的极端情况，社区贡献应用商店的应用有限。Racher数据库数据内置。缺点是如果容器损坏了，数据就不可恢复。
-
kubespray
本人最推荐的方案，集成度很高，flannel等网路信息都在etcd中有存储，不像rancher的rancherDNS存储在内存中，升级方便。可以自行扩展添加功能，支持多种插件选择。kubespray是一个基于Ansible的部署方案，操作系统支持绝大部分基于systemd的系统，什么ContainerLinux/Debian/Ubuntu/CentOS/RHEL/Fedora/CentOS Atomic/openSUSE 支持绝大部分的云平台，也支持OpenStack，vSphere等虚拟化方案。
kubespray也为我们准备好了高可用方案，支持绝大部分网络插件，DNS也支持很多类型，你可以根据自己的需要选择。
Github和官方文档上，目前也很完整。国内如果想要部署，简单修改一下部署配置，声明替换国外一些必要组件的镜像地址为本地下载docker load的镜像版本后，就可以一键部署安装了。
下面通过导图先简单描绘kubespray自动部署k8s集群的三大步骤图（三个椭圆），与portal集成图形化联动管理部分并不是此次配置所必须的，请知晓。作者技能有限，仅从实施过程中获取总结出了一些关键易错的步骤，仅供学习。
二
实战
1
第一部分：kubesprary自动部署集群
获取安装包有几种常见方式，一种是下载github(https://github.com/kubernetes-sigs/kubespray/releases)或者git clone命令(git clone https://github.com/kubernetes-incubator/kubespray.git)下载。
然后手动在一台配置了docker proxy的能连通外网的机器上pull官方镜像，Suse需要安装docker ee企业版，需要设置 Docker 镜像仓库，通过以下命令进行设置。
zypper addrepo https://storebits.docker.com/ee/trial/sub-b45c078b-5786-4a07-a328-0a8773c01f3d/sles/12.3/x86_64/stable-17.06 docker-ee-stable
导入rpm gpg校验key：
rpm--import https://storebits.docker.com/ee/trial/sub-b45c078b-5786-4a07-a328-0a8773c01f3d/sles/gpg
安装完docker后，可以通过打上tag命令后push到本地的DTR镜像仓库。Kubespray默认部署calico比较复杂，本文阐述相对简单flannel的部署（还支持其他的canal, weave网络插件部署）。
以下docker镜像（三种国外原始镜像源k8s.gcr.io、quay.io、docker.io均可尝试）上传到本地镜像仓库（其中五个k8s核心重要组件尽量下载二进制文件，后面章节会提到），通过docker pull命令下载其他本地安装必备介质：
k8s.gcr.io/cluster-proportional-autoscaler-amd64:1.3.0
k8s.gcr.io/pause-amd64:3.1
k8s.gcr.io/etcd:3.2.24
nginx:1.13
k8s.gcr.io/kubernetes-dashboard-amd64:v1.10.0
k8s.gcr.io/coredns:1.2.6
k8s.gcr.io/k8s-dns-node-cache:1.12.7
quay.io/coreos/flannel:v0.10.0-amd64
quay.io/coreos/flannel-cni:v0.3.0
-
kubernetes的整体架构如下：
-
一、master节点主要包含三大组件：
1. apiserver 提供资源操作的唯一入口，并提供认证，授权，访问控制API注册和发现等机制
2. scheduler 负责资源的调度，按照预定的调度策略将POD调度到相应节点上
3. controller 负责维护集群的状态，如故障检测，自动扩展，滚动更新等
-
二、node节点主要包含
1.kubelet 维护容器的声明周期，同时也负载挂载和网络管理
2.kube-proxy 负责为service提供cluster内部服务的服务发现和负载均衡
-
三、 其他核心组件
1. etcd 保存整个集群状态
2. flannel 为集群提供网络环境
-
四、 kubernetes核心插件
1. coreDNS 负责为整个集群提供DNS服务
2. ingress controller 为服务提供外网入口
3. promentheus 提供资源监控（目前行内用的zabbix监控）
4. dashboard 提供GUI
-
系统规划：
所有的主机都需要关闭selinux，执行的命令如下：
setenforce 0
sed-i--follow-symlinks 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/sysconfig/selinux
所有主机也要关闭防火墙：
systemctl stop SuSEfirewall2.service
systemctl stop SuSEfirewall2_init.service
systemctl disable SuSEfirewall2.service
systemctldisable SuSEfirewall2_init.service
iptables ipv4转发需开启：
sysctl -w net.ipv4.ip_forward=1
sysctl -p
关闭所有节点swap
swapoff -a
安装前依赖包的问题，启动kubespray需要很多系统必备依赖包，其中最容易遗漏socat安装包。
fatal: [NODE9]: FAILED! => {"attempts": 4, "changed": false, "cmd": ["/usr/bin/zypper", "--quiet", "--non-interactive", "--xmlout", "install", "--type", "package", "--auto-agree-with-licenses", "--no-recommends", "--", "+device-mapper", "+ebtables", "+openssl", "+curl", "+rsync", "+socat", "+unzip", "+e2fsprogs", "+xfsprogs"], "msg": "Zypper run command failed with return code 8.", "rc": 8, "stderr": "", "stdout": There are no incompatibility issues.\n<solvable type=\"package\" name=\"socat\" edition=\"1.7.2.4-3.1\" arch=\"x86_64\" summary=\"
-
软件版本
kubernetes：1.14
kubesprary：v2.10.4
Docker：17.06 Enterprise Edition
Operating System：SuSE Linux Enterprise Server 12 SP3
github下载好kubesprary后，开始安装setuptools，然后再安装pip组件，根据requirement.txt列表解决安装依赖包，安装相关联的前置组件，这个也可以通过外网机提前下载好，我这边是提前批量传好，其中python2下需要安装如下组件：
Python3需要安装如下组件，这里需要修改/usr/bin/pip首行python指向python3可执行命令：
安装后检查ansible版本，如输出有版本信息，说明安装成功。
ansible --version
-
安装docker ee
按照行内标准来安装，然后安装python-httplib2。
-
配置SSH互信
deploy-server⽣成ssh秘钥对ssh-keygen，通过ssh-copy-id命令就可以完成公钥deploy-server的公钥id_rsa.pub拷贝。记得首次需要从deploy-server完成一次到所有节点的ssh免密登录。
首先，进入inventory目录下，同级复制sample为mycluster目录，，编辑初始化的主机列表：其中ansible_host和ip填实际ip，ip为同网段可通的，默认安装calico，但本次部署较为简单的flannel网络组件，故calico-rr路由反射不配置，vault为集群证书管理功能，一般为master节点。
-
初始化Inventory⽂件
declare -a IPS=(5台主机IP，每个IP之间空格隔开)
CONFIG_FILE=inventory/mycluster/hosts.ini HOST_PREFIX=NODE python3
contrib/inventory_builder/inventory.py ${IPS[@]}
其次替换如下必备组件，图1是必须修改的本地镜像库地址，务必要修改正确，否则可能造成部署报错，其中图2、3重要信息为nginx版本和kube_version、etcd version、flannel_cni、coredns版本要对应正确：
然后确保main.yaml配置文件中对应的二进制256位校验对应版本的值要一样，可以通过sha256sum校验。
修改roles/kubespray-defaults/defaults目录下的main.yaml，修改enbale_network_policy为false，这样就会使用flannel默认安装。
然后编辑mycluster/group_vars/k8s-cluster/k8s-cluster.yml文件，再次确认部署的网络插件为flannel，另外需规划pod之间通讯的内网网段和service内网网段两个私网网段（其中如下显示service网段用到的组件）,修改kubeproxy为iptables:
将以下安装包下载后，在正式部署前上传⾄每个节点的/tmp/kubernetes-release,⽬录如果不存在，使⽤root⽤户创建即可。其中，hyperkube模块就是把各种功能集成到一个可执行文件，然后在运行时指定模块(2.12 kubespray版本已经开始废弃此功能，默认加了kubeadm_use_hyperkube_image: False默认指定)。cni-plugin会在指定的network ns中创建veth pair，kubeadm 是 kubernetes 的集群安装工具，其余组件已经在开篇用docker从外网镜像站下载并打包成tar包并导入到dtr中，下面不再罗列。
roles/containerengine/docker/vars/suse.yml编辑该文件，修改docker引擎为docker-ee。
在roles/kubernetes/preinstall/tasks/0020-verify-settings.yml中删除以下校验主机名必须小写的内容：
- name: Stop if bad hostname
assert:
that: inventory_hostname is match("[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]
([-a-z0-9]*[a-z0-9])?)*$")
msg: "Hostname must consist of lower case alphanumeric characters, '.' or '-
', and must start and end with an alphanumeric character"
ignore_errors: "{{ ignore_assert_errors }}"
默认部署主机名只会1~5自动生成，本文为6~10修改contrib/inventory_builder/inventory.py，找highest_host_id字段，后面+1改为+6。
登录内网已搭建好的dtr仓库，通过docker login输入密码登录到dtr仓库后，push镜像到其中，这里注意需要现在dtr中添加完对应名字的仓库根目录名后，push才会成功。
Push完点击镜像菜单，可以看到各个版本的镜像：
-
正式部署：
ansible-playbook -i inventory/mycluster/hosts.ini --become --become-user=root
cluster.yml
-
清除环境：
官⽅清除⼯具
#使⽤ansible⼯具reset环境
ansible-playbook -i inventory/mycluster/hosts.ini --become --become-user=root
reset.yml
确认是否还有容器正在运⾏，并且删除所有docker镜像（确保所有的docker镜像都是跟本次部署相关），卸载删除docker ee软件，删除systemd的相关⽂件：
rm -rf /etc/systemd/system/multi-user.target.wants/etcd.service
rm -rf /etc/systemd/system/multi-user.target.wants/kubelet.service
rm -rf /etc/systemd/system/docker.service*
systemctl daemon-reload
2
第二部分：集成portal管理
准备portal证书、集群证书，备份证书，并替换新portal证书实现节点纳管，修改dashboard对接节点详细信息控制。
-
证书工具下载和上传
所有master节点操作：
-
创建目录，并上传工具，并配置环境变量，创建证书分类目录：
mkdir -p /opt/cfssl/bin
将三个二进制可执行文件拷贝至/opt/cfssl/bin目录下
mv cfssl_linux-amd64 /opt/cfssl/bin/cfssl
mv cfssljson_linux-amd64 /opt/cfssl/bin/cfssljson
mv cfssl-certinfo_linux-amd64 /opt/cfssl/bin/cfssl-certinfo
chmod +x /opt/cfssl/bin/*
echo 'export PATH=$PATH:/opt/cfssl/bin' >> ~/.bashrc;source ~/.bashrc
mkdir -p /root/k8s-replace-cert
echo "export k8s_cert_dir=/root/k8s-replace-cert" >> ~/.bashrc;source ~/.bashrc
mkdir -vp $k8s_cert_dir/{CA/,apiserver/,apiserverkubelet/,
kubelet/{client,server},kubectl/,controller-manager/,scheduler}
master任一节点操作，创建master与两个worker节点的互信证书目录：
mkdir -vp $k8s_cert_dir/kubelet/NODE9/{client,server}
mkdir -vp $k8s_cert_dir/kubelet/NODE10/{client,server}
-
创建worker节点证书目录和配置环境变量：
mkdir -p /root/k8s-replace-cert
echo "export k8s_cert_dir=/root/k8s-replace-cert" >> ~/.bashrc;source ~/.bashrc
mkdir-vp $k8s_cert_dir/{CA/,kubelet/{client,server}}
-
Portal中创建新集群
首先登陆portal，点击添加kubernetes集群，这里需要填入如下必填项，集群名、API Server Endpoint（默认是三个集群vip的6443端口），dashboard endpoint（默认是三个集群vip的30443端口）。日志服务（logtail类似组件）和监控服务（zabbix、prometheus等）需要单独安装，此处这两个组件可以不先强制安装出来，随便填写个地址就好，docker版本通过docker version输出填入：
-
登录portal管理地址：
然后点击下载证书，会得到一个certFile.zip一个压缩包里，里面包含三个文件，ca.pem（集群根证书）、clientCA.pem（worker节点根证书，与服务端通信）、key.pem（集群私钥），把三个证书拷贝到/root/k8s-replace-cert/CA目录下:
查看根证书和client CA证书，用openssl X509格式解析：
-
创建ca-config配置文件
证书有效期为20年(175200h)
kubernetes-server profile用于server证书生成
kubernetes-client profile用于client证书生成
两种server auth和client auth证书配置文件制作：
-
两种证书前面三步通用步骤：
1.进入对应证书目录
2.创建csr json（这里server的kube-apiserver需要输入整个节点的主机名和ip信息，还有域名信息、kubelet-server的CN注意确保生成完date命令生效已转变为实际时间，且所有证书CN需要小写lowercase,（可以详见k8s中文说明））
3.通过cfssl gencert pem产生pem临时证书，包含私钥
-
server auth证书制作第四步骤：
4.通过openssl x509完成crt证书生成（不含私钥）和openssl rsa命令完成对应的私钥的重命名，并删除证书过渡pem文件（仅apiserver证书、kubelet server和client证书需要做这步）
-
client auth证书配置文件制作第四步骤：
4.通过kubectl config 4步命令产生配置文件，分别是set-cluster（需要用根证书ca.crt）、set-credentials、set-context设置上下文和use-context使用上下文产生conf文件。（其他三步证书都需要用pem类型的）
-
conf文件构成：
一共有3个kubelet.conf、scheduler.conf、controller-manager.conf,其构成确保有4段，分别为cluster（带有主机名和集群域名的证书信息）、contexts（带有集群域名标识）各一段和users两端客户端验证秘钥。
创建完成后，master证书根目录下每个节点各36个文件，worker证书个目录下每个节点各6个文件。
-
master证书创建
分别为apiserver server auth和client auth证书制作两步、apiserver-kubelet server auth和client auth证书制作两步、kubectl客户端admin证书配置文件生成一步、kube-controller-manager client auth一步、kube-scheduler client auth证书配置文件生成一步：
-
worker证书创建
分别为kubelet server auth和client auth证书制作两步（在master1节点上完成）。
上面讲述了制作两种类型的证书基本操作步骤，重要的是csr请求文件，csr分四种类型：
1.ca-config.json(ca证书请求文件创建，用于派生其他关联证书,前面已列举)
2.apiserver(apiserver-csr.json)
黑色省去了主机三个master节点对应的ip，其中0.1地址为内部通讯的service ip
3.kube-scheduler-csr.json、kube-controller-manager-csr.json、kubelet-server-csr.json（带有主机名和时间标识）
4.带有O和OU标识的，有admin-csr.json、kubelet-client-csr.json
-
证书备份
cp -r /etc/kubernetes /etc/kubernetes-bak
cp -r /var/lib/kubelet/pki /var/lib/kubelet/pki-bak
备份好所有的文件后，就可以开始拷贝server证书到对应的/etc/kubernetes/ssl目录下了，这里必须是/etc/kubernetes的子目录：
worker节点证书制作，只有两步，分别为kubelet的server auth和client auth这里统一在master1节点操作：
-
创建apiserver-ca.crt文件
该文件共有三段client CA证书:
1.集群CA证书
2.集群client CA证书---容器平台用户使用portal生成的kubeconfig访问apiserver
3.portal所在集群CA证书---容器平台用户使用portal本身访问apiserver
#登录portal根证书节点，拷贝portal CA证书至三个master节点
scp portal-ca.pem NODE6:/root/k8s-replace-cert/CA/portal-ca.crt
scp portal-ca.pem NODE7:/root/k8s-replace-cert/CA/portal-ca.crt
scp portal-ca.pem NODE8:/root/k8s-replace-cert/CA/portal-ca.crt
cat /etc/kubernetes/ssl/ca.crt >> /etc/kubernetes/ssl/apiserver-ca.crt
cat $k8s_cert_dir/CA/clientCA.crt >> /etc/kubernetes/ssl/apiserver-ca.crt
cat $k8s_cert_dir/CA/portal-ca.crt >> /etc/kubernetes/ssl/apiserver-ca.crt
-
重启master节点进程：
-
重启work节点进程：
-
节点详情：
有时重启完，master或者worker节点有部分通讯异常，需要手动删除/var/lib/kubelet/pki的软连接文件kubelet-client-current.pem文件，这个文件有时可能不会自动关联最新的kube-client证书。
Dashboard接入容器Portal
-
Dashboard Services使用Nodeport
默认Dashboard是通过Kube-proxy访问的，由于容器平台portal使用nodeport进行访问，因此在部署完成后，需要修改dashboard相关services配置，详见github说明：
https://github.com/kubernetes/dashboard/wiki/Accessing-Dashboard---1.7.X-and-above
kubectl -n kube-system edit service kubernetes-dashboard
spec:
clusterIP:
externalTrafficPolicy: Cluster
ports:
- nodePort: 30443 ###添加指定端口
port: 443
protocol: TCP
targetPort: 8443
selector:
k8s-app: kubernetes-dashboard
sessionAffinity: None
type: NodePort ### ClusterIP修改为Nodeport
status:
loadBalancer: {}
-
Dashboard 证书重新生成
mkdir -p /etc/kubernetes/ssl/dashboard
cp /etc/kubernetes/ssl/apiserver-ca.crt /etc/kubernetes/ssl/dashboard/dashboard-ca.crt
cp /etc/kubernetes/ssl/apiserver.crt /etc/kubernetes/ssl/dashboard/dashboard.crt
cp /etc/kubernetes/ssl/apiserver.key /etc/kubernetes/ssl/dashboard/dashboard.key
cat $k8s_cert_dir/CA/clientCA.crt >> /etc/kubernetes/ssl/dashboard/dashboard.crt
cat $k8s_cert_dir/CA/portal-ca.crt >> /etc/kubernetes/ssl/dashboard/dashboard.crt
-
重新生成相关dashboard相关secrets，将证书内容注入其中
kubectl -n kube-system delete secrets kubernetes-dashboard-certs
kubectl create secret generic kubernetes-dashboard-certs --fromfile=/
etc/kubernetes/ssl/dashboard -n kube-system
-
使用nodeselector指定部署节点为master节点，并指定dashboard的TLS证书
kubectl -n kube-system edit deployments kubernetes-dashboard
spec:
nodeSelector: ####添加
node-role.kubernetes.io/master: "" ####添加
containers:
- args:
- --auto-generate-certificates #删除
- --tls-key-file=dashboard.key ####添加
- --tls-cert-file=dashboard.crt ####添加
- --authentication-mode=token
- --token-ttl=900
image: /lzq/kubernetes-dashboard-amd64:v1.10.0
imagePullPolicy: IfNotPresent
对接完dashboard，控制台还不是不能正常显示，无法展示控制台的更多的功能，还会报如下错误：
User "system:serviceaccount:kube-system:kubernetes-dashboard" cannot list resource "events" in API group "" in the namespace "default"
通过查看pod日志：
经查证，有serviceaccount认证账户，重建无效；查看clusterrole正常，但是查看clusterrolebinding时发现少了kubernetes-dashboard一条内容，其记录了全局管理权限。
但是默认是没有创建完全RBAC的管理role，需要添加，并用kubectl apply -f dashboard-clusterrole.yaml创建，文件内容如下：
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
name: kubernetes-dashboard
labels:
k8s-app: kubernetes-dashboard
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-adminsubjects:
- kind: ServiceAccount
name: kubernetes-dashboard
namespace: kube-system
再次查看dashboard yaml配置文件，与1.12对比，发现少了--tls-ca-file这个参数，加上会后crashloopbackoff报错，查看kubelet --help命令也没有这个参数，所以需要去掉。查看官方也有这种说法，1.12以前是这么定义的：kube-apiserver trusts any cert if it is run without the --tls-ca-file set，1.14版本以后这个参数可能被遗弃了，不是强制校验了。
另外/etc/kubernetes/manifests目录存放k8s自带组件的yaml文件，这里不要放置备份文件，容易造成修改不生效的问题存在，需要想看容器进程读的配置文件对比查看。
-
再来打开，控制台，集群详情显示正常：
3
第三部分：常见问题处理和容器混淆参数说明
-
高版本的kubeadm初始化后报unable to update cni config:no valid networks found in /etc/cni/net.d
原因是高版本的kubelet将验证cni配置文件，如果不支持cniVersion，说明需要替换匹配版本的cni-conf.json数据缺失匹配的cniVersion，因此plugin flannel does not support config version返回类似错误，说明coredns下载的版本不正确或者文件异常，需要重新校对
-
容易混淆的参数说明：
(其余可以参考https://github.com/kubernetes-sigs/kubespray/tree/master/docs)
-
1.kubectl_localhost and kubeconfig_localhost: 同时设置为true时， kubectl 才会安装在本地机器上。
-
2.local_release_dir:所有二进制文件都会被预读到这个位置才能被推送安装，默认位置/tmp/release
-
3.download_container:设置为true表示如果需要拉动或要求始终拉动镜像，则下载到容器所有节点上
-
4.download_run_once、k8s_image_pull_policy、download_always_pull:
Kubespray支持多种下载/上传模式。默认值为：
每个节点自己下载二进制文件和容器映像，这是download_run_once:False。对于K8s应用程序，提取策略为k8s_image_pull_policy：IfNotPresent。对于诸如kubelet或etcd之类的系统管理的容器,拉策略为download_always_pull：False，如果仅所需的回购和tag/sha256摘要与主机的不同，则为拉。还有“一次拉动，多次推”模式：
设置download_run_once:True将使kubespray仅下载一次容器映像和二进制文件，然后将它们推送到群集节点。默认的下载委托节点是第一个kube-master。
设置download_localhost：为True可使localhost成为下载委托。如果群集节点无法访问外部地址，这将很有用。要使用此功能，需要在ansible主服务器上安装并运行docker，并且当前用户位于docker组中，或者可以执行无密码sudo，才能访问docker。
注意：当download_run_once为true且download_localhost为false时，所有下载将在委托节点上完成，包括该节点上不需要的容器镜像的下载。结果，该节点上所需的存储可能比download_run_once为false时要多，因为所有映像都将加载到该节点上的docker实例中，而不仅仅是该节点所需的映像。
缓存时：
当download_run_once为True时，所有下载的文件都将本地缓存在download_cache_dir中，默认值为/tmp/kubespray_cache。在随后的供应运行中，此本地缓存将用于供应节点，从而最大程度地减少带宽使用并缩短供应时间。预计在ansible节点上约有800MB的磁盘空间可用于缓存。 kubernetes节点上的镜像缓存所需的磁盘空间与最大镜像所需的磁盘空间差不多，目前最大磁盘空间略小于150MB。
默认情况下，如果download_run_once为false，则kubespray不会将下载的镜像和文件从下载委托节点检索到本地缓存，也不会使用该缓存预先设置这些节点。如果您具有包含容器映像和文件的完整缓存，并且不需要下载任何内容，但是想要使用缓存，则将download_force_cache设置为True。
默认情况下，用于预配置远程节点的缓存映像将在使用后从远程节点中删除，以节省磁盘空间。设置download_keep_remote_cache将防止文件被删除。这在开发kubespray时很有用，因为它可以减少预配时间。结果，远程节点上所需的镜像存储空间将从150MB增加到大约550MB，这是当前所有所需容器镜像的总大小。
容器镜像和二进制文件由vars描述，如foo_version，foo_download_url，用于二进制文件的foo_checksum和用于容器的foo_image_repo，foo_image_tag或可选的foo_digest_checksum。
三
结论
总结一下，kuberspray是一套很好的开源利用ansible自动化部署kubernetes的工具，从头部署一般能够很好理解证书之间的校验关系，部署虽然简单，但是遇到了很多坎，感谢提供帮助的小伙伴。k8s包含一套完整的HA和LB方案，功能扩展强大，kubespray只是其中代表工具之一，这也说明为啥社区开发者喜欢大力度开发k8s了。
林子强
2015年初加入民生银行，一直从事linux、AIX、vmware系统运维，参加过民生多个灾备系统项目的项目部分搭建，现对容器这块有一定的研究，期望能让更多的人分享学到技术的快乐！
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK