目录
1.复制证书到kubernetes.工作目录的ssl子目录报错
(1) 架构
(2)kube- apiserver
k8s通过kube- apiserver这 个进程提供服务,该进程运行在单个master节点上。默认有两个端口6443和8080
安全端口6443用于接收HTTPS请求,用于基于Token文件或客户端证书等认证
本地端口8080用于接收HTTP请求,非认证或授权的HTTP请求通过该端口访问APIServer
(3) kubeconfig.sh
kubeconfig.sh文件包含集群参数(CA 证书、API Server 地址),客户端参数(上面生成的证书和私钥),集群context上下文参数(集群名称、用户名)。Kubenetes 组件(如kubelet、 kube-proxy) 通过启动时指定不同的kubeconfig文件可以切换到不同的集群,连接到apiserver
(4) kubelet
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生成一个证书,以后的访问都是用证书做认证了。
(1)在 master01 节点上操作
- cd /opt/k8s/
- unzip master.zip
-
- chmod +x *.sh
(2)创建kubernetes工作目录
mkdir -p /opt/kubernetes/{cfg,bin,ssl}
(3)创建用于生成CA证书、相关组件的证书和私钥的目录
- mkdir /opt/k8s/k8s-cert
- mv /opt/k8s/k8s-cert.sh /opt/k8s/k8s-cert
- cd /opt/k8s/k8s-cert/
- chmod +x *.sh
- ./k8s-cert.sh #生成CA证书、相关组件的证书和私钥
-
- ls *pem
(4)复制证书
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
(5)开启 apiserver 服务
二进制文件、token、证书都准备好后,开启 apiserver 服务
- cd /opt/k8s/
-
- ./apiserver.sh 192.168.204.171 https://192.168.204.171:2379,https://192.168.204.173:2379,https://192.168.204.175:2379
-
-
- #检查进程是否启动成功
- ps aux | grep kube-apiserver
查询端口
- netstat -natp | grep 6443
-
- netstat -natp | grep 8080
查看版本信息(必须保证apiserver启动正常,不然无法查询到server的版本信息)
kubectl version
(6)启动scheduler 服务
- cd /opt/k8s/
- ./scheduler.sh 127.0.0.1
-
- ps aux | grep kube-scheduler
查看节点状态
- kubectl get componentstatuses
- 或
- kubectl get cs
(7) 启动controller-manager服务
- cd /opt/k8s/
- ./controller-manager.sh 127.0.0.1
查看节点状态
- kubectl get componentstatuses
- 或
- kubectl get cs
(1)在 master01 节点上操作
把kubelet、 kube-proxy拷贝到node 节点
- cd /opt/k8s/kubernetes/server/bin
- scp kubelet kube-proxy root@192.168.204.173:/opt/kubernetes/bin/
- scp kubelet kube-proxy root@192.168.204.175:/opt/kubernetes/bin/
(2)在 node01 节点上操作
上传node.zip 到/opt 目录中,解压node.zip 压缩包,获得kubelet.sh、proxy.sh
- cd /opt/
- unzip node.zip
(1)创建用于生成kubelet的配置文件的目录
mkdir /opt/k8s/kubeconfig
(2)上传 kubeconfig.sh 文件到/opt/k8s/kubeconfig 目录中
- cd /opt/k8s/kubeconfig
- chmod +x kubeconfig.sh
(3)生成kubelet的配置文件
- cd /opt/k8s/kubeconfig
- ./kubeconfig.sh 192.168.204.171 /opt/k8s/k8s-cert/
-
- ls
(4)把配置文件bootstrap.kubeconfig、kube-proxy.kubeconfig拷贝到node节点
- cd /opt/k8s/kubeconfig
- scp bootstrap.kubeconfig kube-proxy.kubeconfig root@192.168.204.173:/opt/kubernetes/cfg/
- scp bootstrap.kubeconfig kube-proxy.kubeconfig root@192.168.204.175:/opt/kubernetes/cfg/
RBAC授权,将预设用户kubelet-bootatrap 与内置的ClusterRole system:node-bootatrapper 绑定到一起,使其能够发起CSR请求
kubectl create clusterrolebinding kubelet-bootstrap --clusterrole=system:node-bootstrapper --user=kubelet-bootstrap
(5)查看角色
kubectl get clusterroles | grep system:node-bootstrapper
查看已授权的角色
kubectl get clusterrolebinding
(1)使用kubelet.sh脚本启动kubelet服务
- cd /opt/
- chmod +x kubelet.sh
- ./kubelet.sh 192.168.204.173
(2)检查kubelet服务启动
ps aux | grep kubelet
此时还没有生成证书
ls /opt/kubernetes/ssl/
(1)检查到node1 节点的kubelet 发起的CSR请求,Pending 表示等待集群给该节点签发证书
kubectl get csr
(2)通过CSR请求
kubectl certificate approve node-csr-Y4fiQXiK38SS0LtDOKASTyMKsqnFXA10IOlW0-baLrg
(3)再次查看CSR请求状态,Approved, Issued表示已授权CSR请求并签发证书
kubectl get csr
(4)查看群集节点状态,成功加入node1节点
kubectl get nodes
(1)自动生成了证书和kubelet.kubeconfig 文件
- ls /opt/kubernetes/cfg/kubelet.kubeconfig
-
- ls /opt/kubernetes/ssl/
(2)加载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
(3) 使用proxy.sh脚本启动proxy服务
- cd /opt/
- chmod +x proxy.sh
- ./proxy.sh 192.168.111.173
-
- systemctl status kube-proxy.service
(1) 在node1 节点上将kubelet.sh、 proxy.sh 文件拷贝到node2 节点
- cd /opt/
- scp kubelet.sh proxy.sh root@192.168.204.175:/opt/
(2)node02 节点部署
使用kubelet.sh脚本启动kubelet服务
- cd /opt/
- chmod +x kubelet.sh
- ./kubelet.sh 192.168.204.175
(3) 在 master01 节点上操作
使用kubelet.sh脚本启动kubelet服务
kubectl get csr
通过CSR请求
kubectl certificate approve node-csr-Stux3Mk16W9oyKNn9QzVrrtz3N-B6LBtnL8_jLsbBzE
再次查看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.204.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
由实验:二进制部署K8S单Master架构(一)继续进行
表1 K8S环境
主机 | IP | 软件 | 硬件 |
k8s集群master01 | 192.168.204.171 | kube-apiserver kube-controller-manager kube-scheduler etcd | 4核4G |
k8s集群node1 | 192.168.204.173 | kubelet kube-proxy docker flannel | 4核4G |
k8s集群node2 | 192.168.204.175 | kubelet kube-proxy docker flannel | 4核4G |
(1)在 master01 节点上操作
(2)创建kubernetes工作目录
(3)创建用于生成CA证书、相关组件的证书和私钥的目录
(4)复制证书
controller-manager 和 kube-scheduler 设置为只调用当前机器的 apiserver, 使用127.0.0.1:8080 通信,因此不需要签发证书
复制CA证书、apiserver 相关证书和私钥到kubernetes. 工作目录的ssl子目录中
上传kubernetes-server-linux-amd64.tar.gz 到/opt/k8s/ 目录中,解压kubernetes 压缩包
复制master组件的关键命令文件到kubernetes.工作目录的bin子目录中
创建bootstrap token 认证文件,apiserver 启动时会调用,然后就相当于在集群内创建了一个这个用户,接下来就可以用RBAC给他授权
(5)开启 apiserver 服务
二进制文件、token、证书都准备好后,开启 apiserver 服务
查询端口
查看版本信息(必须保证apiserver启动正常,不然无法查询到server的版本信息)
(6)启动scheduler 服务
查看节点状态,目前controller-manager 节点还处于未健康的状态
(7)启动controller-manager服务
所有节点都健康
(1)在 master01 节点上操作
把kubelet、 kube-proxy拷贝到node 节点
(2)在 node01 节点上操作
上传node.zip 到/opt 目录中,解压node.zip 压缩包,获得kubelet.sh、proxy.sh
(1)创建用于生成kubelet的配置文件的目录
(2)上传 kubeconfig.sh 文件到/opt/k8s/kubeconfig 目录中
(3)生成kubelet的配置文件
(4)把配置文件bootstrap.kubeconfig、kube-proxy.kubeconfig拷贝到node节点
RBAC授权,将预设用户kubelet-bootatrap 与内置的ClusterRole system:node-bootatrapper 绑定到一起,使其能够发起CSR请求
(5)查看角色
查看已授权的角色
(1)使用kubelet.sh脚本启动kubelet服务
(2)检查kubelet服务启动
此时还没有生成证书
(1)检查到node1 节点的kubelet 发起的CSR请求,Pending 表示等待集群给该节点签发证书
(2)通过CSR请求
(3)再次查看CSR请求状态,Approved, Issued表示已授权CSR请求并签发证书
(4)查看群集节点状态,成功加入node1节点
(1)自动生成了证书和kubelet.kubeconfig 文件
(2)加载ip_vs模块
(3) 使用proxy.sh脚本启动proxy服务
(1) 在node1 节点上将kubelet.sh、 proxy.sh 文件拷贝到node2 节点
(2)node02 节点部署
使用kubelet.sh脚本启动kubelet服务
(3) 在 master01 节点上操作
使用kubelet.sh脚本启动kubelet服务
通过CSR请求
再次查看CSR请求状态,Approved, Issued表示已授权CSR请求并签发证书
查看群集节点状态
加载ip_vs模块
使用proxy.sh脚本启动proxy服务
创建一个镜像并查看
查看容器详细信息
在node节点查看能否进入容器
(1)报错
无法获取"apiserver*pem" 的文件状态(stat): 没有那个文件或目录
(2)原因分析
k8s-cert.sh 配置文件未删除注释
(3)解决方法
删除注释
修改前:
修改后:
成功
k8s通过kube- apiserver这 个进程提供服务,该进程运行在单个master节点上。默认有两个端口6443和8080:
安全端口6443用于接收HTTPS请求,用于基于Token文件或客户端证书等认证
本地端口8080用于接收HTTP请求,非认证或授权的HTTP请求通过该端口访问APIServer