kubernetes安装文档

一 系统配置

1 关闭SELIUX

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启动,之后等会就会看到熟悉的页面了。要说一点的是,可能会在下图所示页面卡顿一会,等会就行了

2 关闭防火墙

systemctl stop firewalld 
systemctl disable firewalld

3 配root免登录

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

4 配置/etc/hosts

vi /etc/hosts
192.168.200.221 k8smaster
192.168.200.222 k8smaster2
192.168.200.223 k8snode

5 关闭系统swap

swapoff -a && sysctl -w vm.swappiness=0
sed '/swap.img/d' -i /etc/fstab

注释掉/etc/fstab中swap挂载

6 设置系统参数

modprobe br_netfilter
cat <<EOF | tee /etc/sysctl.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

二 安装DOCKER CE

以下内容来自于官方英文文档,通过yum安装所以需要接通外网,系统版本CENTOS7最新版
所有机器全部安装

1 安装repository

在新主机上首次安装Docker CE之前,需要设置Docker存储库。之后,您可以从存储库安装和更新Docker。
设置存储库

1.1 卸载旧版本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

1.2 安装依赖包

yum install -y yum-utils \
  device-mapper-persistent-data \
  lvm2

1.3 设置repository

yum-config-manager \
    --add-repo \
https://download.docker.com/linux/centos/docker-ce.repo

注:若无法下载可以手动下载之后在进行安装

yum-config-manager --add-repo /usr/MyWorkSpace/docker-ce.repo

1.4 启用docker-ce-edge和docker-ce-test

yum-config-manager --enable docker-ce-edge
yum-config-manager --enable docker-ce-test

1.5 安装DOCKER CE

yum -y install docker-ce

1.6 rpm安装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

1.7 设置docker自启动

systemctl enable docker && systemctl start docker

三 安装Kubernetes

1 下载Kubernetes二进制包

https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.11.md#client-binaries
源码在github上自行下载

2 安装Kubernetes.

2.1 配置kubernetes-server(所有节点)

在所有节点上配置kubectl,kubectl在kubernetes-server-linux-amd64.tar.gz中
将kubectl拷贝到如下目录

cp kubectl /usr/local/bin/

2.2 配置kubernetes-node

将kubernetes-node-linux-amd64.tar.gz中的所有文件拷贝到

cp * /usr/local/bin/

2.3 配置Kubernetes CNI(所以节点)

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

2.4 安装CFSSL

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

3建立CA与产生TLS凭证

3.1 在master1中获取部署文件

git clone https://github.com/kairen/k8s-manual-files.git ~/k8s-manual-files
cd ~/k8s-manual-files/pki

3.2 ETCD

在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/

3.3 Kubernetes组件

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位址。

3.4建立TLS凭证

3.4.1 API Server
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

3.4.2 Front Proxy Client

此凭证将被用于 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
3.4.3 Controller Manager

凭证会建立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
3.4.4 Scheduler

凭证会建立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
3.4.5 Admin

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
3.4.6 Masters Kubelet

这边使用 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
3.4.7 Service Account Key

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

4 Kubernetes Masters

本节将说明如何部署与设定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 来观察启动的容器状况。

4.1部署与设定

在首先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 (dockerpsqa)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

4.2 建立 TLS Bootstrapping

由于本教程采用 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

4.2.2接着在k8s-m1建立TLS Bootstrap Secret

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

4.2.3建立TLS Bootstrap Autoapprove RBAC来提供自动受理CSR

$ 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

4.3验证Master节点

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

5 Kubernetes Nodes

本节将说明如何建立与设定 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

5.1部署与设定

确认文件都复制后,即可设定所有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

5.2验证Node节点

完成后,在任意一台master节点复制Admin kubeconfig文件,并通过简单指令验证:

kubectl get csr

注:
1、可以调用kubectl get csr查看是否有csr处于pending的状态,有的话,调用kubectl certificate approve $CSR将其确认即可

6 Kubernetes Core Addons部署

当完成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

6.1 Kubernetes Proxy

启动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

6.2 CoreDNS

本节将通过 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则会出问题。

7 Kubernetes集群网路

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 集群网络。

7.1网路部署与设定

从上述了解 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。

8 Kubernetes Extra Addons部署

本节说明如何部署一些官方常用的额外 Addons,如 Dashboard、Metrics Server 与 Ingress Controller 等等。
所有 Addons 部署文件均存已放至k8s-manual-files中,因此在k8s-m1进入该目录,并依序下小节建立:

$ cd ~/k8s-manual-files

8.1 Ingress Controller

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 域名。

8.2 External DNS

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

8.3 Dashboard

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}'

8.4 Prometheus

由于 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
访问:
这里写链接内容

8.5 Metrics Server

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

8.6 Helm Tiller Server

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被墙,所以只能想别的办法,现在将阿里云的处理方式附录到以下,本地下载与网络下载选一个就行,所有节点都需要下载

1 设置yum源

cat <<EOF > /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

2 下载镜像

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

3 本地安装

下载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

4、进程无法启动

以上过程可能启动时间较长,因为需要下载docker镜像,和网速有关,假如进程无法running可以等待一段时间

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值