【CKA考试笔记】三、kubernetes集群管理

实验环境

完成集群初始化的集群1、集群2
集群1：
（vms21）192.168.26.21——master1
（vms22）192.168.26.22——worker1-1
（vms23）192.168.26.23——worker1-2
集群2：
（vms61）192.168.26.61——master2
（vms62）192.168.26.62——worker2-1

一、查看集群配置信息

老版本中可以使用kubeadm config view查看，但是现在已经废弃了
现版本中查看集群配置信息

kubectl get cm kubeadm-config -o yaml -n kube-system

podSubnet——pod网段
serviceSubnet——service-svc网段
imageRepository——镜像源
kubernetesVersion——k8s版本号
…

二、查看各节点所使用的runtime是什么

kubectl get nodes -o wide

三、集群缩容

集群中删除某个worker节点

#先清除这个节点上的pod（安全驱逐节点上面所有的 pod）
kubectl drain [节点名] --ignore-daemonsets
#执行后节点STATUS变为Ready,SchedulingDisabled
#删除节点
kubectl delete nodes [节点名]

四、集群扩容

新增节点到集群

#1.获取加入集群的命令
kubeadm token create --print-join-command
#2.将生成类似如下命令，复制并输入执行
kubeadm join 192.168.26.21:6443 --token [xxx...]\--discovery-token-ca-cert-hash sha256:[xxx...]
#若命令执行过程中遇到某个报错了（例如对于曾经加入过集群的节点，现已经删除了，再次加入集群会报错），将报错解决后，这时直接执行加入集群的命令会报错，需要输入kubeadm reset恢复出厂设置（只需在当前节点机器上reset），然后再重新输入命令加入集群
kubeadm reset

五、恢复出厂设置reset、重新初始化集群

kubeadm reset

注意点：
1.各个worker节点在加入集群时报错，可以在该节点机器上reset一下，再去加入集群
2.master上reset后，需要重新初始化集群、重新安装calico
若master上执行了reset操作，进行重新初始化集群，初始化好之后，查看各节点STATUS虽然为Ready，但是也需要重新安装calico（正常情况下，没有安装calico时，STATUS为NotReady）
——因为master上reset之后，整个calico环境也被重置了，但是calico的历史文件并没有被删除，仍保留在 /etc/cni/net.d/*
若将 /etc/cni/net.d/下的文件删除（只删除里面的文件，不删除该目录）rm -rf /etc/cni/net.d/*，STATUS就会变为NotReady，重新安装calico后，会再次生成这些文件

实验：删除集群中所有节点，并重新初始化集群

#1.对所有节点drain操作
kubectl drain vms21.rhce.cc --ignore-daemonsets
kubectl drain vms22.rhce.cc --ignore-daemonsets
kubectl drain vms23.rhce.cc --ignore-daemonsets
#2.删除所有节点
kubectl delete nodes vms21.rhce.cc
kubectl delete nodes vms22.rhce.cc
kubectl delete nodes vms23.rhce.cc
#3.此时，若直接初始化会报错，需要先在master上reset
kubeadm reset
#4.删除旧的/root/.kube/config文件
rm -rf /root/.kube/config
#5.master上初始化集群，设置pod网段为10.244.0.0/16
kubeadm init --image-repository registry.aliyuncs.com/google_containers --kubernetes-version=v1.24.2 --pod-network-cidr=10.244.0.0/16
#6.创建.kube/config认证文件
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
#7.各worker节点上reset之后，再加入集群
kubeadm reset
kubeadm join 192.168.26.21:6443 --token [xxx...]\--discovery-token-ca-cert-hash sha256:[xxx...]
#8.各节点上删除calico历史文件（只删除文件，不删除目录）
rm -rf /etc/cni/net.d/*
#9.master上重新安装calico
kubectl apply -f calico.yaml

六、监测cpu、内存负载

前提：安装metric-server

查看节点的负载

kubectl top nodes

查看pod的负载

# -n 指定命名空间
kubectl top pods -n kube-system

1core = 1000m（1核=1000微核心）
双核既2core=2000m，若某个node占用cpu383m，则cpu使用率为383/2000=19%

七、命名空间（namespace）

我们可以在硬盘中创建一个个的文件夹，我们把所有的文件进行分类，将某一类的文件都放在文件夹1中，某一类的文件放在文件夹2中…，k82中有很多的pod，它是一种资源，不像本地的文件可以放在文件夹中，若想整理这么多的pod，我们可以创建一个个的命名空间，将某一些pod放在命名空间1里，某些pod放在命名空间2xia…也可以放数据卷等资源

不同的命名空间（namespace）之间互相隔离，就可以对不同的项目进行隔离，项目1看不到项目2的东西，如同不同地理位置的人在同一个qq群里，物理上不在一起，但是逻辑上在同一个组织内，能看到同一个群里的消息，看不到其他群里的消息

（1）列出集群中所有命名空间

kubectl get namespaces 可以简写为 kubectl get ns

（2）创建新的命名空间

kubectl create ns [名称]

（3）删除指定命名空间

kubectl delete ns [名称]

（4）若以管理员身份登录，默认在名为 “default” 的命名空间里，在此时kubectl get nodes、kubectl get pods等操作，都是获取在当前命名空间下的资源
若要修改默认的命名空间，编辑在家目录下的.kube/config文件

vim .kube/config
#修改context下的namespace（若不存在，则自己加上）的值，值为默认命名空间的名字
...
contexts:
- context:
    cluster: kubernetes
    user: kubernetes-admin
    namespace: [命名空间名字]
...

（5）kubens的使用
kubens是一个插件，下载好后，放入/usr/bin下，授予可执行权限，可以很方便的查看当前命名空间、切换命名空间

#下载kubens二进制文件，输出到/bin/kubens
curl -L https://github.com/ahmetb/kubectx/releases/download/v0.9.1/kubens -o /bin/kubens
#授予可执行权限
chmod +x /bin/kubens
#查看当前命名空间
kubens
#切换命名空间
kubens [命名空间名字]

（6）命名空间kube-system

kubectl get pods -n kube-system

k8s中一些必须的组件（kube-apiserver、kube-controller-manager、kube-scheduler、etcd、kube-proxy等）都在kube-system这个命名空间下，以pod的方式运行，因此kube-system这个命名空间性质类似于操作系统的C盘

NAME                                       READY   STATUS    RESTARTS   AGE
calico-kube-controllers-56cdb7c587-ndvcp   1/1     Running   0          4h26m
calico-node-6d2rv                          1/1     Running   0          4h26m
calico-node-tkj9x                          1/1     Running   0          4h26m
calico-node-v69sp                          1/1     Running   0          4h26m
coredns-74586cf9b6-cldcq                   1/1     Running   0          4h27m
coredns-74586cf9b6-hvbc2                   1/1     Running   0          4h27m
etcd-vms21.rhce.cc                         1/1     Running   3          4h27m
kube-apiserver-vms21.rhce.cc               1/1     Running   3          4h27m
kube-controller-manager-vms21.rhce.cc      1/1     Running   3          4h27m
kube-proxy-lgsfd                           1/1     Running   0          4h26m
kube-proxy-pmb7t                           1/1     Running   0          4h27m
kube-proxy-st2zx                           1/1     Running   0          4h26m
kube-scheduler-vms21.rhce.cc               1/1     Running   3          4h27m
metrics-server-58556b7dd4-qx7hv            1/1     Running   0          4h26m

八、k8s中对所有资源类型的通用操作

像namespace、node、pod等实质上都是资源，k8s中，这些资源都可以通过kubectl get [资源类型]来进行查看

（1）查看所有资源类型

想查看系统中都有哪些资源，及简写是什么，可以通过kubectl api-resources查看

kubectl api-resources

知道了有哪些资源、及简写后，就可以使用如下通用操作：

（2）列出所有某种资源

kubectl get [资源类型/简写]
#例
kubectl get no
kubectl get po
kubectl get ns
...
#以上获取的都是在当前命名空间下（即默认命名空间）
#若要获取指定命名空间下的资源，并且用户拥有足够的权限，则使用-n指定
#-n 指定命名空间
kubectl get [资源类型/简写] -n [命名空间名称]

（3）查看资源属性的通用语法

kubectl describe [资源类型] [资源名字]

（4）删除某个资源

kubectl delete [资源类型/简写] [名字]
#例
kubectl delete no vms23.rhce.cc
kubectl delete ns kube-public

（5）资源的标签相关

在k8s环境里，万事万物都有标签

#查看资源的标签的通用语法
kubectl get [资源类型] --show-labels
#查看具体某个资源的标签
kubectl get [资源类型] [资源名] --show-labels

#查看pod的标签
kubectl get pod --show-labels

#设置标签的通用语法
#会追加该标签，即原有的标签也还在
kubectl label [资源类型] [资源名] [标签键]=[标签值]
#对所有某个资源设置标签
kubectl label [资源类型] --all [标签键]=[标签值]
#若原有的标签中已经存在该键(key)了，则会报错，若想要覆盖，则使用 --overwrite
kubectl label [资源类型] [资源名] [标签键]=[标签值] --overwrite

#去除某个标签
kubectl label [资源类型] [资源名] [标签键]-
#去除所有某个资源的标签
kubectl label [资源类型] --all [标签键]-

#查看含有某个标签的资源
kubectl get [资源类型] -l [标签键]=[标签值]

我们查看node，会发现master上的ROLES为control-plane

kubectl get nodes

NAME            STATUS   ROLES           AGE    VERSION
vms21.rhce.cc   Ready    control-plane   7d4h   v1.24.2
vms22.rhce.cc   Ready    <none>          7d4h   v1.24.2
vms23.rhce.cc   Ready    <none>          7d4h   v1.24.2

我们查看更全的信息

kubectl get nodes --show-labels

NAME            STATUS   ROLES           AGE    VERSION   LABELS
vms21.rhce.cc   Ready    control-plane   7d4h   v1.24.2   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=vms21.rhce.cc,kubernetes.io/os=linux,node-role.kubernetes.io/control-plane=,node.kubernetes.io/exclude-from-external-load-balancers=

可以看到master这个节点的LABELS中的这个标签 “node-role.kubernetes.io/control-plane=”（值为空）
所以这里的ROLES是可以通过标签来设置的
我们模仿这个标签可以将其余两个worker节点的标签分别设置为worker1、worker2

kubectl label nodes vms22.rhce.cc node-role.kubernetes.io/worker1=
kubectl label nodes vms23.rhce.cc node-role.kubernetes.io/worker2=

九、多集群切换

为什么需要多集群切换？

假设现在有两套集群，集群a由master1、worker1-1、worker1-2组成，集群b由master2、worker2-1、worker2-2组成
集群a、集群b同时工作，并且在它们之上有一个负载均衡器，来分发请求到集群a、集群b
若此时要对集群a、集群b进行系统升级、维护，那么这段时间系统将无法对外提供服务，用户访问不了应用，这就不符合高可用性，为了使得用户能够正常访问系统，就可以进行 “多集群切换”，当集群a要进行升级维护时，负载均衡器断开与集群a的连接，当用户客户端发送请求的时候，负载均衡器将全部请求转发给集群b，这样用户就可以正常访问了，集群a维护完毕正常运行后，重新接入负载均衡器，集群b升级维护时同理，待全部集群正常工作后，负载均衡器重新发挥分发流量、负载均衡的功能，这也称为 “蓝绿部署”

“蓝绿集群” 可以基于不同的集群来做，也可以基于集群内不同的deployment来做

通过kubeconfig配置文件配置多套集群

在多集群的环境下，当我们想管理集群a的时候，首先需要连接到集群a的master，想要管理集群b的时候，需要连接到集群b的master上，非常不方便，我们是否可以在一台主机上，管理多套集群呢？——通过kubeconfig文件可以配置多套集群

kubeconfig文件结构介绍

可以通过kubectl config view命令查看kubeconfig文件结构

apiVersion: v1
clusters: #集群信息
- cluster: #单个集群信息
    certificate-authority-data: DATA+OMITTED #连接到该集群所需要的证书
    server: https://192.168.26.21:6443 #连接到该集群master的地址
  name: kubernetes #该集群名称
contexts: #上下文信息
- context: #单个上下文信息
    cluster: kubernetes #关联的集群名
    user: kubernetes-admin #关联的用户名
  name: kubernetes-admin@kubernetes #该上下文名称
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users: #用户信息
- name: kubernetes-admin #该用户名称
  user: #单个用户信息
    client-certificate-data: #用户证书信息
    client-key-data: REDACTED #用户私钥信息

主要分为三部分：
1.集群信息（clusters）：从中可以配置各个集群（cluster）的信息，server为连接到该集群master的地址
2.上下文信息（contexts）：上下文信息中关联了集群信息与用户信息，各个context将各个集群（cluster）与用户（user）关联起来
3.用户信息（users）：用户信息

配置多套集群

实验环境：
集群1：
master1——192.168.26.21
worker1-1——192.168.26.22
worker1-2——192.168.26.23
集群2：
master2——192.168.26.61
worker2-1——192.168.26.62

首先我们需要自己创建一个kubeconfig文件
使用自带的kubeconfig文件作为模板，导出另存为一个新的kubeconfig文件，命名为myconfig.yaml

kubectl config view > myconfig.yaml

查看连接到该集群所需要的证书、用户私钥

# certificate-authority-data集群证书
# client-certificate-data用户证书
# client-key-data用户私钥
cat .kube/config

查看连接到当前集群master的地址

kubectl cluster-info

编辑kubeconfig配置文件

vim myconfig.yaml

配置集群1与集群2的信息，配置两个集群信息，cluster1和cluster2，两个用户信息admin1和admin2，配置两个context将其关联起来，使用context1作为默认的上下文信息
修改配置文件如下：

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: [连接到cluster1的证书]
    server: https://192.168.26.21:6443
  name: cluster1
- cluster:
   certificate-authority-data: [连接到cluster2的证书]
   server: https://192.168.26.61:6443
 name: cluster2
contexts:
- context:
    cluster: cluster1
    user: admin1
  name: context1
- context:
    cluster: cluster2
    user: admin2
  name: context2
current-context: context1
kind: Config
preferences: {}
users:
- name: admin1
  user:
    client-certificate-data: [admin1的用户证书]
    client-key-data: [admin1的用户私钥]
- name: admin2
  user:
    client-certificate-data: [admin2的用户证书]
    client-key-data: [admin2的用户私钥]

使myconfig.yaml配置生效

#方式一：将myconfig.yaml覆盖.kube/config
cp myconfig.yaml .kube/config
#方式二：定义环境变量KUBECONFIG，这种方式只在当前终端生效，在其他终端就不生效
export KUBECONFIG=myconfig.yaml
#取消给定的变量KUBECONFIG
unset KUBECONFIG

查看管理了几套集群

kubectl config get-contexts

kubectl get nodes查看当前集群下的资源，若要切换到指定的集群下，使用：

kubectl config use-context [集群名]

其他一些常用命令

kubectl config set-context 集群名 --namespace=命名空间
kubectl config set-context --current --namespace=命名空间