目录
如果之前部署的k8s中途暂停了,导致flannel(或Docker)网络不通,可以配置ipv4转发功能解决
cat >> /etc/sysctl.conf << EOF
net.ipv4.ip_forward=1
EOF
五.部署 master 组件
1.在 master01 节点上操作
上传master.zip 和k8s-cert.sh 到/opt/k8s 目录中,解压master.zip 压缩包
cd /opt/k8s/
unzip master.zip
chmod +x *.sh
创建kubernetes工作目录
mkdir -p /opt/kubernetes/{cfg,bin,ssl}
创建用于生成CA证书、相关组件的证书和私钥的目录
mkdir /opt/k8s/k8s-cert
mv /opt/k8s/k8s-cert.sh /opt/k8s/k8s-cert
cd /opt/k8s/k8s-cert/
./k8s-cert.sh #生成CA证书、相关组件的证书和私钥
ls *pem
controller-manager 和 kube-scheduler 设置为只调用当前机器的 apiserver, 使用127.0.0.1:8080 通信,因此不需要签发证书
复制CA证书、apiserver 相关证书和私钥到kubernetes. 工作目录的ssl子目录中
cp ca*pem apiserver*pem /opt/kubernetes/ssl/
上传kubernetes-server-linux-amd64.tar.gz 到/opt/k8s/ 目录中,解压kubernetes 压缩包
cd /opt/k8s/
tar zxvf kubernetes-server-linux-amd64.tar.gz
复制master组件的关键命令文件到kubernetes. 工作目录的bin子目录中
cd /opt/k8s/kubernetes/server/bin
cp kube-apiserver kubectl kube-controller-manager kube-scheduler /opt/kubernetes/bin/
ln -s /opt/kubernetes/bin/* /usr/local/bin/
创建bootstrap token 认证文件,apiserver 启动时会调用,然后就相当于在集群内创建了一个这个用户,接下来就可以用RBAC给他授权
cd /opt/k8s/
vim token.sh
#!/bin/bash
#获取随机数前16个字节内容,以十六进制格式输出,并删除其中空格
BOOTSTRAP_TOKEN=$(head -c 16 /dev/urandom | od -An -t x | tr -d ' ')
#生成token.csv 文件,按照Token序列号,用户名,UID,用户组的格式生成
cat > /opt/kubernetes/cfg/token.csv <<EOF
${BOOTSTRAP_TOKEN},kubelet-bootstrap,10001,"system:kubelet-bootstrap"
EOF
chmod +x token.sh
./token.sh
cat /opt/kubernetes/cfg/token.csv
二进制文件、token、证书都准备好后,开启 apiserver 服务
cd /opt/k8s/
./apiserver.sh 192.168.111.171 https://192.168.111.171:2379,https://192.168.111.173:2379,https://192.168.111.175:2379
#检查进程是否启动成功
ps aux | grep kube-apiserver
k8s通过kube- apiserver这 个进程提供服务,该进程运行在单个master节点上。默认有两个端口6443和8080
安全端口6443用于接收HTTPS请求,用于基于Token文件或客户端证书等认证
本地端口8080用于接收HTTP请求,非认证或授权的HTTP请求通过该端口访问APIServer
netstat -natp | grep 6443
netstat -natp | grep 8080
查看版本信息(必须保证apiserver启动正常,不然无法查询到server的版本信息)
kubectl version
启动scheduler 服务
cd /opt/k8s/
./scheduler.sh 127.0.0.1
ps aux | grep kube-scheduler
启动controller-manager服务
cd /opt/k8s/
./controller-manager.sh 127.0.0.1
查看节点状态
kubectl get componentstatuses
或
kubectl get cs
六.部署 Woker Node 组件
1.在 master01 节点上操作
把kubelet、 kube-proxy拷贝到node 节点
cd /opt/k8s/kubernetes/server/bin
scp kubelet kube-proxy root@192.168.111.173:/opt/kubernetes/bin/
scp kubelet kube-proxy root@192.168.111.175:/opt/kubernetes/bin/
2.在 node01 节点上操作
上传node.zip 到/opt 目录中,解压node.zip 压缩包,获得kubelet.sh、proxy.sh
cd /opt/
unzip node.zip
3.在master1节点上操作
创建用于生成kubelet的配置文件的目录
mkdir /opt/k8s/kubeconfig
上传 kubeconfig.sh 文件到/opt/k8s/kubeconfig 目录中
kubeconfig.sh文件包含集群参数(CA 证书、API Server 地址),客户端参数(上面生成的证书和私钥),集群context上下文参数(集群名称、用户名)。Kubenetes 组件(如kubelet、 kube-proxy) 通过启动时指定不同的kubeconfig文件可以切换到不同的集群,连接到apiserver
cd /opt/k8s/kubeconfig
chmod +x kubeconfig.sh
生成kubelet的配置文件
cd /opt/k8s/kubeconfig
./kubeconfig.sh 192.168.111.171 /opt/k8s/k8s-cert/
ls
把配置文件bootstrap.kubeconfig、kube-proxy.kubeconfig拷贝到node节点
cd /opt/k8s/kubeconfig
scp bootstrap.kubeconfig kube-proxy.kubeconfig root@192.168.111.173:/opt/kubernetes/cfg/
scp bootstrap.kubeconfig kube-proxy.kubeconfig root@192.168.111.175:/opt/kubernetes/cfg/
RBAC授权,将预设用户kubelet-bootatrap 与内置的ClusterRole system:node-bootatrapper 绑定到一起,使其能够发起CSR请求
kubectl create clusterrolebinding kubelet-bootstrap --clusterrole=system:node-bootstrapper --user=kubelet-bootstrap
kubelet采用TLS Bootstrapping 机制,自动完成到kube -apiserver的注册,在node节点量较大或者后期自动扩容时非常有用。
Master apiserver 启用TLS 认证后,node 节点kubelet 组件想要加入集群,必须使用CA签发的有效证书才能与apiserver 通信,当node节点很多时,签署证书是一件很繁琐的事情。因此Kubernetes 引入了TLS bootstraping 机制来自动颁发客户端证书,kubelet会以一个低权限用户自动向apiserver 申请证书,kubelet 的证书由apiserver 动态签署。kubelet首次启动通过加载bootstrap.kubeconfig中的用户Token 和apiserver CA证书发起首次CSR请求,这个Token被预先内置在apiserver 节点的token.csv 中,其身份为kubelet-bootstrap 用户和system: kubelet- bootstrap用户组:想要首次CSR请求能成功(即不会被apiserver 401拒绝),则需要先创建一个ClusterRoleBinding, 将kubelet-bootstrap 用户和system:node - bootstrapper内置ClusterRole 绑定(通过kubectl get clusterroles 可查询),使其能够发起CSR认证请求。
TLS bootstrapping 时的证书实际是由kube-controller-manager组件来签署的,也就是说证书有效期是kube-controller-manager组件控制的; kube-controller-manager 组件提供了一个--experimental-cluster-signing-duration参数来设置签署的证书有效时间:默认为8760h0m0s, 将其改为87600h0m0s, 即10年后再进行TLS bootstrapping 签署证书即可。
也就是说kubelet 首次访问API Server 时,是使用token 做认证,通过后,Controller Manager 会为kubelet生成一个证书,以后的访问都是用证书做认证了。
查看角色
kubectl get clusterroles | grep system:node-bootstrapper
查看已授权的角色
kubectl get clusterrolebinding
4.在 node01 节点上操作
使用kubelet.sh脚本启动kubelet服务
cd /opt/
chmod +x kubelet.sh
./kubelet.sh 192.168.111.173
检查kubelet服务启动
ps aux | grep kubelet
此时还没有生成证书
ls /opt/kubernetes/ssl/
5.在 master01 节点上操作
检查到node1 节点的kubelet 发起的CSR请求,Pending 表示等待集群给该节点签发证书.
kubectl get csr
通过CSR请求
kubectl certificate approve node-csr-qTmgz9S260ZWb5VO_x0oYetEUqzNiNAnuwVTsZS7QXg
再次查看CSR请求状态,Approved, Issued表示已授权CSR请求并签发证书
kubectl get csr
查看群集节点状态,成功加入node1节点
kubectl get nodes
6.在 node01 节点上操作
自动生成了证书和kubelet.kubeconfig 文件
加载ip_vs模块
for i in $(ls /usr/lib/modules/$(uname -r)/kernel/net/netfilter/ipvs|grep -o "^[^.]*");do echo $i; /sbin/modinfo -F filename $i >/dev/null 2>&1 && /sbin/modprobe $i;done
使用proxy.sh脚本启动proxy服务
cd /opt/
chmod +x proxy.sh
./proxy.sh 192.168.111.173
systemctl status kube-proxy.service
7.node02 节点部署(方法一)
在node1 节点上将kubelet.sh、 proxy.sh 文件拷贝到node2 节点
cd /opt/
scp kubelet.sh proxy.sh root@192.168.111.175:/opt/
node02 节点部署
使用kubelet.sh脚本启动kubelet服务
cd /opt/
chmod +x kubelet.sh
./kubelet.sh 192.168.111.175
在 master01 节点上操作
使用kubelet.sh脚本启动kubelet服务
kubectl get csr
通过CSR请求
kubectl certificate approve node-csr-7bDpWFqqtvBpuqHIiZVryIGnoUONdTatGFRKdOTBCCA
再次查看CSR请求状态,Approved, Issued表示已授权CSR请求并签发证书
kubectl get csr
查看群集节点状态
kubectl get nodes
加载ip_vs模块
for i in $(ls /usr/lib/modules/$(uname -r)/kernel/net/netfilter/ipvs|grep -o "^[^.]*");do echo $i; /sbin/modinfo -F filename $i >/dev/null 2>&1 && /sbin/modprobe $i;done
使用proxy.sh脚本启动proxy服务
cd /opt/
chmod +x proxy.sh
./proxy.sh 192.168.111.175
systemctl status kube-proxy.service
创建一个镜像并查看
kubectl create deployment nginx-test --image=nginx:1.14
kubectl get pod
查看容器详细信息
kubectl get pod -o wide #查看容器详细信息
在node节点查看能否进入容器
docker ps -a
docker exec -it d14bcf3f8fb7