文章详情

登录

短信预约-IT技能 免费直播动态提醒

选择考试省份

  • 北京
  • 上海
  • 天津
  • 重庆
  • 河北
  • 山东
  • 辽宁
  • 黑龙江
  • 吉林
  • 甘肃
  • 青海
  • 河南
  • 江苏
  • 湖北
  • 湖南
  • 江西
  • 浙江
  • 广东
  • 云南
  • 福建
  • 海南
  • 山西
  • 四川
  • 陕西
  • 贵州
  • 安徽
  • 广西
  • 内蒙
  • 西藏
  • 新疆
  • 宁夏
  • 兵团

请输入下面的图形验证码

提交验证

短信预约提醒成功

如何为你的 Kubernetes 集群保驾护航

2024-12-03 01:30

关注

 随着Kubernetes的不断发展，技术不断成熟，越来越多的公司选择把自家的应用部署到Kubernetes中。但是把应用部署到Kubernetes中就完事了吗？显然不是，应用容器化只是万里长征的第一步，如何让应用安心、稳定的运行才是后续的所有工作。

这里主要从以下几个方面来进行整理，对于大部分公司足够使用。

Node

Node可以是物理主机，也可以是云主机，它是Kubernetes的载体。在很多时候我们并不太关心Node怎么样了，除非其异常。但是作为运维人员，我们最不希望的就是异常，对于Node也是一样。

Node节点并不需要做太多太复杂的操作，主要如下：

>内核升级

对于大部分企业，CentOS系统还是首选，默认情况下，7系列系统默认版本是3.10，该版本的内核在Kubernetes社区有很多已知的Bug，所以对节点来说，升级内核是必须的，或者企业可以选择Ubuntu作为底层操作系统。

升级内核的步骤如下（简单的升级方式）： 

  1. wget https://elrepo.org/linux/kernel/el7/x86_64/RPMS/kernel-lt-5.4.86-1.el7.elrepo.x86_64.rpm  
  2. rpm -ivh kernel-lt-5.4.86-1.el7.elrepo.x86_64.rpm  
  3. cat /boot/grub2/grub.cfg | grep menuentry  
  4. grub2-set-default 'CentOS Linux (5.4.86-1.el7.elrepo.x86_64) 7 (Core)'  
  5. grub2-editenv list 
  6. grub2-mkconfig -o /boot/grub2/grub.cfg  
  7. reboot 

>软件更新

对于大部分人来说，更新软件在很多情况下是不做的，因为害怕兼容问题。不过在实际生产中，对于已知有高危漏洞的软件，我们还需要对其进行更新，这个可以针对处理。

>优化Docker配置文件

对于Docker的配置文件，主要优化的就是日志驱动、保留日志大小以及镜像加速等，其他的配置根据情况而定，如下： 

  1. cat > /etc/docker/daemon.json  << EOF  
  2. {  
  3.     "exec-opts": ["native.cgroupdriver=systemd"],  
  4.     "log-driver": "json-file",  
  5.     "log-opts": {  
  6.         "max-size": "100m",  
  7.         "max-file": "10"  
  8.     },  
  9.     "bip": "169.254.123.1/24",  
  10.     "oom-score-adjust": -1000,  
  11.     "registry-mirrors": ["https://pqbap4ya.mirror.aliyuncs.com"],  
  12.     "storage-driver": "overlay2",  
  13.     "storage-opts":["overlay2.override_kernel_check=true"],  
  14.     "live-restore": true  
  15. }  
  16. EOF 

>优化kubelet参数

对于K8S来讲，kubelet是每个Node的组长，负责Node的"饮食起居"，这里对它的参数配置主要如下： 

  1. cat > /etc/systemd/system/kubelet.service <<EOF  
  2. [Unit]  
  3. Description=kubelet: The Kubernetes Node Agent  
  4. Documentation=https://kubernetes.io/docs/  
  5. [Service]  
  6. ExecStartPre=/usr/bin/mkdir -p /sys/fs/cgroup/pids/system.slice/kubelet.service  
  7. ExecStartPre=/usr/bin/mkdir -p /sys/fs/cgroup/cpu/system.slice/kubelet.service  
  8. ExecStartPre=/usr/bin/mkdir -p /sys/fs/cgroup/cpuacct/system.slice/kubelet.service  
  9. ExecStartPre=/usr/bin/mkdir -p /sys/fs/cgroup/cpuset/system.slice/kubelet.service  
  10. ExecStartPre=/usr/bin/mkdir -p /sys/fs/cgroup/memory/system.slice/kubelet.service  
  11. ExecStartPre=/usr/bin/mkdir -p /sys/fs/cgroup/systemd/system.slice/kubelet.service  
  12. ExecStart=/usr/bin/kubelet \  
  13. --enforce-node-allocatable=pods,kube-reserved \  
  14. --kube-reserved-cgroup=/system.slice/kubelet.service \  
  15. --kube-reserved=cpu=200m,memory=250Mi \  
  16. --eviction-hard=memory.available<5%,nodefs.available<10%,imagefs.available<10% \  
  17. --eviction-soft=memory.available<10%,nodefs.available<15%,imagefs.available<15% \  
  18. --eviction-soft-grace-period=memory.available=2m,nodefs.available=2m,imagefs.available=2m \  
  19. --eviction-max-pod-grace-period=30 \  
  20. --eviction-minimum-reclaim=memory.available=0Mi,nodefs.available=500Mi,imagefs.available=500Mi  
  21. Restart=always  
  22. StartLimitInterval=0  
  23. RestartSec=10   
  24. [Install]  
  25. WantedBy=multi-user.target  
  26. EOF 

其功能主要是为每个Node增加资源预留，可以在一定程度上防止Node宕机。

>日志配置管理

这里的日志配置管理针对的是系统日志，非自研应用日志。默认情况下，系统日志都不需要我们特殊配置，我这里提出来，主要是保障日志的可追溯。当系统因为某种原因被入侵，系统系统被删除的情况下，还有日志提供给我们分析。

所以在条件允许的情况下，对Node节点的系统日志进行远程备份是有必要的，可以采用rsyslog进行配置管理，日志可以保存到远端的日志中心或者oss上。

>安全配置

安全配置这里涉及的不多，主要是针对已知的一些安全问题进行加固。主要有以下五种（当然还有更多，看自己的情况）：

Pod

Pod是K8S的最小调度单元，是应用的载体，它的稳定直接关乎应用本身，在部署应用的时候，主要考虑一下几个方面。

>资源限制

Pod使用的是主机的资源，合理的资源限制可以有效避免资源超卖或者资源抢占问题。在配置资源限制的时候，要根据实际的应用情况来决定Pod的QoS，不同的QoS配置情况不一样。

如果应用的级别比较高，建议配置Guaranteed级别配置，如下： 

  1. resources:  
  2.   limits:  
  3.     memory: "200Mi"  
  4.     cpu: "700m"  
  5.   requests:  
  6.     memory: "200Mi"  
  7.     cpu: "700m" 

如果应用级别一般，建议配置Burstable级别，如下： 

  1. resources:  
  2.   limits:  
  3.     memory: "200Mi"  
  4.     cpu: "500m"  
  5.   requests:  
  6.     memory: "100Mi"  
  7.     cpu: "100m" 

强烈不建议使用BestEffort类型的Pod。

>调度策略

调度策略也是根据情况来定，如果你的应用需要指定调度到某些节点，可以使用亲和性调度，如下： 

  1. affinity:  
  2.   nodeAffinity:  
  3.     preferredDuringSchedulingIgnoredDuringExecution:  
  4.       - preference: {}  
  5.         weight: 100  
  6.     requiredDuringSchedulingIgnoredDuringExecution:  
  7.       nodeSelectorTerms:  
  8.         - matchExpressions:  
  9.             - key: env  
  10.               operator: In  
  11.               values:  
  12.                 - uat 

如果一个节点只允许某一个应用调度，这时候就需要用到污点调度了，也就是先给节点打污点，然后需要调度到该节点的Pod需要容忍污点。最稳妥的方式是标签+污点相结合。如下： 

  1. tolerations:  
  2. - key: "key1"          #能容忍的污点key  
  3.   operator: "Equal"    #Equal等于表示key=value ， Exists不等于，表示当值不等于下面value正常  
  4.   value: "value1"      #值  
  5.   effect: "NoExecute"  #effect策略  
  6.   tolerationSeconds: 3600  #原始的pod多久驱逐，注意只有effect: "NoExecute"才能设置，不然报错 

当然，除了Pod和Node的关联，还有Pod和Pod之间的关联，一般情况下，为了达到真正的高可用，我们不建议同一个应用的Pod都可以调度到同一个节点，所以我们需要给Pod做反亲和性调度，如下： 

  1. affinity:  
  2.   podAntiAffinity:  
  3.     requiredDuringSchedulingIgnoredDuringExecution:  
  4.     - labelSelector:  
  5.         matchExpressions:  
  6.         - key: app  
  7.           operator: In  
  8.           values:  
  9.           - store  
  10.       topologyKey: "kubernetes.io/hostname" 

如果某个应用亲和其他应用，则可以使用亲和性，这样可以在一定程度上降低网络延迟，如下： 

  1. affinity:  
  2.   podAffinity:  
  3.     requiredDuringSchedulingIgnoredDuringExecution:  
  4.     - labelSelector:  
  5.         matchExpressions:  
  6.         - key: security  
  7.           operator: In  
  8.           values:  
  9.           - S1 
  10.       topologyKey: failure-domain.beta.kubernetes.io/zone 

>优雅升级

Pod默认是采用的滚动更新策略，我们关注点主要在新的Pod起来后，老的Pod如何能优雅的处理流量，对外界是无感的。

最简单的方式是"睡几秒"，这种方式并不能保证百分百的优雅处理流量，方式如下： 

  1. lifecycle:  
  2.   preStop:  
  3.     exec:  
  4.       command:  
  5.       - /bin/sh  
  6.       - -c  
  7.       - sleep 15 

如果有注册中心，可以在退出的时候先把原服务从注册中心下线再退出，比如这里使用的nacos作为注册中心，如下： 

  1. lifecycle:  
  2.   preStop:  
  3.     exec:  
  4.       command:  
  5.         - /bin/sh  
  6.         - -c  
  7.         - "curl -X DELETE your_nacos_ip:8848/nacos/v1/ns/instance?serviceName=nacos.test.1&ip=${POD_IP}&port=8880&clusterName=DEFAULT" && sleep 15 

 >探针配置

探针重要吗？重要！它是kubelet判断Pod是否健康的重要依据。

Pod的主要探针有：

其中startupProbe是v1.16版本后才新增的探针，其主要针对启动时间较长的应用，在多数情况下只需要配置livenessProbe和readinessProbe即可。

通常情况下，一个Pod就代表一个应用，所以在配置探针的时候最好能直接反应应用是否正常，很多框架都带有健康检测功能，我们在配置探针的时候可以考虑使用这些健康检测功能，如果框架没有，也可以考虑让开发人员统一开发一个健康检测接口，这样便于标准化健康检测。如下： 

  1. readinessProbe:  
  2.   failureThreshold: 3  
  3.   httpGet:  
  4.     path: /health  
  5.     port: http  
  6.     scheme: HTTP  
  7.   initialDelaySeconds: 40  
  8.   periodSeconds: 10  
  9.   successThreshold: 1  
  10.   timeoutSeconds: 3  
  11. livenessProbe:  
  12.   failureThreshold: 3  
  13.   httpGet:  
  14.     path: /health  
  15.     port: http  
  16.     scheme: HTTP  
  17.   initialDelaySeconds: 60  
  18.   periodSeconds: 10  
  19.   successThreshold: 1  
  20.   timeoutSeconds: 2 

如果需要配置startupProbe，则可以如下配置： 

  1. startupProbe:  
  2.   httpGet:  
  3.     path: /health  
  4.     prot: 80  
  5.   failureThreshold: 10  
  6.   initialDelay：10  
  7.   periodSeconds: 10 

>保护策略

这里的保护策略主要是指在我们主动销毁Pod的时候，通过保护策略来控制Pod的运行个数。

在K8S中通过PodDisruptionBudget（PDB）来实现这个功能，对于一些重要应用，我们需要为其配置PDB，如下： 

  1. apiVersion: policy/v1beta1  
  2. kind: PodDisruptionBudget  
  3. metadata:  
  4.   name: pdb-demo  
  5. spec:  
  6.   minAvailable: 2  
  7.   selector:  
  8.     matchLables:  
  9.       app: nginx 

在PDB中，主要通过两个参数来控制Pod的数量：

注意：minAvailable和maxUnavailable是互斥了，也就是说两者同一时刻只能出现一种。

日志

日志会贯穿应用的整个生命周期，在排查问题或者分析数据的时候，日志都不可缺少。对于日志，这里主要从以下方面进行分析。

>日志标准

日志一般分为业务日志和异常日志，对于日志，我们不希望其太复杂，也不希望其太简单，更多的是希望通过日志达到如下目标：

那日志标准如何定义呢？我这里简单整理以下几点：

这样规定的主要目的是便于收集和查看日志。

>收集

针对不同的日志输出有不同的日志收集方案，主要有以下二种：

在Node上部署Logging Agent进行收集

这种日志收集方案主要针对已经标准输出的日志，架构如下：

对于非标准输出的日志就没办法进行收集。

在Pod中以Sidecar形式进行收集

这种收集方案主要针对非标准输出的日志，可以在Pod中以sidecar的方式运行日志收集客户端，将日志收集到日志中心，架构如下：

不过这种方式比较浪费资源，所以最理想的情况就是把应用日志都标准输出，这样收集起来比较简单。

>分析

在业务正常的情况下，我们其实很少去查看日志内容，只有在出问题的时候才会借助日志分析问题（大部分情况下都是这样），那为什么我这里要把分析提出来呢？

日志其实承载了很多信息，如果能对日志进行有效分析，可以帮助我们识别、排查很多问题，比如阿里云的日志中心，在日志分析方面做的就很不错。

>告警

日志告警，可以让我们快速知道问题，也缩小了故障排查范围。不过要做日志告警就必须做好日志“关键字”管理，也就是要确定某一个关键字能够准确的代表一个问题，最好不出现泛指的现象，这样做的好处就是能够让告警更加准备，而不是出现一些告警风暴或者无效告警，久而久之就麻木了。

监控

集群、应用等的生命周期里离不开监控系统，有效的监控系统可以为我们提供更高的可观测性，方便我们线性的分析问题，排查问题以及定位问题，再配上有效的告警通知，也方便我们能快速的知道问题。

对于监控，主要从以下几个方面进行介绍。

>集群监控

对于K8S集群以及跑在K8S应用来说，普遍使用Prometheus来进行监控。整个集群的稳定性关乎着应用的稳定性，所以对集群的监控至关重要，下面简单列举了一些监控项，在实际的工作中酌情处理。

>应用监控

在很多企业中，并没有接入应用监控，主要还是没有在应用中集成监控指标，导致无法监控，所以在应用开发的时候就强烈建议开发将应用监控加上，将指标按prometheus标准格式暴露出来。

除了开发人员主动暴露指标外，我们也可以通过javaagent方式配置一些exporter，用来抓取一些指标，比如jvm监控指标。

在应用级别做监控，可以将监控粒度更细化，这样可以更容易发现问题。我这里简单整理了一些应用监控项，如下：

这些监控项都有对于的exporter来完成，比如redis中间件有redis-exporter，api监控有blcakbox-exporter等。

>事件监控

在Kubernetes中，事件分为两种，一种是Warning事件，表示产生这个事件的状态转换是在非预期的状态之间产生的；另外一种是Normal事件，表示期望到达的状态，和目前达到的状态是一致的。

事件大多数情况下表示正在发生或者已经发生的事，在实际工作中很容易就忽略这类信息，所以我们有必要借助事件监控来规避这类问题。

在K8S中，常用的事件监控是kube-eventer，它可以收集pod/node/kubelet等资源对象的event，还可以收集自定义资源对象的event，然后将这类信息发送到相关人员。

通过事件，我们主要关注的监控项如下：

>链路监控

正常情况下，K8S中的应用是单独的个体存在，彼此之间没有显性的联系，这时候就需要一种手段，将应用间的关系表现出来，方便我们跟踪分析整个链路的问题。

目前比较流行的链路监控工具有很多，我这边主要是使用skywalking进行链路监控，其主要agent端比较丰富，也提供了很高的自扩展能力，有兴趣的朋友可以了解一下。

通过链路监控，主要达到以下目的。

>告警通知

很多人会忽略告警通知，觉得告警就行。但是在做告警通知的时候还是需要仔细去考虑的。

如下简单整理一下关注点。

个人觉得难点在于哪些指标需要告警。我们在选取指标的时候一定要遵循以下规则：

综合这些规则考虑，才方便我们选取需要的指标。

第二就是紧急程度分类，这个主要是根据这个告警指标所暴露出来的问题是不是需要我们及时去解决，还有影响范围来综合衡量。

故障升级主要是针对需要解决的问题没有解决而做的一种策略，提高故障等级，也相当于提高了紧急程度了。通知渠道分类主要是方便我们区分不同的告警，还有如果能快速接收到告警信息。

写在最后

上面写的都是一些基础的操作，对于YAML工程师来说，算是必备的技能储备，这一套放到大部分公司都是适用的。

 

来源：奇妙的Linux世界内容投诉

免责声明：

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的，并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据，供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题

  • 2024年上半年信息系统项目管理师第二批次真题及答案解析（完整版）

    难度     813人已做
    查看

  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看

  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看

  • 2024年上半年软考高项第一、二批次真题考点汇总（完整版）

    难度     435人已做
    查看

  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机

如何为你的 Kubernetes 集群保驾护航

后端开发KubernetesLinux2024-12-03

如何为你的Kubernetes保驾护航

后端开发KubernetesDevtron2024-12-03

数据保护即服务（DPaaS）如何为业务保驾护航

后端开发数据保护DPaaS2024-12-14

HTTPS保驾护航：为你的CMS网站披上传说级护甲！

HTTPS保驾护航：为你的CMS网站披上传说级护甲！
后端开发2024-02-16

职证网个性化教育，为你的事业保驾护航

后端开发职证网2024-11-30

独家揭秘！5G如何为大型活动保驾护航

后端开发5G无线通信2024-12-02

如何防止不需要的模块加载以保护Kubernetes集群？

后端开发KubernetesLinux2024-12-24

阿里云全新云服务器为你的业务保驾护航

阿里云全新云服务器为你的业务保驾护航
后端开发2023-10-29

15个API安全优秀实践，为你的应用程序保驾护航

后端开发软件开发API2024-11-30

从郑州暴雨看重大事件保障服务，华为如何为企业保驾护航？

后端开发数字化2024-12-03

复工复产进行时，如何为企业网络安全保驾护航？

后端开发网络安全疫情2024-12-24

特斯拉被黑客攻击？如何保护您的Kubernetes集群并阻止黑客？

后端开发Kubernetes容器2024-11-30

数据库事务隔离级别实操指南：为你的数据库保驾护航

数据库事务隔离级别实操指南：为你的数据库保驾护航
后端开发2024-02-10

技术同学须知的MySQL设计规约，为你的数据库开发保驾护航！

后端开发2023-10-22

从信息化到数字化 乖宝集团为宠物舌尖上的安全保驾护航

后端开发乖宝集团数字化转型2024-12-10

如何使用Polaris验证你的Kubernetes集群是否遵循了最佳安全实践

后端开发Polaris部署2024-11-30

数据被收集、隐私被泄露……首次亮相的个人信息保护法草案如何捍卫你我信息安全？

后端开发信息安全数据2024-12-03
位置：首页-资讯-后端开发
咦！没有更多了？去看看其它编程学习网 内容吧
首页课程
资料下载问答资讯