kubernetes二进制单节点和多节点部署(多节点+dashbord)
kubernetes二进制单节点和多节点部署(多节点+dashbord)kubernetes单节点部署环境准备在 master01 节点上操作上传 master.zip 和 k8s-cert.sh 到 /opt/k8s 目录中,解压 master.zip 压缩包创建kubernetes工作目录创建用于生成CA证书、相关组件的证书和私钥的目录复制CA证书、apiserver相关证书和私钥到 kube
kubernetes二进制单节点和多节点部署(多节点+dashbord)
- kubernetes单节点部署
- 环境准备
- 在 master01 节点上操作
- 上传 master.zip 和 k8s-cert.sh 到 /opt/k8s 目录中,解压 master.zip 压缩包
- 创建kubernetes工作目录
- 创建用于生成CA证书、相关组件的证书和私钥的目录
- 复制CA证书、apiserver相关证书和私钥到 kubernetes工作目录的 ssl 子目录中
- 复制master组件的关键命令文件到 kubernetes工作目录的 bin 子目录中
- 创建 bootstrap token 认证文件
- 二进制文件、token、证书都准备好后,开启 apiserver 服务
- 检查进程是否启动成功
- 查看端口检查
- 查看版本信息
- 启动 scheduler 服务
- 查看 master 节点状态
- 部署 node 组件
- 将node组件加入到k8s集群中
- 将node2节点也加入到k8s集群中
- kubernetes多节点部署
- 部署 Dashboard UI
- Dashboard 介绍
- 在 master01 节点上操作
- 在k8s工作目录中创建dashborad工作目录
- 核心文件官方下载资源地址
- 通过kubectl create 命令创建resources
- 查看类型为 Role,RoleBinding 的资源对象 kubernetes-dashboard-minimal 是否生成
- 证书和密钥创建
- 查看类型为 Secret 的资源对象 kubernetes-dashboard-certs,kubernetes-dashboard-key-holder 是否生成
- 创建容器需要的控制器以及服务账户
- 查看类型为 ServiceAccount,Deployment 的资源对象 kubernetes-dashboard-settings 是否生成
- 将服务提供出去
- 查看创建在指定的 kube-system 命名空间下的 pod 和 service 状态信息
- 执行脚本
- 在 dashboard 工作目录下将生成两个证书
- 重新进行部署(注意:当apply不生效时,先使用delete清除资源,再apply创建资源)
- 由于可能会更换所分配的节点,所以要再次查看一下分配的节点服务器地址和端口号
- 再次进行访问测试,选择使用令牌方式登录,使用 k8s-admin.yaml 文件进行创建令牌
- 查看令牌序列号,取 token: 后面的内容
- 将令牌序列号复制填入到浏览器页面中,点击登录
kubernetes单节点部署
环境准备
Master01 192.168.121.12
Node01 192.168.121.13
Node03 192.168.121.17
在 master01 节点上操作
上传 master.zip 和 k8s-cert.sh 到 /opt/k8s 目录中,解压 master.zip 压缩包
cd /opt/k8s/
unzip master.zip
apiserver.sh
scheduler.sh
controller-manager.sh
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/
vim k8s-cert.sh
chmod +x k8s-cert.sh
./k8s-cert.sh #生成CA证书、相关组件的证书和私钥
ls *pem
admin-key.pem apiserver-key.pem ca-key.pem kube-proxy-key.pem
admin.pem apiserver.pem ca.pem kube-proxy.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.121.12 https://192.168.121.12:2379,https://192.168.121.13:2379,https://192.168.121.17:2379
检查进程是否启动成功
ps aux | grep kube-apiserver
查看端口检查
//k8s通过kube-apiserver这个进程提供服务,该进程运行在单个master节点上。默认有两个端口6443和8080
//安全端口6443用于接收HTTPS请求,用于基于Token文件或客户端证书等认证
netstat -natp | grep 6443
//本地端口8080用于接收HTTP请求,非认证或授权的HTTP请求通过该端口访问API Server
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
查看 master 节点状态
kubectl get componentstatuses #也可以 kubectl get cs
NAME STATUS MESSAGE ERROR
controller-manager Healthy ok
scheduler Healthy ok
etcd-2 Healthy {"health":"true"}
etcd-1 Healthy {"health":"true"}
etcd-0 Healthy {"health":"true"}
部署 node 组件
在 master01 节点上操作
把 kubelet、kube-proxy 拷贝到 node 节点
cd /opt/k8s/kubernetes/server/bin
scp kubelet kube-proxy root@192.168.121.13:/opt/kubernetes/bin/
scp kubelet kube-proxy root@192.168.121.17:/opt/kubernetes/bin/
在 node01 节点上操作
上传 node.zip 到 /opt 目录中,解压 node.zip 压缩包,获得kubelet.sh、proxy.sh
cd /opt/
unzip node.zip
在 master01 节点上操作
创建用于生成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
rz -E
chmod +x kubeconfig.sh
生成kubelet的配置文件
cd /opt/k8s/kubeconfig
./kubeconfig.sh 192.168.121.12 /opt/k8s/k8s-cert/
ls
bootstrap.kubeconfig kubeconfig.sh kube-proxy.kubeconfig
把配置文件 bootstrap.kubeconfig、kube-proxy.kubeconfig 拷贝到 node 节点
cd /opt/k8s/kubeconfig
scp bootstrap.kubeconfig kube-proxy.kubeconfig root@192.168.121.13:/opt/kubernetes/cfg/
scp bootstrap.kubeconfig kube-proxy.kubeconfig root@192.168.121.17:/opt/kubernetes/cfg/
RBAC授权
将预设用户 kubelet-bootstrap 与内置的 ClusterRole system:node-bootstrapper 绑定到一起,使其能够发起 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
将node组件加入到k8s集群中
在 node01 节点上操作
使用kubelet.sh脚本启动kubelet服务
cd /opt/
chmod +x kubelet.sh
./kubelet.sh 192.168.121.13
检查kubelet服务启动
ps aux | grep kubelet
此时还没有生成证书
ls /opt/kubernetes/ssl/
在 master01 节点上操作
检查到 node01 节点的 kubelet 发起的 CSR 请求,Pending 表示等待集群给该节点签发证书
kubectl get csr
通过 CSR 请求
kubectl certificate approve node-csr-NOI-9vufTLIqJgMWq4fHPNPHKbjCXlDGHptj7FqTa8A
再次查看 CSR 请求状态
Approved,Issued 表示已授权 CSR 请求并签发证书
kubectl get csr
查看群集节点状态,成功加入node01节点
kubectl get nodes
将node2节点也加入到k8s集群中
在 node01 节点上操作
自动生成了证书和 kubelet.kubeconfig 文件
ls /opt/kubernetes/cfg/kubelet.kubeconfig
ls /opt/kubernetes/ssl/
加载 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.121.13
systemctl status kube-proxy.service
node02 节点部署
方法一:
//在 node01 节点上将 kubelet.sh、proxy.sh 文件拷贝到 node02 节点
cd /opt/
scp kubelet.sh proxy.sh root@192.168.121.17:/opt/
##### 在 node02 节点上操作 #####
//使用kubelet.sh脚本启动kubelet服务
cd /opt/
chmod +x kubelet.sh
./kubelet.sh 192.168.121.17
##### 在 master01 节点上操作 #####
//在 master01 节点上操作查看 CSR 请求
kubectl get csr
NAME AGE REQUESTOR CONDITION
node-csr-OaH9HpIKh6AKlfdjEKm4C6aJ0UT_1YxNaa70yEAxnsU 15s kubelet-bootstrap Pending
//通过 CSR 请求
kubectl certificate approve node-csr-OaH9HpIKh6AKlfdjEKm4C6aJ0UT_1YxNaa70yEAxnsU
kubectl get csr
NAME AGE REQUESTOR CONDITION
node-csr-OaH9HpIKh6AKlfdjEKm4C6aJ0UT_1YxNaa70yEAxnsU 2m kubelet-bootstrap Approved,Issued
//查看群集中的节点状态
kubectl get nodes
NAME STATUS ROLES AGE VERSION
192.168.121.13 Ready
192.168.121.17 Ready
//加载 ipvs 模块
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.121.17
systemctl status kube-proxy.service
方法二:
//在node01节点操作,把现成的/opt/kubernetes目录和kubelet、kube-proxy的service服务管理文件复制到其他node节点
scp -r /opt/kubernetes/ root@192.168.121.17:/opt/
scp /usr/lib/systemd/system/{kubelet,kube-proxy}.service root@192.168.121.17:/usr/lib/systemd/system/
//在node02节点上操作,进行修改
//首先删除复制过来的证书,等会node02会自行申请证书
cd /opt/kubernetes/ssl/
rm -rf *
//修改配置文件kubelet、kubelet.config、kube-proxy的相关IP地址配置为当前节点的IP地址
cd /opt/kubernetes/cfg
vim kubelet
KUBELET_OPTS="--logtostderr=true \
--v=4 \
--hostname-override=192.168.121.17 \ #修改
......
vim kubelet.config
kind: KubeletConfiguration
apiVersion: kubelet.config.k8s.io/v1beta1
address: 192.168.121.17 #修改
vim kube-proxy
KUBE_PROXY_OPTS="--logtostderr=true \
--v=4 \
--hostname-override=192.168.121.17 \ #修改
//加载 ipvs 模块
modprobe ip_vs
//启动kubelet和kube-proxy服务并设置开机自启
systemctl start kubelet.service
systemctl enable kubelet.service
systemctl start kube-proxy.service
systemctl enable kube-proxy.service
//到master01节点上发现未授权的node02请求,授权node02加入集群
kubectl get csr
NAME AGE REQUESTOR CONDITION
node-csr-P3996HQxx_2PLeo9bxBu7TVPcWgbAWqla5yj8Wa_5ks 15s kubelet-bootstrap Pending
//授权许可加入群集
kubectl certificate approve node-csr-P3996HQxx_2PLeo9bxBu7TVPcWgbAWqla5yj8Wa_5ks
kubectl get csr
kubectl get nodes
kubernetes多节点部署
环境准备
master01 192.168.121.12
master02 192.168.121.18
VIP 192.168.121.100
LB01 192.168.121.19
LB02 192.168.121.20
master02 节点部署
从 master01 节点上拷贝证书文件、各master组件的配置文件和服务管理文件到 master02 节点
scp -r /opt/etcd/ root@192.168.121.18:/opt/
scp -r /opt/kubernetes/ root@192.168.121.18:/opt
scp /usr/lib/systemd/system/{kube-apiserver,kube-controller-manager,kube-scheduler}.service root@192.168.121.18:/usr/lib/systemd/system/
修改配置文件kube-apiserver中的IP
vim /opt/kubernetes/cfg/kube-apiserver
KUBE_APISERVER_OPTS="--logtostderr=true \
--v=4 \
--etcd-servers=https://192.168.80.10:2379,https://192.168.80.11:2379,https://192.168.80.12:2379 \
--bind-address=192.168.121.18 \ #修改
--secure-port=6443 \
--advertise-address=192.168.121.18 \ #修改
......
在 master02 节点上启动各服务并设置开机自启
systemctl start kube-apiserver.service
systemctl enable kube-apiserver.service
systemctl start kube-controller-manager.service
systemctl enable kube-controller-manager.service
systemctl start kube-scheduler.service
systemctl enable kube-scheduler.service
查看node节点状态
ln -s /opt/kubernetes/bin/* /usr/local/bin/
kubectl get nodes
kubectl get nodes -o wide #-o=wide:输出额外信息;对于Pod,将输出Pod所在的Node名
//此时在master02节点查到的node节点状态仅是从etcd查询到的信息,而此时node节点实际上并未与master02节点建立通信连接,因此需要使用一个VIP把node节点与master节点都关联起来
负载均衡部署
配置load balancer集群双机热备负载均衡(nginx实现负载均衡,keepalived实现双机热备)
在lb01、lb02节点上操作
配置nginx的官方在线yum源,配置本地nginx的yum源
cat > /etc/yum.repos.d/nginx.repo << 'EOF'
[nginx]
name=nginx repo
baseurl=http://nginx.org/packages/centos/7/$basearch/
gpgcheck=0
EOF
yum install nginx -y
修改nginx配置文件,配置四层反向代理负载均衡
指定k8s群集2台master的节点ip和6443端口
vim /etc/nginx/nginx.conf
events {
worker_connections 1024;
}
#添加
stream {
log_format main '$remote_addr $upstream_addr - [$time_local] $status $upstream_bytes_sent';
access_log /var/log/nginx/k8s-access.log main;
upstream k8s-apiserver {
server 192.168.121.19:6443;
server 192.168.121.20:6443;
}
server {
listen 6443;
proxy_pass k8s-apiserver;
}
}
http {
......
检查配置文件语法并启动nginx
//检查配置文件语法
nginx -t
//启动nginx服务,查看已监听6443端口
systemctl start nginx
systemctl enable nginx
netstat -natp | grep nginx
部署keepalived服务
yum install keepalived -y
修改keepalived配置文件
vim /etc/keepalived/keepalived.conf
创建nginx状态检查脚本
vim /etc/nginx/check_nginx.sh
#!/bin/bash
#egrep -cv "grep|$$" 用于过滤掉包含grep 或者 $$ 表示的当前Shell进程ID
count=$(ps -ef | grep nginx | egrep -cv "grep|$$")
if [ "$count" -eq 0 ];then
systemctl stop keepalived
fi
chmod +x /etc/nginx/check_nginx.sh
启动keepalived服务(一定要先启动了nginx服务,再启动keepalived服务)
systemctl start keepalived
systemctl enable keepalived
ip a #查看VIP是否生成
修改node节点上的bootstrap.kubeconfig,kubelet.kubeconfig配置文件为VIP
cd /opt/kubernetes/cfg/
vim bootstrap.kubeconfig
server: https://192.168.80.100:6443
vim kubelet.kubeconfig
server: https://192.168.80.100:6443
vim kube-proxy.kubeconfig
server: https://192.168.80.100:6443
重启kubelet和kube-proxy服务
systemctl restart kubelet.service
systemctl restart kube-proxy.service
在lb01上查看nginx的k8s日志
tail /var/log/nginx/k8s-access.log
在 master01 节点上操作
//测试创建pod
kubectl run nginx --image=nginx
//查看Pod的状态信息
kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-dbddb74b8-nf9sk 0/1 ContainerCreating 0 33s #正在创建中
kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-dbddb74b8-nf9sk 1/1 Running 0 80s #创建完成,运行中
kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE
nginx-dbddb74b8-26r9l 1/1 Running 0 10m 172.17.36.2 192.168.80.15 <none>
//READY为1/1,表示这个Pod中有1个容器
//在对应网段的node节点上操作,可以直接使用浏览器或者curl命令访问
curl 172.17.36.2
//这时在master01节点上查看nginx日志,发现没有权限查看
kubectl logs nginx-dbddb74b8-nf9sk
Error from server (Forbidden): Forbidden (user=system:anonymous, verb=get, resource=nodes, subresource=proxy) ( nginx-dbddb74b8-nf9sk)
//在master01节点上,将cluster-admin角色授予用户system:anonymous
kubectl create clusterrolebinding cluster-system-anonymous --clusterrole=cluster-admin --user=system:anonymous
clusterrolebinding.rbac.authorization.k8s.io/cluster-system-anonymous created
//再次查看nginx日志
kubectl logs nginx-dbddb74b8-nf9sk
部署 Dashboard UI
Dashboard 介绍
仪表板是基于Web的Kubernetes用户界面。您可以使用仪表板将容器化应用程序部署到Kubernetes集群,对容器化应用程序进行故障排除,并管理集群本身及其伴随资源。您可以使用仪表板来概述群集上运行的应用程序,以及创建或修改单个Kubernetes资源(例如部署,作业,守护进程等)。例如,您可以使用部署向导扩展部署,启动滚动更新,重新启动Pod或部署新应用程序。仪表板还提供有关群集中Kubernetes资源状态以及可能发生的任何错误的信息。
在 master01 节点上操作
在k8s工作目录中创建dashborad工作目录
mkdir /opt/k8s/dashboard
cd /opt/k8s/dashboard
//上传Dashboard.zip压缩包,并解压,一共有7个yaml文件,包含5个构建该界面的核心文件,一个k8s-admin.yaml文件是自己写的,用来生成待会在浏览器中登录时所用的令牌;一个dashboard-cert.sh,用来快速生成解决谷歌浏览器加密通信问题所需的证书文件
核心文件官方下载资源地址
https://github.com/kubernetes/kubernetes/tree/master/cluster/addons/dashboard
dashboard-configmap.yaml dashboard-rbac.yaml dashboard-service.yaml dashboard-controller.yaml dashboard-secret.yaml k8s-admin.yaml dashboard-cert.sh
------------------------------------------------------------------------------------------
1、dashboard-rbac.yaml:用于访问控制设置,配置各种角色的访问控制权限及角色绑定(绑定角色和服务账户),内容中包含对应各种角色所配置的规则(rules)
2、dashboard-secret.yaml:提供令牌,访问API服务器所用(个人理解为一种安全认证机制)
3、dashboard-configmap.yaml:配置模板文件,负责设置Dashboard的文件,ConfigMap提供了将配置数据注入容器的方式,保证容器中的应用程序配置从 Image 内容中解耦
4、dashboard-controller.yaml:负责控制器及服务账户的创建,来管理pod副本
5、dashboard-service.yaml:负责将容器中的服务提供出去,供外部访问
通过kubectl create 命令创建resources
cd /opt/k8s/dashboard
1、规定kubernetes-dashboard-minimal该角色的权限:例如其中具备获取更新删除等不同的权限
kubectl create -f dashboard-rbac.yaml
//有几个kind就会有几个结果被创建,格式为kind+apiServer/name
role.rbac.authorization.k8s.io/kubernetes-dashboard-minimal created
rolebinding.rbac.authorization.k8s.io/kubernetes-dashboard-minimal created
查看类型为 Role,RoleBinding 的资源对象 kubernetes-dashboard-minimal 是否生成
kubectl get role,rolebinding -n kube-system
//-n kube-system 表示查看指定命名空间中的pod,缺省值为default
证书和密钥创建
kubectl create -f dashboard-secret.yaml
secret/kubernetes-dashboard-certs created
secret/kubernetes-dashboard-key-holder created
查看类型为 Secret 的资源对象 kubernetes-dashboard-certs,kubernetes-dashboard-key-holder 是否生成
kubectl get secret -n kube-system
创建容器需要的控制器以及服务账户
kubectl create -f dashboard-controller.yaml
serviceaccount/kubernetes-dashboard created
deployment.apps/kubernetes-dashboard created
查看类型为 ServiceAccount,Deployment 的资源对象 kubernetes-dashboard-settings 是否生成
kubectl get serviceaccount,deployment -n kube-system
将服务提供出去
kubectl create -f dashboard-service.yaml
service/kubernetes-dashboard created
查看创建在指定的 kube-system 命名空间下的 pod 和 service 状态信息
kubectl get pods,svc -n kube-system -o wide
//svc 为 service 的缩写,可用 kubectl api-resources 查看
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE
pod/kubernetes-dashboard-7dffbccd68-c6d24 1/1 Running 1 11m 172.17.26.2 192.168.80.11 <none>
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
service/kubernetes-dashboard NodePort 10.0.0.75 <none> 443:30001/TCP 11m k8s-app=kubernetes-dashboard
//dashboard分配给了node01服务器,访问的入口是30001端口,打开浏览器访问 https://nodeIP:30001 来进行测试
火狐浏览器可直接访问:https://192.168.80.11:30001
谷歌浏览器则因为缺少加密通信的认证证书,导致无法直接访问。可通过 菜单->更多工具->开发者工具->Security 查看访问失败的原因。
//解决谷歌浏览器加密通信问题,使用的脚本 dashboard-cert.sh 来快速生成证书文件
cd /opt/k8s/dashboard/
vim dashboard-controller.yaml
......
args:
# PLATFORM-SPECIFIC ARGS HERE
- --auto-generate-certificates
#在文件的第47行下面添加以下两行,指定加密(tls)的私钥和证书文件
- --tls-key-file=dashboard-key.pem
- --tls-cert-file=dashboard.pem
执行脚本
cd /opt/k8s/dashboard/
chmod +x dashboard-cert.sh
./dashboard-cert.sh /opt/k8s/k8s-cert/
在 dashboard 工作目录下将生成两个证书
ls *.pem
dashboard.pem dashboard-key.pem
重新进行部署(注意:当apply不生效时,先使用delete清除资源,再apply创建资源)
kubectl apply -f dashboard-controller.yaml
由于可能会更换所分配的节点,所以要再次查看一下分配的节点服务器地址和端口号
kubectl get pods,svc -n kube-system -o wide
再次进行访问测试,选择使用令牌方式登录,使用 k8s-admin.yaml 文件进行创建令牌
cd /opt/k8s/dashboard/
kubectl create -f k8s-admin.yaml
#获取token简要信息,名称为dashboard-admin-token-xxxxx
kubectl get secrets -n kube-system
NAME TYPE DATA AGE
dashboard-admin-token-kpmm8 kubernetes.io/service-account-token 3
default-token-7dhwm kubernetes.io/service-account-token 3
kubernetes-dashboard-certs Opaque 11
kubernetes-dashboard-key-holder Opaque 2
kubernetes-dashboard-token-jn94c kubernetes.io/service-account-token 3
查看令牌序列号,取 token: 后面的内容
kubectl describe secrets dashboard-admin-token-kpmm8 -n kube-system
将令牌序列号复制填入到浏览器页面中,点击登录
先通过 kubectl get pods 命令查看一下集群中是否有资源在运行,再在 Dashboard UI 界面中命令空间选 default,
点击侧边栏中的“容器组”,点击容器名称,进入一个页面,点击右上方的“运行命令”或”日志“控件会弹出另一个额外页面,可在“运行命令”输入 curl <podip> 命令访问容器,再通过dashboard页面查看日志更新结果。
更多推荐
所有评论(0)