k8s六：k8s运维指南

桃扇骨 2022-11-07 14:35 273阅读 0赞

5.1 k8s集群管理指南  
主要包括：node管理 label管理 namespace资源共享 资源配额管理 集群master高可用 集群监控等  
5.1.1 node的隔离与恢复  
如果某些node需要进行硬件升级、维护等，需要将某些node进行隔离与恢复，有如下三种方法：  
方式一： 通过node的yaml文件修改node的状态  
1)定义配置文件如下：  
unsechedule\_node.yaml  
apiVersion: v1  
kind: Node  
metadata:  
 name: k8s-node-1  
 labels:  
  kubenetes.io/hostname: k8s-node-1  
spec:  
 unschedulable: true  
2)kubectl replace 命令执行  
kubectl replace -f unschedule\_node.yaml  
此时获取node的状态：  
kubectl get nodes  
说明：此时node的status增加了SchedulingDisabled  
方式二： 直接使用命令，如：  
kubectl patch node k8s-node-1 -p '\{"spec":\{"unschedulable":true\}\}'  
方式三：使用命令：如   
kubectl cordon k8s-node-1 \#node隔离  
kubectl uncordon k8s-node-1 \#node解除隔离

整理说明：node被隔离后，对于后续创建的Pod，系统讲不会再向该Node调度；  
对于node被隔离前在node上创建的pod会一直存在，Pod不会自动停止，需要管理员手动停止在该Node上运行的Pod

2 node的扩容  
新的Node节点，安装docker、kubelet和kube-proxy服务并启动，将master url指定为当前k8s集群的地址则可以实现自动注册。

5.1.2 更新资源对象的label  
kubectl label pod redis-pod role=backend \#对名称为redis-pod的pod增加label： role=backend  
kubectl get pods -Lrole \# 查看该pod的label  
kubectl label pod redis-pod role- \#对pod删除key为role的label  
kubectl label pod redis-pod role=master --overwrite

5.1.3 namespace 集群环境共享与隔离  
同一个k8s集群可能用于多条业务线或者多环境来，所以需要引入命名空间的概念，防止不同业务线或环境相互影响。  
假设需要开发和生产两个命名空间，流程主要如下：  
1 创建namespace  
namespace-development.yaml  
apiVersion: v1  
kind: Namespace  
metadata:  
 name: development

namespace-production.yaml  
apiVersion: v1  
kind: Namespace  
metadata:  
 name: production  
执行指令：  
kubectl create -f namespace-development.yaml  
kubectl create -f namespace-production.yaml

2 定义context  
需要为两个工作组分别定义一个context，即运行环境。具体指令如下：  
kuctl config set-cluster kubernetes-cluster --server=https://192.168.1.128:8080  
kubtctl config set-context ctx-dev --namespace=development --cluster=kubernetes-cluster --user=dev  
kubtctl config set-context ctx-prod --namespace=production --cluster=kubernetes-cluster --user=prod

kubectl config view 查看已经定义的context  
注意：通过kubectl config命令在$\{HOME\}/.kube目录下生成了一个名为config的文件，具体内容即使上面指令查看到的内容

3 设置工作组则特定context中工作  
kubectl  config use-context ctx-dev \#将当前运行环境设置为“ctx-dev”  
然后通过kubectl create -f即可创建pod等资源

5.1.4 k8s资源管理  
计算资源：cpu和内存  
资源的两种配置：requests 和 limits  
pod和容器的requests和limits，有如下四个参数：  
spec.container\[\].resources.requests.cpu \#cpu的请求  
spec.container\[\].resources.limits.cpu \#cpu的限制  
spec.container\[\].resources.requests.memeory \#内存的请求  
spec.container\[\].resources.limits.memory \#内存的限制  
说明：两者都是可选的，request没有配置会默认等于limits，limits应该大于requests

spec.container\[\].resources.requests.cpu如果被设置为0.5，含义如下：  
该容器会获得半个cpu，该值是绝对值，即无论几核cpu的资源都是0.5cpu

spec.container\[\].resources.requests.memeory 可以被设置为64M，即需要的内存是64M

基于资源进行的Pod调度  
如果某个node的内存只有4G，其中3G用来运行Pod，pod内存的Request为1G，Limits为2G；那么节点最多可以运行3个这种Pod。  
后期再有Pod需要创建，则不会分配到该节点。

参数生效：  
对容器设置的cpu资源限制会作为参数传给docker  
内存的request不传给docker，limits会传给docker。  
如果容器原型超过了其内存limits的限制，则该容器可能会被杀掉，如果这个容器是一个可重启的容器，那么之后他会被kubelet重启  
cpu因为在容器技术中属于可压缩资源，因此对于CPU的limits配置一般不会因超标导致容器被kill

资源的配置范围管理：  
具体可能存在如下场景：  
1）node一共2G内存，管理员不希望任何Pod申请超过2G的的内存  
2）集群分为不同namespace，希望为不同的namespace设置最大的可使用空间  
3）避免资源浪费，如每个Pod使用node的40%资源，2个使用80%，那么剩下20%会非常尴尬

k8s提供了LimitRange机制限制Pod和容器的Reques和Limits配置。下面是个实例：  
1）创建namespace，如：  
kubectl create namespace limit-example  
2) 为namespace设置LimitRange  
3）创建Pod时触发LimitRange限制

5.1.5 资源紧缺时的Pod驱逐机制  
目的：对于内存、磁盘等不可压缩的资源在进去的情况下继续保证node的稳定性

驱逐策略：  
资源过于紧张时，kubelet会主动停止一个或多个Pod，回收紧缺的资源；  
Pod被终止是，哦容器会全部停止，pod的状态会被设置为Failed

驱逐信号：  
驱逐策略基于驱逐信号来执行，驱逐信号包括：memory.avaliable nodefs.avaliable imagefs.avaliable

驱逐阈值  
驱逐信号获取当前系统资源状态，驱逐阈值则定义资源状态在什么情况下要触发驱逐动作。  
阈值的定义方式：  
<eviction-signal><operator><quantity>,即驱逐信号 运算符 数量表达式，如：  
memory.avaliable<10%  
memory.avaliable<1Gi  
驱逐软阈值：资源消耗达到软阈值时，持续时间达到宽限期之前kubelet不会触发驱动动作  
驱逐硬阈值：达到驱逐阈值，kubelet立即杀掉Pod并进行资源的回收，如：--eviction-hard=memory.avaliable<100Mi

驱逐监控频率  
定义驱逐阈值评估的时间间隔，参数 --housekeeping-interval

节点的状况  
kubelet会持续向master报告节点的状态

回收node界别的资源  
如果节点达到了驱逐阈值，并且也过了宽限期，kubelet并不会立刻回收超出限量的资源，而是先尝试回收资源，包括删除无用镜像、删除死掉的Pod、容器等手段，如果依旧达到驱逐阈值，则会驱逐用户的Pod

驱逐用户的Pod：  
bestEffort:对紧缺资源消耗最多的Pod最先被驱逐  
burstable:先清除资源消耗超出requests的的Pod，没有则按照bestEffort  
Guaranteed

资源最少回收量  
为了避免驱逐Pod仅回收了很少的资源，导致kubelet反复触发驱逐阈值。可以设置一次驱逐回收的最少资源数量。  
通过配置--eviction-minimum-reclaim

5.1.7 k8s集群高可用部署方案  
k8s集群通过对Pod运行状况的监控和调控，实现了应用层的高可用性。所以保证k8s的高可用性十分重要。  
包括两个方面：etcd的高可用 master节点的高可用

etcd的高可用：  
etcd在k8s集群中处于中心数据库的地位，用于存储各种资源的具体信息，所以需要保证etcd的高可用，所以需要部署一个至少由三台服务器组成的etcd集群。

master的高可用：  
master上的进程不断与工作节点上的kubelet和kube-proxy进行通信，来维护整个集群的健康工作状态。为了保证master的高可用，也需要部署一个至少由三台服务器组成的emaster集群

k8s典型的部署方式：如图

通过kubelet服务以容器和的形式启动和运行kube-ap\[iserver\\ kube-controller-master\\kube-scheduler.  
1）kube-apiserver的高可用部署  
预先为kube-apiserver创建所有需要的CA证书和基本鉴权文件等，并子啊每台服务器上创建日志文件：  
touch /var/log/kube-apiserver.log  
2) 为kube-apiserver配置负载均衡器  
3）kube-controller-manager和kube-scheduler的高可用配置，通过租赁锁来实现

5.1.8 k8s集群监控  
开源软件cAdvisor  
页面查看某个node的容器的运行状态:cpu、内存、网络吞吐量、文件系统使用情况等  
问题：仅能对一台Node进行监控，大规模容器集群中则不易使用。

Heapster + Influxdb + Grafana集群性能监控平台  
heapster:汇聚集群各Node上cAdvisor的数据采集系统  
InfluxDB:分布式时序数据库，用于实施数据采集、事件跟踪记录、存储时间图表等  
Grafana:通过dashboard将Influxdb中的时序数据展现成图表或曲线等

5.1.9 集群统一日志管理  
k8s推荐采用Fluentd + ES + kibana完成对系统和容器日志的采集

5.1.10 k8s审计日志  
记录谁在什么时候对什么做了什么操作，该日志记录与kube -apiserver中。

5.1.11 使用web UI管理集群  
要求部署Heapster，可提供部署应用、资源对象管理、日志查询、系统监控查询等集群管理功能。

5.1.12 Helm，k8s应用包管理工具

5.2 Trouble shooting指导  
5.2.1 查看系统event事件  
kubectl describe pod podName  
5.2.2 查看容器日志  
kubectl logs podName  
5.2.3 查看k8s服务日志  
如果在linux系统上安装，且systemd系统来管理k8s服务，那么systemd的journal系统会接管服务程序的食醋胡日志。此时可使用systemd status 或 journactl工具来查看系统服务的日志。