K8S 中的 CPUThrottlingHigh 到底是个什么鬼？

最新推荐文章于 2024-04-22 18:41:55 发布
最新推荐文章于 2024-04-22 18:41:55 发布
阅读量8.8k 收藏 10
点赞数 3
文章标签： 队列 java kubernetes docker 编程语言


1. 前言

在使用 Kubernetes 的过程中，我们看到过这样一个告警信息：

[K8S] 告警主题: CPUThrottlingHigh
告警级别: warning
告警类型: CPUThrottlingHigh
故障实例: 
告警详情: 27% throttling of CPU in namespace kube-system for container kube-proxy in pod kube-proxy-9pj9j.
触发时间: 2020-05-08 17:34:17

这个告警信息说明 kube-proxy 容器被 throttling 了，然而查看该容器的资源使用历史信息，发现该容器以及容器所在的节点的 CPU 资源使用率都不高：

告警期间容器所在节点 CPU 使用率 告警期间 kube-proxy 的资源使用率

经过我们的分析，发现该告警实际上是和 Kubernetes 对于 CPU 资源的限制和管控机制有关。Kubernetes 依赖于容器的 runtime 进行 CPU 资源的调度，而容器 runtime 以 Docker 为例，是借助于 cgroup 和 CFS 调度机制进行资源管控。本文基于这个告警案例，首先分析了 CFS 的基本原理，然后对于 Kubernetes 借助 CFS 进行 CPU 资源的调度和管控方法进行了介绍，最后使用一个例子来分析 CFS 的一些调度特性来解释这个告警的 root cause 和解决方案。

2. CFS 基本原理

基本原理

Linux 在 2.6.23 之后开始引入 CFS 逐步替代 O1 调度器作为新的进程调度器，正如它名字所描述的，CFS(Completely Fair Scheduler) 调度器[1]追求的是对所有进程的全面公平，实际上它的做法就是在一个特定的调度周期内，保证所有待调度的进程都能被执行一遍，主要和当前已经占用的 CPU 时间经权重除权之后的值 (vruntime，见下面公式) 来决定本轮调度周期内所能占用的 CPU 时间，vruntime 越少，本轮能占用的 CPU 时间越多；总体而言，CFS 就是通过保证各个进程 vruntime 的大小尽量一致来达到公平调度的效果：

进程的运行时间计算公式为:
进程运行时间  =  调度周期  *  进程权重  /  所有进程权重之和

vruntime = 进程运行时间  * NICE_0_LOAD /  进程权重 = (调度周期  *  进程权重  /  所有进程总权重) * NICE_0_LOAD /  进程权重  =  调度周期  * NICE_0_LOAD /  所有进程总权重

通过上面两个公式，可以看到 vruntime 不是进程实际占用 CPU 的时间，而是剔除权重影响之后的 CPU 时间，这样所有进程在被调度决策的时候的依据是一致的，而实际占用 CPU 时间是经进程优先级权重放大的。这种方式使得系统的调度粒度更小来，更加适合高负载和多交互的场景。

Kernel 配置

在 kernel 文件系统中，可以通过调整如下几个参数来改变 CFS 的一些行为：

  • /proc/sys/kernel/sched_min_granularity_ns，表示进程最少运行时间，防止频繁的切换，对于交互系统

  • /proc/sys/kernel/sched_nr_migrate，在多 CPU 情况下进行负载均衡时，一次最多移动多少个进程到另一个 CPU 上

  • /proc/sys/kernel/sched_wakeup_granularity_ns，表示进程被唤醒后至少应该运行的时间，这个数值越小，那么发生抢占的概率也就越高

  • /proc/sys/kernel/sched_latency_ns，表示一个运行队列所有进程运行一次的时间长度 (正常情况下的队列调度周期，P)

  • sched_nr_latency，这个参数是内核内部参数，无法直接设置，是通过 sched_latency_ns/sched_min_granularity_ns 这个公式计算出来的；在实际运行中，如果队列排队进程数  nr_running > sched_nr_latency，则调度周期就不是 sched_latency_ns，而是 P = sched_min_granularity_ns * nr_running，如果  nr_running <= sched_nr_latency，则  P = sched_latency_ns

在阿里云的 Kubernetes 节点上，这些参数配置如下：

$ cat /proc/sys/kernel/sched_min_granularity_ns
10000000
$ cat /proc/sys/kernel/sched_nr_migrate
32
$ cat /proc/sys/kernel/sched_wakeup_granularity_ns
15000000
$ cat /proc/sys/kernel/sched_latency_ns
24000000

可以算出来  sched_nr_latency = sched_latency_ns / sched_min_granularity_ns = 24000000 / 10000000 = 2.4

在阿里云普通的虚拟机上的参数如下：

$ cat /proc/sys/kernel/sched_min_granularity_ns
3000000
$ cat /proc/sys/kernel/sched_latency_ns
15000000

可以算出来  sched_nr_latency = sched_latency_ns / sched_min_granularity_ns = 15000000 / 3000000 = 5

而在普通的 CentOS Linux release 7.5.1804 (Core) 上的参数如下：

$ cat /proc/sys/kernel/sched_min_granularity_ns
3000000
$ cat /proc/sys/kernel/sched_nr_migrate
32
$ cat /proc/sys/kernel/sched_wakeup_granularity_ns
4000000
$ cat /proc/sys/kernel/sched_latency_ns
24000000

可以算出来  sched_nr_latency = sched_latency_ns / sched_min_granularity_ns = 24000000 / 3000000 = 8

可以看到，阿里云的 Kubernetes 节点设置了更长的最小执行时间，在进程队列稍有等待 (2.4) 的时候就开始保证每个进程的最小运行时间不少于 10 毫秒。

运行和观察

部署这样一个 yaml POD：

apiVersion: v1
kind: Pod
metadata:
  name: busybox
  labels:
    app: busybox
spec:
  containers:
  - image: busybox
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
    command:
      - "/bin/sh"
      - "-c"
      - "while true; do sleep 10; done"
    imagePullPolicy: IfNotPresent
    name: busybox
  restartPolicy: Always

可以看到该容器内部的进程对应的 CPU 调度信息变化如下：

[root@k8s-node-04 ~]# cat /proc/121133/sched
sh (121133, #threads: 1)
-------------------------------------------------------------------
se.exec_start                                :   20229360324.308323
se.vruntime                                  :             0.179610
se.sum_exec_runtime                          :            31.190620
se.nr_migrations                             :                   12
nr_switches                                  :                   79
nr_voluntary_switches                        :                   78
nr_involuntary_switches                      :                    1
se.load.weight                               :                 1024
policy                                       :                    0
prio                                         :                  120
clock-delta                                  :                   26
mm->numa_scan_seq                            :                    0
numa_migrations, 0
numa_faults_memory, 0, 0, 0, 0, -1
numa_faults_memory, 1, 0, 0, 0, -1
numa_faults_memory, 0, 1, 1, 0, -1
numa_faults_memory, 1, 1, 0, 0, -1


[root@k8s-node-04 ~]# cat /proc/121133/sched
sh (121133, #threads: 1)
-------------------------------------------------------------------
se.exec_start                                :   20229480327.896307
se.vruntime                                  :             0.149504
se.sum_exec_runtime                          :            33.325310
se.nr_migrations                             :                   17
nr_switches                                  :                   91
nr_voluntary_switches                        :                   90
nr_involuntary_switches                      :                    1
se.load.weight                               :                 1024
policy                                       :                    0
prio                                         :                  120
clock-delta                                  :                   31
mm->numa_scan_seq                            :                    0
numa_migrations, 0
numa_faults_memory, 0, 0, 1, 0, -1
numa_faults_memory, 1, 0, 0, 0, -1
numa_faults_memory, 0, 1, 0, 0, -1
numa_faults_memory, 1, 1, 0, 0, -1


[root@k8s-node-04 ~]# cat /proc/121133/sched
sh (121133, #threads: 1)
-------------------------------------------------------------------
se.exec_start                                :   20229520328.862396
se.vruntime                                  :             1.531536
se.sum_exec_runtime                          :            34.053116
se.nr_migrations                             :                   18
nr_switches                                  :                   95
nr_voluntary_switches                        :                   94
nr_involuntary_switches                      :                    1
se.load.weight                               :                 1024
policy                                       :                    0
prio                                         :                  120
clock-delta                                  :                   34
mm->numa_scan_seq                            :                    0
numa_migrations, 0
numa_faults_memory, 0, 0, 0, 0, -1
numa_faults_memory, 1, 0, 0, 0, -1
numa_faults_memory, 0, 1, 1, 0, -1
numa_faults_memory, 1, 1, 0, 0, -1

其中 sum_exec_runtime 表示实际运行的物理时间。

3. Kubernetes 借助 CFS 进行 CPU 管理

CFS 进行 CPU 资源限流 (throtting) 的原理

根据文章《Kubernetes 生产实践系列之三十：Kubernetes 基础技术之集群计算资源管理》[2]的描述，Kubernetes 的资源定义：

    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

比如里面的 CPU 需求，会被翻译成容器 runtime 的运行时参数，并最终变成 cgroups 和 CFS 的参数配置：

$ cat cpu.shares
256
$ cat cpu.cfs_quota_us
50000
$ cat cpu.cfs_period_us
100000

这里有一个默认的参数：

$ cat /proc/sys/kernel/sched_latency_ns
24000000

所以在这个节点上，正常压力下，系统的 CFS 调度周期是 24ms，CFS 重分配周期是 100ms，而该 POD 在一个重分配周期最多占用 50ms 的时间，在有压力的情况下，POD 可以占据的 CPU share 比例是 256。

下面一个例子可以说明不同资源需求的 POD 容器是如何在 CFS 的调度下占用 CPU 资源的：

CPU 资源配置和 CFS 调度

在这个例子中，有如下系统配置情况：

  • CFS 调度周期为 10ms，正常负载情况下，进程 ready 队列里面的进程在每 10ms 的间隔内都会保证被执行一次

  • CFS 重分配周期为 100ms，用于保证一个进程的 limits 设置会被反映在每 100ms 的重分配周期内可以占用的 CPU 时间数，在多核系统中，limit 最大值可以是 CFS 重分配周期 * CPU 核数

  • 该执行进程队列只有进程 A 和进程 B 两个进程

  • 进程 A 和 B 定义的 CPU share 占用都一样，所以在系统资源紧张的时候可以保证 A 和 B 进程都可以占用可用 CPU 资源的一半

  • 定义的 CFS 重分配周期都是 100ms

  • 进程 A 在 100ms 内最多占用 50ms，进程 B 在 100ms 内最多占用 20ms

所以在一个 CFS 重分配周期 (相当于 10 个 CFS 调度周期) 内，进程队列的执行情况如下：

  • 在前面的 4 个 CFS 调度周期内，进程 A 和 B 由于 share 值是一样的，所以每个 CFS 调度内 (10ms)，进程 A 和 B 都会占用 5ms

  • 在第 4 个 CFS 调度周期结束的时候，在本 CFS 重分配周期内，进程 B 已经占用了 20ms，在剩下的 8 个 CFS 调度周期即 80ms 内，进程 B 都会被限流，一直到下一个 CFS 重分配周期内，进程 B 才可以继续占用 CPU

  • 在第 5-7 这 3 个 CFS 调度周期内，由于进程 B 被限流，所以进程 A 可以完全拥有这 3 个 CFS 调度的 CPU 资源，占用 30ms 的执行时间，这样在本 CFS 重分配周期内，进程 A 已经占用了 50ms 的 CPU 时间，在后面剩下的 3 个 CFS 调度周期即后面的 30ms 内，进程 A 也会被限流，一直到下一个 CFS 重分配周期内，进程 A 才可以继续占用 CPU

如果进程被限流了，可以在如下的路径看到：

cat /sys/fs/cgroup/cpu/kubepods/pod5326d6f4-789d-11ea-b093-fa163e23cb69/69336c973f9f414c3f9fdfbd90200b7083b35f4d54ce302a4f5fc330f2889846/cpu.stat

nr_periods 14001693

nr_throttled 2160435

throttled_time 570069950532853

本文开头问题的原因分析

根据 3.1 描述的原理，很容易理解本文开通的告警信息的出现，是由于在某些特定的 CFS 重分配周期内，kube-proxy 的 CPU 占用率超过了给它分配的 limits，而参看 kube-proxy daemonset 的配置，确实它的 limits 配置只有 200ms，这就意味着在默认的 100ms 的 CFS 重调度周期内，它只能占用 20ms，所以在特定繁忙场景会有问题：

$ cat cpu.shares
204
$ cat cpu.cfs_period_us
100000
$ cat cpu.cfs_quota_us
20000

注：这里 cpu.shares 的计算方法如下：200x1024/1000~=204

而这个问题的解决方案就是将 CPU limits 提高。

Zalando 公司有一个分享《Optimizing Kubernetes Resource Requests/Limits for Cost-Efficiency and Latency / Henning Jacobs》[3]很好的讲述了 CPU 资源管理的问题，可以参考，这个演讲的 PPT 在这里[4]可以找到。

更具体问题分析和讨论还可以参考如下文章：

  • CPUThrottlingHigh false positives #108[5]

  • CFS quotas can lead to unnecessary throttling #67577[6]

  • CFS Bandwidth Control[7]

  • Overly aggressive CFS[8]

其中《Overly aggressive CFS[9]》里面还有几个小实验可以帮助大家更好的认识到 CFS 进行 CPU 资源管控的特点：

参考资料

[1]

CFS(Completely Fair Scheduler) 调度器: https://www.kernel.org/doc/Documentation/scheduler/sched-design-CFS.txt

[2]

《Kubernetes 生产实践系列之三十：Kubernetes 基础技术之集群计算资源管理》: https://blog.csdn.net/cloudvtech/article/details/107634724

[3]

《Optimizing Kubernetes Resource Requests/Limits for Cost-Efficiency and Latency / Henning Jacobs》: https://www.youtube.com/watch?v=eBChCFD9hfs

[4]

PPT 在这里: https://www.slideshare.net/try_except_/optimizing-kubernetes-resource-requestslimits-for-costefficiency-and-latency-highload?from_action=save

[5]

CPUThrottlingHigh false positives #108: https://github.com/kubernetes-monitoring/kubernetes-mixin/issues/108

[6]

CFS quotas can lead to unnecessary throttling #67577: https://github.com/kubernetes/kubernetes/issues/67577

[7]

CFS Bandwidth Control: https://www.kernel.org/doc/Documentation/scheduler/sched-bwc.txt

[8]

Overly aggressive CFS: https://gist.github.com/bobrik/2030ff040fad360327a5fab7a09c4ff1

[9]

Overly aggressive CFS: https://gist.github.com/bobrik/2030ff040fad360327a5fab7a09c4ff1      

原文链接：https://blog.csdn.net/cloudvtech/article/details/107634785


你可能还喜欢

点击下方图片即可阅读

真是活久见，在 Minecraft 的虚拟游戏里竟然还能管理 Kubernetes！

云原生是一种信仰 ????

扫码关注公众号

后台回复◉k8s◉获取史上最方便快捷的 Kubernetes 高可用部署工具，只需一条命令，连 ssh 都不需要！

点击 "阅读原文" 获取更好的阅读体验！

❤️给个「在看」，是对我最大的支持❤️
米开朗基杨
关注
  • 3
    点赞
  • 踩
  • 10
    收藏
    觉得还不错? 一键收藏
  • 6
    评论
k8s中的Docker是什么
06-21
最近的三年多时间，随着容器技术的火爆及Kubernetes成为容器编排管理的标准，国内外厂商均已开始了全面拥抱Kubernetes的转型， 无数中小型企业已经落地 Kubernetes，或正走在容器化的道路上 。介绍docker的前世今生...
CPU ThrottlingHigh告警问题与数据指标采集
阿拉斯加大闸蟹的博客
01-31 7180
每5分钟采集一次container_cpu_cfs_throttled_periods_total和container_cpu_cfs_periods_total，根据差值计算Throttling百分比，连续三次(15分钟内)超过5%时即告警。每隔1分钟采集一次container_cpu_usage_seconds_total。cgroup cpuacct子系统cpu.stat中的nr_throttled。cgroup cpuacct子系统cpu.stat中的nr_periods。
当 Pod 崩溃后如何在报警信息中获取对应的日志信息？
DevOps持续集成的博客
03-21 258
Robusta 是一个 Python 开发的用于 Kubernetes 故障排除的开源平台。它位于你的监控堆栈（Prometheus、Elasticsearch 等）之上，并告诉你警报发生的原因以及如何修复它们。Robusta 包含三个主要部分，全部开源：用于 Kubernetes 的自动化引擎内置自动化以丰富和修复常见警报其他一些手动故障排除工具还有一些其他额外的可选组件：包含 Robusta、...
使用 Prometheus 来避免 K8s CPU Limits 造成的事故
云原生实验室
03-17 711
❝本文转自 charlieroro 的博客，原文：https://www.cnblogs.com/charlieroro/p/17074808.html，版权归原作者所有。欢迎投稿，投稿请添加微信好友：cloud-native-yang本文将介绍 Kubernetes 的 resource limits 是如何工作的、使用哪些 metrics 来设置正确的 limits 值、以及使用哪些指标来定位...
弹窗！到底谁是幕后黑手？
云原生实验室
07-20 277
Docker 技术鼻祖系列夜深了，程序员的电脑却没关······突然，桌面右下角弹出了一个窗口······五分钟后······又五分钟后······[ 完 ]本文纯属娱乐，请勿对号入座，...
AIDA64怎样算烤机通过 AIDA64烤机如何算稳定
xilan888的博客
04-02 8817
无论是资深硬件爱好者还是普通用户，在搭建一台兼容机或购买品牌PC设备后，均会对电脑进行烤机测试，以评价电脑日常使用的稳定性。今天向大家推荐一款专业的硬件管理软件AIDA64，除可以获取硬件信息外，AIDA64还可以对PC设备进行烤机测试，那么AIDA64怎样算烤机通过，或者说AIDA64烤机如何算稳定，本文将向大家做详细介绍。
Kubernetes OOM 和 CPU Throttling 问题
n9ecommunity的博客
07-21 942
使用 Kubernetes 时，内存不足（OOM）错误和 CPU 限制（Throttling）是云应用程序中资源处理的主要难题。为什么呢？云应用程序中的 CPU 和内存要求变得越来越重要，因为它们与您的云成本直接相关。通过limits和requests，您可以配置 pod 应如何分配内存和 CPU 资源，以防止资源匮乏并调整云成本。如果节点没有足够的资源，Pod 可能会因抢占或节点压力而被驱逐。当进程运行内存不足 (OOM) 时，它会因为没有所需的资源而被 Kill。如果 CPU 消耗高于实际。
Kubernetes生产实践系列之三十一：Kubernetes基础技术之CPU资源的调度和管理(CFS)
cloudvtech的博客
10-05 3113
一、前言 转载自https://blog.csdn.net/cloudvtech
容器CPU满载问题诊断思路
markMe1024的博客
07-24 480
x 轴表示抽样数，如果一个函数在 x 轴占据的宽度越宽，就表示它被抽到的次数多，即执行的时间长。注意，x 轴不代表时间，而是所有的调用栈合并后，按字母顺序排列的。在新增一个函数后，如果包含多线程的应用，或者代码里存在while死循环，或者担心占用内存过大频繁的触发gc。这里的单位是m的含义是 1000m=1核，所以如果该列的值接近或者超过2000m，代表该pod cpu接近满载。调用栈越深，火焰就越高，顶部就是正在执行的函数，下方都是它的父函数。，默认生成html格式的火焰图，存储在容器内的指定位置。
湖南麒麟实时操作系统调优指南
无知的我
11-25 4087
湖南麒麟实时操作系统的实时性是建立在正确地调优之上的。硬实时任务的要求较为苛刻，对系统的确定性以及稳定性有较高要求，需要硬件、系统以及软件的相互配合才能达到其要求。 硬实时任务对操作系统的延迟以及稳定性提出了非常苛刻的要求，为了满足这一要求，需要硬件、系统以及应用软件自身的配合。硬件与操作系统在设计时往往是要综合考虑各种各样的需求的，力图综合性能强大。而硬实时任务是一种特化的需求，这时就需要对操作系统以及硬件进行精细调整，以求收益的最大化。实时软件在部署时也需要针对硬件做...
AIDA64烤机温度正常是多少 AIDA64烤机结果怎么看
热门推荐
xilan888的博客
03-12 2万+
品牌型号：联想扬天T4900d 系统：Windows 10 专业版 软件版本：AIDA64试用版 部分用户可能电脑型号不一样，但系统版本一致都适合该方法。 使用AIDA64进行烤机测试非常方便，在软件内置的工具中，仅需几步就可以完成烤机测试，用户无需深入了解硬件知识，也无需复杂的软件设置。如何评估测试结果，很多用户可能不太了解，会有诸如AIDA64烤机温度正常是多少的疑问，本文就向大家介绍AIDA64烤机结果怎么看。 1.AIDA64烤机温度正常是多少 了解烤机测试中CPU温度变化规律之前，要先
如何利用K8S全面拥抱微服务架构？
01-27
K8S是第一个将“一切以服务为中心，一切围绕服务运转”作为指导思想的创新型产品，它的功能和架构设计自始至终都遵循了这一指导思想，构建在K8S上的系统不仅可以独立运行在物理机、虚拟机集群或者企业私有云上，也...
K8s中yaml文件详解（超详细）
06-07
K8s中yaml文件详解（超详细）
在k8s中部署mlflow模型服务.zip
11-03
在k8s中部署mlflow模型服务.zip在k8s中部署mlflow模型服务.zip在k8s中部署mlflow模型服务.zip在k8s中部署mlflow模型服务.zip在k8s中部署mlflow模型服务.zip在k8s中部署mlflow模型服务.zip在k8s中部署mlflow模型服务....
【1524】java投票管理系统Myeclipse开发mysql数据库web结构java编程计算机网页项目
qq_251836457的博客
04-18 644
2、开发环境为TOMCAT7.0,Myeclipse8.5开发，数据库为Mysql5.0，使用java语言开发。(5)投票选项管理：对投票选项信息进行添加、删除、修改和查看。(6)投票记录管理：对投票记录信息进行添加、删除、修改和查看。(1)管理员管理：对管理员信息进行添加、删除、修改和查看。(2)用户管理：对用户信息进行添加、删除、修改和查看。(3)公告管理：对公告信息进行添加、删除、修改和查看。(4)投票管理：对投票信息进行添加、删除、修改和查看。4）投票浏览查看、查看投票、投票记录。
ReentrantLock
最新发布
Adepth的博客
04-22 608
这是标准库给我们提供的另一种锁，前面我们学到的一种是顾名思义，Reentrant:可重入的 但我们也知道，synchronized锁不也是可重入的嘛?那这个锁到底有什么其他的过人之处呢？
Web前端 Javascript笔记5
cycyzh的博客
04-18 840
script>'console.log("哈哈哈佳人们好困")'}, 3000)​let t1 = setTimeout('console.log("你们看到这句话的时候我早已身价百万！！")', 4000)​</script>3秒，四秒后出来的东西，出现前会返回计时器编号。
2.8 构建gradle环境
蚊者逆袭的博客
04-18 2156
Gradle是一种现代化的构建工具，用于自动化地构建、测试和部署软件项目。它是一种基于JVM（Java虚拟机）的构建工具，最初是为了解决Apache Ant和Apache Maven等传统构建工具的一些限制而开发的。
JUC(java.util.concurrent) 的常见类
weixin_43497876的博客
04-20 1168
Callable 是一个 interface（类似之前的 Runnable，用来描述一个任务，但是没有返回值）也是描述一个任务的，有返回值。方便程序猿借助多线程的方式计算结果.创建线程计算 1 + 2 + 3 + ... + 1000, 不使用 Callable。
在 CentOS 7 中搭建 K8S 集群的步骤是什么?
08-26
### 回答1： 在 CentOS 7 中搭建 K8S 集群的步骤如下: 1. 安装 Docker: K8S 需要使用 Docker 作为容器引擎, 因此需要在每个节点上安装 Docker。 2. 安装 kubeadm, kubelet 和 kubectl: kubeadm 是用于在 CentOS 上安装和管理 K8S 集群的工具, kubelet 是 K8S 的主要组件, 用于在节点上运行容器, kubectl 是 K8S 的命令行工具, 用于管理集群。 3. 初始化集群: 使用 kubeadm 初始化集群, 在一个节点上运行 kubeadm init 命令。 4. 加入节点: 使用 kubeadm join 命令在其他节点上加入集群。 5. 安装网络插件: 为了使容器之间可以通信, 还需要安装一个网络插件, 常用的有 Flannel 和 Calico。 6. 部署应用: 可以使用 kubectl 命令在集群中部署应用, 或者使用其他工具如 Helm。 希望这些信息能够帮助你。 ### 回答2： 在CentOS 7中搭建K8S集群的步骤如下： 1. 首先，确保所有节点上的操作系统为CentOS 7，并且所有节点之间能够互相通信。 2. 在所有节点上安装Docker并启动Docker服务。可以通过以下命令进行安装： $ sudo yum install -y docker $ sudo systemctl start docker $ sudo systemctl enable docker 3. 配置Docker的系统参数以支持Kubernetes。通过编辑/etc/docker/daemon.json文件，添加以下内容： { "exec-opts": ["native.cgroupdriver=systemd"] } 4. 配置Kubernetes的YUM源，并安装Kubernetes所需的软件包。可以通过以下命令进行安装： $ sudo vi /etc/yum.repos.d/kubernetes.repo 添加以下内容： [kubernetes] name=Kubernetes baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64 enabled=1 gpgcheck=1 repo_gpgcheck=1 gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg $ sudo yum install -y kubelet kubeadm kubectl 5. 配置Kubernetes集群的Master节点。在Master节点上执行以下命令： $ sudo kubeadm init 6. 完成Kubernetes集群的Master节点配置后，按照命令输出的指引，将所需的配置文件拷贝到合适的位置，并设置kubectl的配置文件。例如： $ mkdir -p $HOME/.kube $ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config $ sudo chown $(id -u):$(id -g) $HOME/.kube/config 7. 启动Kubernetes集群的网络插件。可以选择任何支持的网络插件，例如Calico、Flannel等。执行以下命令以安装Calico插件： $ kubectl apply -f https://docs.projectcalico.org/v3.14/manifests/calico.yaml 8. 加入其他节点到Kubernetes集群。按照输出的命令在其他节点上执行以加入集群，例如： $ sudo kubeadm join <Master节点IP>:<Master节点端口> --token <Token值> --discovery-token-ca-cert-hash <CA证书哈希值> 9. 检查Kubernetes集群的状态。执行以下命令以查看集群中节点的状态： $ kubectl get nodes 10. 完成以上步骤后，Kubernetes集群的搭建就完成了。您现在可以开始使用Kubernetes来部署和管理容器应用程序了。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 6
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值