vi /etc/selinux/config
SELINUX=disabled
注:不要修改SELINUXTYPE=targeted
若修改错误解决方案
1.重启系统时候在如下页面选择你要进的内核,按 E ,grub编辑页面。
2.找到linux16那行 在LANG=zh_CN.UTF-8 空格 加上 selinux=0或者 enforcing=0(我是第一个就解决问题了)
3.之后Ctrl+x启动,之后等会就会看到熟悉的页面了。要说一点的是,可能会在下图所示页面卡顿一会,等会就行了
systemctl stop firewalld
systemctl disable firewalld
cd ~
mkdir .ssh
chmod 700 .ssh
cd .ssh
ssh-keygen -t rsa
ssh-keygen -t dsa
cat *.pub > authorized_keys
chmod 644 authorized_keys
然后将所有节点的authorized_keys合并成一个文件
节点A
scp authorized_keys k8snode1:/root/.ssh/node1
节点B
cat node1>>authorized_keys
再将合并后的文件覆盖authorized_keys
vi /etc/hosts
192.168.200.221 k8smaster
192.168.200.222 k8smaster2
192.168.200.223 k8snode
swapoff -a && sysctl -w vm.swappiness=0
sed '/swap.img/d' -i /etc/fstab
注释掉/etc/fstab中swap挂载
modprobe br_netfilter
cat <.d/k8s.conf
net.ipv4.ip_forward = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
EOF
modprobe -- ip_vs
modprobe -- ip_vs_rr
modprobe -- ip_vs_wrr
modprobe -- ip_vs_sh
modprobe -- nf_conntrack_ipv4
sysctl -p /etc/sysctl.d/k8s.conf
以下内容来自于官方英文文档,通过yum安装所以需要接通外网,系统版本CENTOS7最新版
所有机器全部安装
在新主机上首次安装Docker CE之前,需要设置Docker存储库。之后,您可以从存储库安装和更新Docker。
设置存储库
yum remove docker \
docker-client \
docker-client-latest \
docker-common \
docker-latest \
docker-latest-logrotate \
docker-logrotate \
docker-selinux \
docker-engine-selinux \
docker-engine
yum install -y yum-utils \
device-mapper-persistent-data \
lvm2
yum-config-manager \
--add-repo \
https://download.docker.com/linux/centos/docker-ce.repo
注:若无法下载可以手动下载之后在进行安装
yum-config-manager --add-repo /usr/MyWorkSpace/docker-ce.repo
yum-config-manager --enable docker-ce-edge
yum-config-manager --enable docker-ce-test
yum -y install docker-ce
由于网络原因无法使用yum安装可以通过以下网址下载后进行安装
https://download.docker.com/linux/centos/7/x86_64/stable/Packages/
yum install /path/to/package.rpm
或者切换阿里云镜像
vi /etc/yum.repos.d/docker-ce.repo
通过命令把https://download-stage.docker.com替换为http://mirrors.aliyun.com/docker-ce
命令如下:
:%s#https://download-stage.docker.com#http://mirrors.aliyun.com/docker-ce#g
systemctl enable docker && systemctl start docker
https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.11.md#client-binaries
源码在github上自行下载
在所有节点上配置kubectl,kubectl在kubernetes-server-linux-amd64.tar.gz中
将kubectl拷贝到如下目录
cp kubectl /usr/local/bin/
将kubernetes-node-linux-amd64.tar.gz中的所有文件拷贝到
cp * /usr/local/bin/
export CNI_URL=https://github.com/containernetworking/plugins/releases/download
mkdir -p /opt/cni/bin && cd /opt/cni/bin
wget "${CNI_URL}/v0.7.1/cni-plugins-amd64-v0.7.1.tgz" | tar –zx
tar -xvf cni-plugins-amd64-v0.7.1.tgz
export CFSSL_URL=https://pkg.cfssl.org/R1.2
wget ${CFSSL_URL}/cfssl_linux-amd64 -O /usr/local/bin/cfssl
wget ${CFSSL_URL}/cfssljson_linux-amd64 -O /usr/local/bin/cfssljson
wget ${CFSSL_URL}/cfssl-certinfo_linux-amd64 -O /usr/local/bin/cfssl-certinfo
chmod +x /usr/local/bin/cfssl /usr/local/bin/cfssljson /usr/local/bin/cfssl-certinfo
git clone https://github.com/kairen/k8s-manual-files.git ~/k8s-manual-files
cd ~/k8s-manual-files/pki
在k8s-m1建立/etc/etcd/ssl文件夹,并产生 Etcd CA:
export DIR=/etc/etcd/ssl
mkdir -p ${DIR}
cfssl gencert -initca etcd-ca-csr.json | cfssljson -bare ${DIR}/etcd-ca
产生Etcd凭证:
cfssl gencert \
-ca=${DIR}/etcd-ca.pem \
-ca-key=${DIR}/etcd-ca-key.pem \
-config=ca-config.json \
-hostname=127.0.0.1,192.168.200.221,192.168.200.222 \
-profile=kubernetes \
etcd-csr.json | cfssljson -bare ${DIR}/etcd
删除不必要的文件,检查并/etc/etcd/ssl目录是否成功建立以下文件:
$ rm -rf ${DIR}/*.csr
$ ls /etc/etcd/ssl
etcd-ca-key.pem etcd-ca.pem etcd-key.pem etcd.pem
复制文件至其他Etcd节点,这边为所有master节点:
scp -r /etc/etcd 192.168.200.222:/etc/
export K8S_DIR=/etc/kubernetes
export PKI_DIR=${K8S_DIR}/pki
export KUBE_APISERVER=https://192.168.200.225:6443
mkdir -p ${PKI_DIR}
cfssl gencert -initca ca-csr.json | cfssljson -bare ${PKI_DIR}/ca
ls ${PKI_DIR}/ca*.pem
注:
1、 KUBE_APISERVER这边设定为VIP位址。
cfssl gencert \
-ca=${PKI_DIR}/ca.pem \
-ca-key=${PKI_DIR}/ca-key.pem \
-config=ca-config.json \
-hostname=10.96.0.1,192.168.200.225,127.0.0.1,kubernetes.default \
-profile=kubernetes \
apiserver-csr.json | cfssljson -bare ${PKI_DIR}/apiserver
ls ${PKI_DIR}/apiserver*.pem
注:
1、这边-hostname的10.96.0.1是 Cluster IP 的 Kubernetes 端点;
2、192.168.200.225为 VIP 地址;
3、kubernetes. iptv为 Kubernetes 系统在 default namespace 自动建立的 API service domain name
此凭证将被用于 Authenticating Proxy 的功能上,而该功能主要是提供 API Aggregation 的认证。首先通过以下指令产生 CA:
cfssl gencert -initca front-proxy-ca-csr.json | cfssljson -bare ${PKI_DIR}/front-proxy-ca
ls ${PKI_DIR}/front-proxy-ca*.pem
/etc/kubernetes/pki/front-proxy-ca-key.pem /etc/kubernetes/pki/front-proxy-ca.pem
接着产生 Front proxy client 凭证:
cfssl gencert \
-ca=${PKI_DIR}/front-proxy-ca.pem \
-ca-key=${PKI_DIR}/front-proxy-ca-key.pem \
-config=ca-config.json \
-profile=kubernetes \
front-proxy-client-csr.json | cfssljson -bare ${PKI_DIR}/front-proxy-client
ls ${PKI_DIR}/front-proxy-client*.pem
/etc/kubernetes/pki/front-proxy-client-key.pem /etc/kubernetes/pki/front-proxy-client.pem
凭证会建立system:kube-controller-manager的使用者(凭证 CN),并被绑定在 RBAC Cluster Role 中的system:kube-controller-manager来让 Controller Manager 组件能够存取需要的 API object。这边通过以下指令产生 Controller Manager 凭证:
cfssl gencert \
-ca=${PKI_DIR}/ca.pem \
-ca-key=${PKI_DIR}/ca-key.pem \
-config=ca-config.json \
-profile=kubernetes \
manager-csr.json | cfssljson -bare ${PKI_DIR}/controller-manager
ls ${PKI_DIR}/controller-manager*.pem
/etc/kubernetes/pki/controller-manager-key.pem /etc/kubernetes/pki/controller-manager.pem
接着利用kubectl来产生Controller Manager的kubeconfig档:
kubectl config set-cluster kubernetes \
--certificate-authority=${PKI_DIR}/ca.pem \
--embed-certs=true \
--server=${KUBE_APISERVER} \
--kubeconfig=${K8S_DIR}/controller-manager.conf
kubectl config set-credentials system:kube-controller-manager \
--client-certificate=${PKI_DIR}/controller-manager.pem \
--client-key=${PKI_DIR}/controller-manager-key.pem \
--embed-certs=true \
--kubeconfig=${K8S_DIR}/controller-manager.conf
kubectl config set-context system:kube-controller-manager@kubernetes \
--cluster=kubernetes \
--user=system:kube-controller-manager \
--kubeconfig=${K8S_DIR}/controller-manager.conf
kubectl config use-context system:kube-controller-manager@kubernetes \
--kubeconfig=${K8S_DIR}/controller-manager.conf
凭证会建立system:kube-scheduler的使用者(凭证 CN),并被绑定在 RBAC Cluster Role 中的system:kube-scheduler来让 Scheduler 组件能够存取需要的 API object。这边通过以下指令产生 Scheduler 凭证:
cfssl gencert \
-ca=${PKI_DIR}/ca.pem \
-ca-key=${PKI_DIR}/ca-key.pem \
-config=ca-config.json \
-profile=kubernetes \
scheduler-csr.json | cfssljson -bare ${PKI_DIR}/scheduler
ls ${PKI_DIR}/scheduler*.pem
/etc/kubernetes/pki/scheduler-key.pem /etc/kubernetes/pki/scheduler.pem
接着利用kubectl来产生Scheduler的kubeconfig文件:
kubectl config set-cluster kubernetes \
--certificate-authority=${PKI_DIR}/ca.pem \
--embed-certs=true \
--server=${KUBE_APISERVER} \
--kubeconfig=${K8S_DIR}/scheduler.conf
kubectl config set-credentials system:kube-scheduler \
--client-certificate=${PKI_DIR}/scheduler.pem \
--client-key=${PKI_DIR}/scheduler-key.pem \
--embed-certs=true \
--kubeconfig=${K8S_DIR}/scheduler.conf
kubectl config set-context system:kube-scheduler@kubernetes \
--cluster=kubernetes \
--user=system:kube-scheduler \
--kubeconfig=${K8S_DIR}/scheduler.conf
kubectl config use-context system:kube-scheduler@kubernetes \
--kubeconfig=${K8S_DIR}/scheduler.conf
Admin 被用来绑定 RBAC Cluster Role 中 cluster-admin,当想要操作所有 Kubernetes 集群功能时,就必须利用这边产生的 kubeconfig 文件案。这边通过以下指令产生 Kubernetes Admin 凭证:
cfssl gencert \
-ca=${PKI_DIR}/ca.pem \
-ca-key=${PKI_DIR}/ca-key.pem \
-config=ca-config.json \
-profile=kubernetes \
admin-csr.json | cfssljson -bare ${PKI_DIR}/admin
ls ${PKI_DIR}/admin*.pem
/etc/kubernetes/pki/admin-key.pem /etc/kubernetes/pki/admin.pem
接着利用kubectl来产生Admin的kubeconfig文件:
kubectl config set-cluster kubernetes \
--certificate-authority=${PKI_DIR}/ca.pem \
--embed-certs=true \
--server=${KUBE_APISERVER} \
--kubeconfig=${K8S_DIR}/admin.conf
kubectl config set-credentials kubernetes-admin \
--client-certificate=${PKI_DIR}/admin.pem \
--client-key=${PKI_DIR}/admin-key.pem \
--embed-certs=true \
--kubeconfig=${K8S_DIR}/admin.conf
kubectl config set-context kubernetes-admin@kubernetes \
--cluster=kubernetes \
--user=kubernetes-admin \
--kubeconfig=${K8S_DIR}/admin.conf
kubectl config use-context kubernetes-admin@kubernetes \
--kubeconfig=${K8S_DIR}/admin.conf
这边使用 Node authorizer 来让节点的 kubelet 能够存取如 services、endpoints 等 API,而使用 Node authorizer 需定义 system:nodes 群组(凭证的 Organization),并且包含system:node:的使用者名称(凭证的 Common Name)。
首先在k8s-m1节点产生所有 master 节点的 kubelet 凭证,这边通过下面脚本来产生:
for NODE in k8smaster k8smaster2; do
echo "--- $NODE ---"
cp kubelet-csr.json kubelet-$NODE-csr.json;
sed -i "s/\$NODE/$NODE/g" kubelet-$NODE-csr.json;
cfssl gencert \
-ca=${PKI_DIR}/ca.pem \
-ca-key=${PKI_DIR}/ca-key.pem \
-config=ca-config.json \
-hostname=$NODE \
-profile=kubernetes \
kubelet-$NODE-csr.json | cfssljson -bare ${PKI_DIR}/kubelet-$NODE;
rm kubelet-$NODE-csr.json
done
ls ${PKI_DIR}/kubelet*.pem
注:
k8smaster k8smaster2为服务器IP
产生完成后,将kubelet凭证复制到所有master节点上:
for NODE in k8smaster k8smaster2; do
echo "--- $NODE ---"
ssh ${NODE} "mkdir -p ${PKI_DIR}"
scp ${PKI_DIR}/ca.pem ${NODE}:${PKI_DIR}/ca.pem
scp ${PKI_DIR}/kubelet-$NODE-key.pem ${NODE}:${PKI_DIR}/kubelet-key.pem
scp ${PKI_DIR}/kubelet-$NODE.pem ${NODE}:${PKI_DIR}/kubelet.pem
rm ${PKI_DIR}/kubelet-$NODE-key.pem ${PKI_DIR}/kubelet-$NODE.pem
done
接着利用 kubectl 来产生 kubelet 的 kubeconfig 文件,这边通过脚本来产生所有master节点的文件:
for NODE in k8smaster k8smaster2; do
echo "--- $NODE ---"
ssh ${NODE} "cd ${PKI_DIR} && \
kubectl config set-cluster kubernetes \
--certificate-authority=${PKI_DIR}/ca.pem \
--embed-certs=true \
--server=${KUBE_APISERVER} \
--kubeconfig=${K8S_DIR}/kubelet.conf && \
kubectl config set-credentials system:node:${NODE} \
--client-certificate=${PKI_DIR}/kubelet.pem \
--client-key=${PKI_DIR}/kubelet-key.pem \
--embed-certs=true \
--kubeconfig=${K8S_DIR}/kubelet.conf && \
kubectl config set-context system:node:${NODE}@kubernetes \
--cluster=kubernetes \
--user=system:node:${NODE} \
--kubeconfig=${K8S_DIR}/kubelet.conf && \
kubectl config use-context system:node:${NODE}@kubernetes \
--kubeconfig=${K8S_DIR}/kubelet.conf"
done
Kubernetes Controller Manager 利用 Key pair 来产生与签署 Service Account 的 tokens,而这边不通过 CA 做认证,而是建立一组公私钥来让 API Server 与 Controller Manager 使用:
openssl genrsa -out ${PKI_DIR}/sa.key 2048
openssl rsa -in ${PKI_DIR}/sa.key -pubout -out ${PKI_DIR}/sa.pub
ls ${PKI_DIR}/sa.*
删除不必要文件
当所有文件建立与产生完成后,将一些不必要文件删除:
rm -rf ${PKI_DIR}/*.csr \
${PKI_DIR}/scheduler*.pem \
${PKI_DIR}/controller-manager*.pem \
${PKI_DIR}/admin*.pem \
${PKI_DIR}/kubelet*.pem
复制文件至其他节点
凭证将复制到其他master节点:
for NODE in k8smaster k8smaster2; do
echo "--- $NODE ---"
for FILE in $(ls ${PKI_DIR}); do
scp ${PKI_DIR}/${FILE} ${NODE}:${PKI_DIR}/${FILE}
done
done
复制kubeconfig文件至其他master节点:
for NODE in k8smaster k8smaster2; do
echo "--- $NODE ---"
for FILE in admin.conf controller-manager.conf scheduler.conf; do
scp ${K8S_DIR}/${FILE} ${NODE}:${K8S_DIR}/${FILE}
done
done
本节将说明如何部署与设定Kubernetes Master角色中的各组件,在开始前先简单了解一下各组件功能:
1. kubelet:负责管理容器的生命周期,定期从 API Server 取得节点上的预期状态(如网络、储存等等配置)资源,并呼叫对应的容器接口(CRI、CNI 等)来达成这个状态。任何 Kubernetes 节点都会拥有该组件。
2. kube-apiserver:以 REST APIs 提供 Kubernetes 资源的 CRUD,如授权、认证、访问控制与 API 注册等机制。
3. kube-controller-manager:通过核心控制循环(Core Control Loop)监听 Kubernetes API 的资源来维护集群的状态,这些资源会被不同的控制器所管理,如 Replication Controller、Namespace Controller 等等。而这些控制器会处理着自动扩展、滚动更新等等功能。
4. kube-scheduler:负责将一个(或多个)容器依据排程策略分配到对应节点上让容器引擎(如 Docker)执行。而排程受到 QoS 要求、软硬件约束、亲和性(Affinity)等等规范影响。
5. Etcd:用来保存集群所有状态的 Key/Value 储存系统,所有 Kubernetes 组件会通过 API Server 来跟 Etcd 进行沟通来保存或取得资源状态。
6. HAProxy:提供多个 API Server 的负载平衡(Load Balance)。
7. Keepalived:建立一个虚拟 IP(VIP) 来作为 API Server 统一存取端点。
而上述组件除了 kubelet 外,其他将通过 kubelet 以 Static Pod 方式进行部署,这种方式可以减少管理 Systemd 的服务,并且能通过 kubectl 来观察启动的容器状况。
在首先k8s-m1节点展示进入k8s-manual-files目录,并依序执行下述指令来完成部署:
cd ~/k8s-manual-files
首先利用./hack/gen-configs.sh脚本在每台master节点产生组态文件:
export NODES="k8smaster k8smaster2"
export ADVERTISE_VIP=192.168.200.225
./hack/gen-configs.sh
k8s-m1 config generated...
k8s-m2 config generated...
k8s-m3 config generated...
后完成检查记得/etc/etcd/config.yml与/etc/haproxy/haproxy.cfg是否设定正确。
接着利用./hack/gen-manifests.sh脚本在每台master节点产生 Static pod YAML 文件,以及其他相关配置文件(如 EncryptionConfig):
export NODES="k8smaster k8smaster2"
./hack/gen-configs.sh
./hack/gen-manifests.sh
完成后记得检查/etc/kubernetes/manifest,/etc/kubernetes/encryption与/etc/kubernetes/audit目录中的文件是否正确。
将修改完成后的配置文件传送到所有master节点
注:
1、 需要提前修改/root/k8s-manual-files/master/manifests下配置文件中的镜像名称,由于1.11.0在centos下启用ipvs有bug,所以需要升级镜像版本
2、 修改kube-apiserver.yml、kube-controller-manager.yml kube-scheduler.yml中的v1.11.0为v1.11.2
3、 编辑/etc/kubernetes/manifests/keepalived.yml
value: "#PYTHON2BASH:[192.168.24.31,192.168.23.221]"为ETCD IP
KEEPALIVED_ROUTER_ID中的值为60
4、 编辑kube-apiserver.yml
修改etcd数据库地址,修改–secure-port=6443 默认是5443
确认上述两个产生文件步骤完成后,即可设定所有master节点的 kubelet systemd 来启动 Kubernetes 组件。首先复制下列文件到指定路径:
for NODE in k8smaster k8smaster2; do
echo "--- $NODE ---"
ssh ${NODE} "mkdir -p /var/lib/kubelet /var/log/kubernetes /var/lib/etcd /etc/systemd/system/kubelet.service.d"
scp master/var/lib/kubelet/config.yml ${NODE}:/var/lib/kubelet/config.yml
scp master/systemd/kubelet.service ${NODE}:/lib/systemd/system/kubelet.service
scp master/systemd/10-kubelet.conf ${NODE}:/etc/systemd/system/kubelet.service.d/10-kubelet.conf
done
接着在k8s-m1通过SSH启动所有master节点的kubelet:
for NODE in k8smaster k8smaster2; do
ssh ${NODE} "systemctl enable kubelet.service && systemctl start kubelet.service"
done
完成后会需要一段时间来下载映像档与启动组件,可以利用该指令来监看:
注:(以下几点特别重要)
1、镜像下载方式看附录
2、docker rm -f (dockerps−qa),部分进程无法启动时需要删除原有容器3、删除 ( d o c k e r p s − q a ) , 部 分 进 程 无 法 启 动 时 需 要 删 除 原 有 容 器 3 、 删 除 KUBELET_NETWORK_ARGS
/etc/systemd/system/kubelet.service.d/10-kubeadm.conf
检查进程是否全部启动
yum install net-tools
watch netstat -ntlp
由于本教程采用 TLS 认证来确保 Kubernetes 集群的安全性,因此每个节点的 kubelet 都需要通过 API Server 的 CA 进行身份验证后,才能与 API Server 进行沟通,而这过程过去都是采用手动方式针对每台节点(master与node)单独签署凭证,再设定给 kubelet 使用,然而这种方式是一件繁琐的事情,因为当节点扩展到一定程度时,将会非常费时,甚至延伸初管理不易问题。
而由于上述问题,Kubernetes 实现了 TLS Bootstrapping 来解决此问题,这种做法是先让 kubelet 以一个低权限使用者(一个能存取 CSR API 的 Token)存取 API Server,接着对 API Server 提出申请凭证签署请求,并在受理后由 API Server 动态签署 kubelet 凭证提供给对应的node节点使用。具体作法请参考 TLS Bootstrapping 与 Authenticating with Bootstrap Tokens。
4.2.1在k8s-m1建立bootstrap使用者的kubeconfig
export TOKEN_ID=$(openssl rand 3 -hex)
export TOKEN_SECRET=$(openssl rand 8 -hex)
export BOOTSTRAP_TOKEN=${TOKEN_ID}.${TOKEN_SECRET}
export KUBE_APISERVER="https://192.168.200.225:6443"
kubectl config set-cluster kubernetes \
--certificate-authority=/etc/kubernetes/pki/ca.pem \
--embed-certs=true \
--server=${KUBE_APISERVER} \
--kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf
kubectl config set-credentials tls-bootstrap-token-user \
--token=${BOOTSTRAP_TOKEN} \
--kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf
kubectl config set-context tls-bootstrap-token-user@kubernetes \
--cluster=kubernetes \
--user=tls-bootstrap-token-user \
--kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf
kubectl config use-context tls-bootstrap-token-user@kubernetes \
--kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf
export KUBECONFIG=/etc/kubernetes/admin.conf
cat <<EOF | kubectl create -f -
apiVersion: v1
kind: Secret
metadata:
name: bootstrap-token-${TOKEN_ID}
namespace: kube-system
type: bootstrap.kubernetes.io/token
stringData:
token-id: "${TOKEN_ID}"
token-secret: "${TOKEN_SECRET}"
usage-bootstrap-authentication: "true"
usage-bootstrap-signing: "true"
auth-extra-groups: system:bootstrappers:default-node-token
EOF
secret/bootstrap-token-e371c7 created
$ cd ~/k8s-manual-files/
$ kubectl apply -f master/resources/kubelet-bootstrap-rbac.yml
clusterrolebinding.rbac.authorization.k8s.io/kubelet-bootstrap created
clusterrolebinding.rbac.authorization.k8s.io/node-autoapprove-bootstrap created
clusterrolebinding.rbac.authorization.k8s.io/node-autoapprove-certificate-rotation created
cp /etc/kubernetes/admin.conf ~/.kube/config
kubectl get cs
kubectl -n kube-system get po
kubectl get node
通过kubectl logs来查看容器的日志:
kubectl -n kube-system logs -f kube-apiserver-k8smaster
注:
1、这边会发现出现 403 Forbidden 问题,这是因为 kube-apiserver user 并没有 nodes 的资源访问权限,属于正常。
为了方便管理集群,因此需要通过 kubectl logs 来查看,但由于 API 权限问题,故需要建立一个 RBAC Role 来获取访问权限,这边在k8smaster节点执行以下指令建立:
kubectl apply -f master/resources/apiserver-to-kubelet-rbac.yml
完成后,再次通过kubectl logs查看Pod:
kubectl -n kube-system logs -f kube-apiserver-k8smaster
接着设定 Taints and Tolerations 来让一些特定 Pod 能够排程到所有master节点上:
kubectl taint nodes node-role.kubernetes.io/master="":NoSchedule --all
本节将说明如何建立与设定 Kubernetes Node 节点,Node 是主要执行容器实例(Pod)的工作节点。这过程只需要将 PKI、Bootstrap conf 等文件复制到机器上,再用 kubelet 启动即可。
在开始部署前,在k8smaster将需要用到的文件复制到所有node节点上:
for NODE in k8snode1; do
echo "--- $NODE ---"
ssh ${NODE} "mkdir -p /etc/kubernetes/pki/"
for FILE in pki/ca.pem pki/ca-key.pem bootstrap-kubelet.conf; do
scp /etc/kubernetes/${FILE} ${NODE}:/etc/kubernetes/${FILE}
done
done
确认文件都复制后,即可设定所有node节点的 kubelet systemd 来启动 Kubernetes 组件。首先在k8s-m1复制下列文件到指定路径:
cd ~/k8s-manual-files
for NODE in k8snode1; do
echo "--- $NODE ---"
ssh ${NODE} "mkdir -p /var/lib/kubelet /var/log/kubernetes /var/lib/etcd /etc/systemd/system/kubelet.service.d /etc/kubernetes/manifests"
scp node/var/lib/kubelet/config.yml ${NODE}:/var/lib/kubelet/config.yml
scp node/systemd/kubelet.service ${NODE}:/lib/systemd/system/kubelet.service
scp node/systemd/10-kubelet.conf ${NODE}:/etc/systemd/system/kubelet.service.d/10-kubelet.conf
done
接着在k8s-m1通过SSH启动所有node节点的kubelet:
for NODE in k8snode1; do
ssh ${NODE} "systemctl enable kubelet.service && systemctl start kubelet.service"
done
完成后,在任意一台master节点复制Admin kubeconfig文件,并通过简单指令验证:
kubectl get csr
注:
1、可以调用kubectl get csr
查看是否有csr处于pending的状态,有的话,调用kubectl certificate approve $CSR
将其确认即可
当完成master与node节点的部署,并组合成一个可运作集群后,就可以开始通过 kubectl 部署 Addons,Kubernetes 官方提供了多种 Addons 来加强 Kubernetes 的各种功能,如集群 DNS 解析的kube-dns(or CoreDNS)、外部存取服务的kube-proxy与 Web-based 管理接口的dashboard等等。而其中有些 Addons 是被 Kubernetes 认定为必要的,因此本节将说明如何部署这些 Addons。
在首先k8s-m1节点展示进入k8s-manual-files目录,并依序执行下述指令来完成部署:
$ cd ~/k8s-manual-files
启动linux中的IPVS(所有节点执行)
cat << EOF > /etc/sysconfig/modules/ipvs.modules
#!/bin/bash
ipvs_modules_dir="/usr/lib/modules/\`uname -r\`/kernel/net/netfilter/ipvs"
for i in \`ls \$ipvs_modules_dir | sed -r 's#(.*).ko.xz#\1#'\`; do
/sbin/modinfo -F filename \$i &> /dev/null
if [ \$? -eq 0 ]; then
/sbin/modprobe \$i
fi
done
EOF
chmod 755 /etc/sysconfig/modules/ipvs.modules && bash /etc/sysconfig/modules/ipvs.modules && lsmod | grep ip_vs
cp /etc/sysconfig/modules/ipvs.modules /lib/modules
kube-proxy 是实现 Kubernetes Service 资源功能的关键组件,这个组件会通过 DaemonSet 在每台节点上执行,然后监听 API Server 的 Service 与 Endpoint 资源对象的事件,并依据资源预期状态通过 iptables 或 ipvs 来实现网络转发,而本次安装采用 ipvs。
在k8s-m1通过kubeclt执行下面指令来建立,并检查是否部署成功:
export KUBE_APISERVER=https://192.168.200.225:6443
编辑vi /root/k8s-manual-files/addons/kube-proxy/kube-proxy-cm.yml
server: ${KUBE_APISERVER}中的${KUBE_APISERVER}为KUBE_APISERVER
编辑vi addons/kube-proxy/kube-proxy.yml
修改镜像版本为image: k8s.gcr.io/kube-proxy-amd64:v1.11.2
kubectl create -f addons/kube-proxy/
kubectl -n kube-system get po -l k8s-app=kube-proxy
kubectl -n kube-system logs -f kube-proxy-fwgx8
若有安装 ipvsadm 的话,可以通过以下指令查看 proxy 规则:
yum -y install ipvsadm
ipvsadm -ln
本节将通过 CoreDNS 取代 Kube DNS 作为集群服务发现组件,由于 Kubernetes 需要让 Pod 与 Pod 之间能够互相沟通,然而要能够沟通需要知道彼此的 IP 才行,而这种做法通常是通过 Kubernetes API 来取得达到,但是 Pod IP 会因为生命周期变化而改变,因此这种做法无法弹性使用,且还会增加 API Server 负担,基于此问题 Kubernetes 提供了 DNS 服务来作为查询,让 Pod 能够以 Service 名称作为域名来查询 IP 地址,因此用户就再不需要关切实际 Pod IP,而 DNS 也会根据 Pod 变化更新资源纪录(Record resources)。
CoreDNS 是由 CNCF 维护的开源 DNS 项目,该项目前身是 SkyDNS,其采用了 Caddy 的一部分来开发服务器框架,使其能够建构一套快速灵活的 DNS,而 CoreDNS 每个功能都可以被实作成一个插件的中间件,如 Log、Cache、Kubernetes 等功能,甚至能够将源纪录储存至 Redis、Etcd 中。
在k8s-m1通过kubeclt执行下面指令来建立,并检查是否部署成功:
cd /root/k8s-manual-files/addons
$ kubectl create -f coredns/
$ kubectl -n kube-system get po -l k8s-app=kube-dns
这边会发现 Pod 处于Pending状态,这是由于 Kubernetes 的集群网络没有建立,因此所有节点会处于NotReady状态,而这也导致 Kubernetes Scheduler 无法替 Pod 找到适合节点而处于Pending,为了解决这个问题,下节将说明与建立 Kubernetes 集群网络。
注:
1、若 Pod 是被 DaemonSet 管理的话,则不会 Pending,不过若没有设定hostNetwork则会出问题。
Kubernetes 在默认情况下与 Docker 的网络有所不同。在 Kubernetes 中有四个问题是需要被解决的,分别为:
• 高耦合的容器到容器沟通:通过 Pods 与 Localhost 的沟通来解决。
• Pod 到 Pod 的沟通:通过实现网络模型来解决。
• Pod 到 Service 沟通:由 Services object 结合 kube-proxy 解决。
• 外部到 Service 沟通:一样由 Services object 结合 kube-proxy 解决。
而 Kubernetes 对于任何网络的实现都需要满足以下基本要求(除非是有意调整的网络分段策略):
• 所有容器能够在没有 NAT 的情况下与其他容器沟通。
• 所有节点能够在没有 NAT 情况下与所有容器沟通(反之亦然)。
• 容器看到的 IP 与其他人看到的 IP 是一样的。
庆幸的是 Kubernetes 已经有非常多种的网络模型以网络插件(Network Plugins)方式被实现,因此可以选用满足自己需求的网络功能来使用。另外 Kubernetes 中的网络插件有以下两种形式:
• CNI plugins:以 appc/CNI 标准规范所实现的网络,详细可以阅读 CNI Specification。
• Kubenet plugin:使用 CNI plugins 的 bridge 与 host-local 来实现基本的 cbr0。这通常被用在公有云服务上的 Kubernetes 集群网络。
从上述了解 Kubernetes 有多种网络能够选择,而本教学选择了 Calico 作为集群网络的使用。Calico 是一款纯 Layer 3 的网络,其好处是它整合了各种云原生平台(Docker、Mesos 与 OpenStack 等),且 Calico 不采用 vSwitch,而是在每个 Kubernetes 节点使用 vRouter 功能,并通过 Linux Kernel 既有的 L3 forwarding 功能,而当数据中心复杂度增加时,Calico 也可以利用 BGP route reflector 来达成。
由于 Calico 提供了 Kubernetes resources YAML 文件来快速以容器方式部署网络插件至所有节点上,因此只需要在k8s-m1通过 kubeclt 执行下面指令来建立:
$ cd ~/k8s-manual-files
$ sed -i 's/192.168.0.0\/16/10.244.0.0\/16/g' cni/calico/v3.1/calico.yml
$ kubectl create -f cni/calico/v3.1/
注
1、这边要记得将CALICO_IPV4POOL_CIDR的网络修改 Cluster IP CIDR。此配置为10.244.0.0为集群ip
2、另外当节点超过 50 台,可以使用 Calico 的 Typha 模式来减少通过 Kubernetes datastore 造成 API Server 的负担
部署后通过kubectl检查是否有启动:
$ kubectl -n kube-system get po -l k8s-app=calico-node
$ kubectl -n kube-system logs -f kube-proxy-fwgx8
确认 calico-node 都正常运作后,通过 kubectl exec 进入 calicoctl pod 来检查功能是否正常:
$ kubectl exec -ti -n kube-system calicoctl -- calicoctl get profiles -o wide
$ kubectl exec -ti -n kube-system calicoctl -- calicoctl get node -o wide
完成后,通过检查节点是否不再是NotReady,以及Pod是否不再处于Pending:
$ kubectl get no
$ kubectl -n kube-system get po -l k8s-app=kube-dns -o wide
当成功到这边时,一个能运作的 Kubernetes 集群基本上就完成了,接下来将介绍一些好用的 Addons 来帮助使用与管理 Kubernetes。
本节说明如何部署一些官方常用的额外 Addons,如 Dashboard、Metrics Server 与 Ingress Controller 等等。
所有 Addons 部署文件均存已放至k8s-manual-files中,因此在k8s-m1进入该目录,并依序下小节建立:
$ cd ~/k8s-manual-files
Ingress 是 Kubernetes 中的一个抽象资源,其功能是通过 Web Server 的 Virtual Host 概念以域名(Domain Name)方式转发到内部 Service,这避免了使用 Service 中的 NodePort 与 LoadBalancer 类型所带来的限制(如 Port 数量上限),而实现 Ingress 功能则是通过 Ingress Controller 来达成,它会负责监听 Kubernetes API 中的 Ingress 与 Service 资源对象,并在发生资源变化时,依据资源预期的结果来设定 Web Server。另外 Ingress Controller 有许多实现可以选择:
Ingress NGINX: Kubernetes 官方维护的项目,也是本次安装使用的 Controller。
F5 BIG-IP Controller: F5 所开发的 Controller,它能够让管理员通过 CLI 或 API 从 Kubernetes 与 OpenShift 管理 F5 BIG-IP 设备。
Ingress Kong: 著名的开源 API Gateway 项目所维护的 Kubernetes Ingress Controller。
Træfik: 是一套开源的 HTTP 反向代理与负载平衡器,而它也支持了 Ingress。
Voyager: 一套以 HAProxy 为底的 Ingress Controller。
首先在k8s-m1执行下述指令来建立 Ingress Controller,并检查是否部署正常:
export INGRESS_VIP=192.168.200.226
$ sed -i "s/\${INGRESS_VIP}/${INGRESS_VIP}/g" addons/ingress-controller/ingress-controller-svc.yml
$ kubectl create ns ingress-nginx
$ kubectl apply -f addons/ingress-controller
$ kubectl -n ingress-nginx get po,svc
当确认上面步骤都没问题后,就可以通过kubeclt建立简单NGINX来测试功能:
$ kubectl apply -f apps/nginx/
$ kubectl get po,svc,ing
完成后通过cURL工具来测试功能是否正常:
$ curl 192.168.200.226 -H 'Host: nginx.k8s.local'
若出现503错误请等待一会,可能是服务器负载过高
虽然 Ingress 能够让我们通过域名方式存取 Kubernetes 内部服务,但是若域名于法被测试机器解析的话,将会显示default backend – 404结果,而这经常发生在内部自建环境上,虽然可以通过修改主机/etc/hosts来描述,但并不弹性,因此下节将说明如何建立一个 External DNS 与 DNS 服务器来提供自动解析 Ingress 域名。
External DNS 是 Kubernetes 小区的孵化项目,被用于定期同步 Kubernetes Service 与 Ingress 资源,并依据资源内容来自动设定公有云 DNS 服务的资源纪录(Record resources)。而由于部署不是公有云环境,因此需要通过 CoreDNS 提供一个内部 DNS 服务器,再由 ExternalDNS 与这个 CoreDNS 做串接。
首先在k8s-m1执行下述指令来建立CoreDNS Server,并检查是否部署正常:
$ export DNS_VIP=192.168.200.226
$ sed -i "s/\${DNS_VIP}/${DNS_VIP}/g" addons/external-dns/coredns/coredns-svc-tcp.yml
$ sed -i "s/\${DNS_VIP}/${DNS_VIP}/g" addons/external-dns/coredns/coredns-svc-udp.yml
$ kubectl create -f addons/external-dns/namespace.yml
$ kubectl create -f addons/external-dns/coredns/
$ kubectl -n external-dns get po,svc
yum -y install bind-utils
dig @192.168.200.226 SOA nginx.k8s.local +noall +answer +time=2 +tries=1
接着部署ExternalDNS来与CoreDNS同步资源纪录:
$ kubectl apply -f addons/external-dns/external-dns/
$ kubectl -n external-dns get po -l k8s-app=external-dns
完成后,通过dig 与nslookup工具检查上节测试Ingress的NGINX服务:
dig @192.168.200.226 A nginx.k8s.local +noall +answer +time=2 +tries=1
修改vi /etc/resolv.conf
nameserver 192.168.200.226
Dashboard 是 Kubernetes 官方开发的 Web-based 仪表板,目的是提升管理 Kubernetes 集群资源便利性,并以资源可视化方式,来让人更直觉的看到整个集群资源状态,
在k8s-m1通过 kubeclt 执行下面指令来建立 Dashboard 至 Kubernetes,并检查是否正确部署:
$ cd ~/k8s-manual-files
$ kubectl apply -f addons/dashboard/
$ kubectl -n kube-system get po,svc -l k8s-app=kubernetes-dashboard
在这边会额外建立名称为anonymous-dashboard-proxy的 Cluster Role(Binding) 来让system:anonymous这个匿名用户能够通过 API Server 来 proxy 到 Kubernetes Dashboard,而这个 RBAC 规则仅能够存取services/proxy资源,以及https:kubernetes-dashboard:资源名称。
因此我们能够在完成后,通过以下连结来进入 Kubernetes Dashboard:
https://192.168.200.225:6443/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/#!/login
由于 Kubernetes Dashboard v1.7 版本以后不再提供 Admin 权限,因此需要通过 kubeconfig 或者 Service Account 来进行登入才能取得资源来呈现,这边建立一个 Service Account 来绑定cluster-admin 以测试功能:
$ kubectl -n kube-system create sa dashboard
$ kubectl create clusterrolebinding dashboard --clusterrole cluster-admin --serviceaccount=kube-system:dashboard
$ SECRET=$(kubectl -n kube-system get sa dashboard -o yaml | awk '/dashboard-token/ {print $3}')
$ kubectl -n kube-system describe secrets ${SECRET} | awk '/token:/{print $2}'
由于 Heapster 将要被移弃,因此这边选用 Prometheus 作为第三方的集群监控方案。而本次安装采用 CoreOS 开发的 Prometheus Operator 用于管理在 Kubernetes 上的 Prometheus 集群与资源,更多关于 Prometheus Operator 的信息可以参考小弟的 Prometheus Operator 介绍与安装 文章。
首先在k8s-m1执行下述指令来部署所有Prometheus需要的组件:
kubectl apply -f addons/prometheus/
kubectl apply -f addons/prometheus/operator/
kubectl apply -f addons/prometheus/alertmanater/
kubectl apply -f addons/prometheus/node-exporter/
kubectl apply -f addons/prometheus/kube-state-metrics/
kubectl apply -f addons/prometheus/grafana/
kubectl apply -f addons/prometheus/kube-service-discovery/
kubectl apply -f addons/prometheus/prometheus/
kubectl apply -f addons/prometheus/servicemonitor/
完成后,通过kubectl检查服务是否正常运行:
$ kubectl -n monitoring get po,svc,ing
在客户端机器添加DNS服务器192.168.200.226
访问:
这里写链接内容
Metrics Server 是实现了资源 Metrics API 的组件,其目标是取代 Heapster 作为 Pod 与 Node 提供资源的 Usage metrics,该组件会从每个 Kubernetes 节点上的 Kubelet 所公开的 Summary API 中收集 Metrics。
首先在k8s-m1测试一下 kubectl top 指令:
$ kubectl top node
发现 top 指令无法取得 Metrics,这表示 Kubernetes 集群没有安装 Heapster 或是 Metrics Server 来提供 Metrics API 给 top 指令取得资源使用量。
由于上述问题,我们要在k8s-m1节点通过 kubectl 部署 Metrics Server 组件来解决:
$ kubectl create -f addons/metric-server/
$ kubectl -n kube-system get po -l k8s-app=metrics-server
注:
1、vi addons/metric-server/metrics-server-dp.yml
imagePullPolicy: Always 改为 IfNotPresent由于镜像被墙,所以采用ALWAYS无法启动
完成后,等待一点时间(约30s – 1m)收集指标,再次执行kubectl top指令查看:
$ kubectl top node
Helm 是 Kubernetes Chart 的管理工具,Kubernetes Chart 是一套预先组态的 Kubernetes 资源。其中Tiller Server主要负责接收来至 Client 的指令,并通过 kube-apiserver 与 Kubernetes 集群做沟通,根据 Chart 定义的内容,来产生与管理各种对应 API 对象的 Kubernetes 部署文件(又称为 Release)。
首先在k8s-m1安装Helm工具:
$ wget -qO- https://kubernetes-helm.storage.googleapis.com/helm-v2.9.1-linux-amd64.tar.gz | tar -zx
$ mv linux-amd64/helm /usr/local/bin/
另外在所有node节点安装socat:
yum -y install socat
在k8s-m1接着初始化Helm
$ kubectl -n kube-system create sa tiller
$ kubectl create clusterrolebinding tiller --clusterrole cluster-admin --serviceaccount=kube-system:tiller
$ helm init --service-account tiller --upgrade -i registry.cn-hangzhou.aliyuncs.com/google_containers/tiller:v2.9.1 --stable-repo-url https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts
$ helm repo update
$ helm list
$ kubectl -n kube-system get po -l app=helm
$ helm version
测试Helm功能
这边部署简单Jenkins来进行功能测试:
$ helm install --name redis-test --set "persistence.enabled=false,mariadb.persistence.enabled=false" stable/redis
$ kubectl get po,svc,ing -l app=redis-test-redis
若部署出错用以下指令查询详细信息
kubectl describe po -l app=redis-test-redis
根据提示显示进行配置
helm del --purge redis-test
由于官方images被墙,所以只能想别的办法,现在将阿里云的处理方式附录到以下,本地下载与网络下载选一个就行,所有节点都需要下载
cat < /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=0
EOF
yum -y install epel-release
yum clean all
yum makecache
docker pull registry.cn-hangzhou.aliyuncs.com/k8s-gcr-io-jxm/kube-proxy-amd64:v1.11.2
docker pull registry.cn-hangzhou.aliyuncs.com/k8s-gcr-io-jxm/kube-scheduler-amd64:v1.11.2
docker pull registry.cn-hangzhou.aliyuncs.com/k8s-gcr-io-jxm/kube-controller-manager-amd64:v1.11.2
docker pull registry.cn-hangzhou.aliyuncs.com/k8s-gcr-io-jxm/kube-apiserver-amd64:v1.11.2
docker pull quay.io/coreos/etcd:v3.3.8
docker pull docker.io/haproxy:1.7-alpine
docker pull docker.io/osixia/keepalived:1.4.5
docker pull registry.cn-hangzhou.aliyuncs.com/k8s-gcr-io-jxm/pause:3.1
docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/coredns:1.1.3
docker pull registry.cn-hangzhou.aliyuncs.com/criss/quay.io-calico-typha:v0.7.4
docker pull quay.io/calico/node:v3.1.3
docker pull registry.cn-hangzhou.aliyuncs.com/criss/quay.io-calico-cni:v3.1.3
docker pull registry.cn-beijing.aliyuncs.com/k8s_apps/defaultbackend:1.4
docker pull quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.16.2
docker pull coredns/coredns:1.1.4
docker pull registry.opensource.zalan.do/teapot/external-dns:v0.5.4
docker pull registry.cn-hangzhou.aliyuncs.com/kube_containers/kubernetes-dashboard-amd64:v1.8.3
docker pull quay.io/coreos/prometheus-operator:v0.22.0
docker pull quay.io/coreos/kube-rbac-proxy:v0.3.1
docker pull quay.io/prometheus/prometheus
docker pull grafana/grafana:5.1.0
docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/kube-state-metrics:v1.3.1
docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/alertmanager
docker pull quay.io/prometheus/prometheus:v2.3.1
docker pull quay.io/coreos/prometheus-config-reloader:v0.22.0
docker pull quay.io/coreos/configmap-reload:v0.0.1
docker pull registry.cn-hangzhou.aliyuncs.com/k8s-kernelsky/metrics-server-amd64:v0.2.1
docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/tiller:v2.9.1
重命名镜像
docker tag registry.cn-hangzhou.aliyuncs.com/k8s-gcr-io-jxm/kube-proxy-amd64:v1.11.2 k8s.gcr.io/kube-proxy-amd64:v1.11.2
docker tag registry.cn-hangzhou.aliyuncs.com/k8s-gcr-io-jxm/kube-scheduler-amd64:v1.11.2 k8s.gcr.io/kube-scheduler-amd64:v1.11.2
docker tag registry.cn-hangzhou.aliyuncs.com/k8s-gcr-io-jxm/kube-controller-manager-amd64:v1.11.2 k8s.gcr.io/kube-controller-manager-amd64:v1.11.2
docker tag registry.cn-hangzhou.aliyuncs.com/k8s-gcr-io-jxm/kube-apiserver-amd64:v1.11.2 k8s.gcr.io/kube-apiserver-amd64:v1.11.2
docker tag registry.cn-hangzhou.aliyuncs.com/k8s-gcr-io-jxm/etcd-amd64:3.2.18
docker tag registry.cn-hangzhou.aliyuncs.com/k8s-gcr-io-jxm/pause:3.1 k8s.gcr.io/pause:3.1
docker tag registry.cn-hangzhou.aliyuncs.com/google_containers/coredns:1.1.3 k8s.gcr.io/coredns:1.1.3
docker tag registry.cn-hangzhou.aliyuncs.com/criss/quay.io-calico-typha:v0.7.4 quay.io/calico/typha:v0.7.4
docker tag registry.cn-hangzhou.aliyuncs.com/criss/quay.io-calico-cni:v3.1.3 quay.io/calico/cni:v3.1.3
docker tag registry.cn-beijing.aliyuncs.com/k8s_apps/defaultbackend:1.4 gcr.io/google_containers/defaultbackend:1.4
docker tag registry.cn-hangzhou.aliyuncs.com/kube_containers/kubernetes-dashboard-amd64:v1.8.3 k8s.gcr.io/kubernetes-dashboard-amd64:v1.8.3
docker tag registry.cn-hangzhou.aliyuncs.com/google_containers/kube-state-metrics:v1.3.1 quay.io/coreos/kube-state-metrics:v1.3.1
docker tag registry.cn-hangzhou.aliyuncs.com/google_containers/alertmanager quay.io/prometheus/alertmanager
docker tag registry.cn-hangzhou.aliyuncs.com/k8s-kernelsky/metrics-server-amd64:v0.2.1 gcr.io/google_containers/metrics-server-amd64:v0.2.1
docker tag registry.cn-hangzhou.aliyuncs.com/google_containers/tiller:v2.9.1 gcr.io/kubernetes-helm/tiller:v2.9.1
下载kubernetes-server-linux-amd64.tar.gz中包含镜像文件,可以用docker load < cloud-controller-manager.tar进行安装
docker load < cloud-controller-manager.tar
docker load < kube-aggregator.tar
docker load < kube-apiserver.tar
docker load < kube-controller-manager.tar
docker load < kube-proxy.tar
docker load < kube-scheduler.tar
以下包仍需网络下载
docker pull quay.io/coreos/etcd:v3.3.8
docker pull docker.io/haproxy:1.7-alpine
docker pull docker.io/osixia/keepalived:1.4.5
docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/coredns:1.1.3
docker pull registry.cn-hangzhou.aliyuncs.com/criss/quay.io-calico-typha:v0.7.4
docker pull registry.cn-hangzhou.aliyuncs.com/criss/quay.io-calico-cni:v3.1.3
docker pull registry.cn-beijing.aliyuncs.com/k8s_apps/defaultbackend:1.4
docker pull quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.16.2
docker pull coredns/coredns:1.1.4
docker pull registry.opensource.zalan.do/teapot/external-dns:v0.5.4
docker pull registry.cn-hangzhou.aliyuncs.com/kube_containers/kubernetes-dashboard-amd64:v1.8.3
docker pull quay.io/coreos/prometheus-operator:v0.22.0
docker pull quay.io/coreos/kube-rbac-proxy:v0.3.1
docker pull quay.io/prometheus/prometheus
docker pull grafana/grafana:5.1.0
docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/kube-state-metrics:v1.3.1
docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/alertmanager
docker pull quay.io/prometheus/prometheus:v2.3.1
docker pull quay.io/coreos/prometheus-config-reloader:v0.22.0
docker pull quay.io/coreos/configmap-reload:v0.0.1
docker pull registry.cn-hangzhou.aliyuncs.com/k8s-gcr-io-jxm/pause:3.1
docker pull registry.cn-hangzhou.aliyuncs.com/k8s-kernelsky/metrics-server-amd64:v0.2.1
docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/tiller:v2.9.1
重命名镜像
docker tag k8s.gcr.io/kube-scheduler:v1.11.2 k8s.gcr.io/kube-scheduler-amd64:v1.11.2
docker tag k8s.gcr.io/kube-aggregator:v1.11.2 k8s.gcr.io/kube-aggregator-amd64:v1.11.2
docker tag k8s.gcr.io/kube-apiserver:v1.11.2 k8s.gcr.io/kube-apiserver-amd64:v1.11.2
docker tag k8s.gcr.io/kube-controller-manager:v1.11.2 k8s.gcr.io/kube-controller-manager-amd64:v1.11.2
docker tag k8s.gcr.io/kube-proxy:v1.11.2 k8s.gcr.io/kube-proxy-amd64:v1.11.2
docker tag registry.cn-hangzhou.aliyuncs.com/google_containers/coredns:1.1.3 k8s.gcr.io/coredns:1.1.3
docker tag registry.cn-hangzhou.aliyuncs.com/criss/quay.io-calico-typha:v0.7.4 quay.io/calico/typha:v0.7.4
docker tag registry.cn-hangzhou.aliyuncs.com/criss/quay.io-calico-cni:v3.1.3 quay.io/calico/cni:v3.1.3
docker tag registry.cn-beijing.aliyuncs.com/k8s_apps/defaultbackend:1.4 gcr.io/google_containers/defaultbackend:1.4
docker tag registry.cn-hangzhou.aliyuncs.com/kube_containers/kubernetes-dashboard-amd64:v1.8.3 k8s.gcr.io/kubernetes-dashboard-amd64:v1.8.3
docker tag registry.cn-hangzhou.aliyuncs.com/google_containers/kube-state-metrics:v1.3.1 quay.io/coreos/kube-state-metrics:v1.3.1
docker tag registry.cn-hangzhou.aliyuncs.com/google_containers/alertmanager quay.io/prometheus/alertmanager
docker tag registry.cn-hangzhou.aliyuncs.com/k8s-gcr-io-jxm/pause:3.1 k8s.gcr.io/pause:3.1
docker tag registry.cn-hangzhou.aliyuncs.com/k8s-kernelsky/metrics-server-amd64:v0.2.1 gcr.io/google_containers/metrics-server-amd64:v0.2.1
docker tag registry.cn-hangzhou.aliyuncs.com/google_containers/tiller:v2.9.1 gcr.io/kubernetes-helm/tiller:v2.9.1
以上过程可能启动时间较长,因为需要下载docker镜像,和网速有关,假如进程无法running可以等待一段时间