背景由于公司目前开始全面开始推进ubuntu系统的使用，使用时发现内核更新太过频繁，对于ubuntu桌面版本内核升级可能会提升用户体验和安全性，但对于ubuntu server服务器，我们一般会采用固定版本。默认情况下ubuntu不管是桌面版还是server版本，执行 apt update会升级下载所有需要升级的包（包括内核包）。版本固定方便统一维护，如果某个版本的内核存在bug，可以安排统一更新。 升级和卸载内核1、升级内核 123456789101112131415161718# 查看当前内核uname -r# 升级软件包sudo apt update# 查看可用内核apt-cache search linux-image# 选择合适的内核进行安装sudo apt-get install linux-image-XXXX-genericor 之前执行过 sudo apt update 更新过，执行如下dpkg --list | grep linux-imageor 另外，可以自行下载制定内核进行安装，下载地址如下：http://kernel.ubuntu.com/~kernel-p ...

环境信息 kubelet： v1.19.10 os：centos7.9 deploy：kubeasz 概览当 Kubernetes 中 Node 节点出现状态异常的情况下，节点上的 Pod 会被重新调度到其他节点上去，但是有的时候我们会发现节点 Down 掉以后，Pod 并不会立即触发重新调度，这实际上就是和 Kubelet 的状态更新机制密切相关的，Kubernetes 提供了一些参数配置来触发重新调度的时间，为了简单起见，将跳过 HA 的部分，仅描述 Kubelet<->Controller Manager 通信流程。 默认情况下，正常行为： kubelet 自身会定期更新状态到 apiserver，通过参数 –node-status-update-frequency 指定上报频率，默认是 10s 上报一次。 Kubernetes controller manager 每隔 –node-monitor-period 检查 Kubelet 的状态。默认值为 5 秒。 如果状态在 –node-monitor-grace-period 时间内更新，Kubernetes c ...

背景在 Kubernetes 集群运行时，节点有时会因为组件问题、内核死锁、资源不足等原因不可用。Kubelet 默认对节点的 PIDPressure、MemoryPressure、DiskPressure 等资源状态进行监控，但是存在当 Kubelet 上报状态时节点已处于不可用状态的情况，甚至 Kubelet 可能已开始驱逐 Pod。在此类场景下，原生 Kubernetes 对节点健康的检测机制是不完善的，为了提前发现节点的问题，需要添加更加细致化的指标来描述节点的健康状态并且采取相应的恢复策略，实现智能运维，以节省开发和减轻运维人员的负担。 NPD 故障检测NPD（node-problem-detector）是 Kubernetes 社区开源的集群节点的健康检测组件。NPD 提供了通过正则匹配系统日志或文件来发现节点异常的功能。用户可以通过运维经验，配置可能产生异常问题日志的正则表达式，选择不同的上报方式。NPD 会解析用户的配置文件，当有日志能匹配到用户配置的正则表达式时，可以通过 NodeCondition、Event 或 Promethues Metric 等方式将检测到的 ...

题目要求 在清单文件 /ckad/CKAD00016/periodic.yaml 中定义此 Pod 在一个 busybox:stable 容器中运行命令 date 该命令必须每分钟运行一次，并且必须在 10 秒内完成运行，或者被 Kubernetes 终止运行。注意： CronJob 名称和容器名称都必须为 hello 在上述清单文件中创建此资源，并验证此 Job 至少成功执行一次。 参考https://kubernetes.io/zh-cn/docs/tasks/job/automated-tasks-with-cron-jobs/ https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/job/ 解答123456789101112131415161718192021222324252627282930313233343536373839404142# 1.编辑文件vim /ckad/CKAD00016/periodic.yaml# 2.根据要求编辑文件内容apiVersion: batch/v1kind: C ...

题目要求namespace goshawk 中名为 chipmunk-service 的 Service 指向名为 current-chipmunk-deployment 的 Deployment 创建的 5 个 Pod 你可以在 /ckad/goshawk 中找到 current-chipmunk-deployment 的清单文件。 在同一 namespace 中创建一个 相同的 Deployment 名为 canary-chipmunk-deployment 修改 Deployment 以便 在 namespace goshawk 中运行的 Pod 的最大数量为 10 个 chipmunk.service 流量的 40% 流向 Pod canary-chipmunk-deployment 参考https://kubernetes.io/zh-cn/docs/concepts/cluster-administration/manage-deployment/#canary-deployments 解答123456789101112131415161718192021222 ...

准备 OS版本：CentOS7.6.1810 内核版本：5.4.207-1.el7.elrepo.x86_64 依赖包：1234567#内核依赖包rpm -qa | grep kernel-ltkernel-lt-tools-5.4.207-1.el7.elrepo.x86_64kernel-lt-tools-libs-5.4.207-1.el7.elrepo.x86_64kernel-lt-devel-5.4.207-1.el7.elrepo.x86_64kernel-lt-5.4.207-1.el7.elrepo.x86_64kernel-lt-headers-5.4.207-1.el7.elrepo.x86_64 安装内核必须升级到4.x版本以上，才可以使用。我的内核版本已经升级过，具体升级内核过程这里不展开，建议使用elrepo 安装高版本内核。 12345678910111213#安装bcc-toolsyum install -y bcc-tools#添加环境变量export PATH=$PATH:/usr/share/bcc/tools# 测试#cachestat ...

CPU绑核配置默认情况下，kubelet 使用 CFS 配额 来执行 Pod 的 CPU 约束。 当节点上运行了很多 CPU 密集的 Pod 时，工作负载可能会迁移到不同的 CPU 核， 这取决于调度时 Pod 是否被扼制，以及哪些 CPU 核是可用的。许多应用对这种迁移不敏感，因此无需任何干预即可正常工作。有些应用对CPU敏感，CPU敏感型应用有如下特点。 对CPU throttling 敏感 对上下文切换敏感 对处理器缓存未命中敏感 对跨socket内存访问敏感 期望运行在同一物理CPU的超线程 如果您的应用有以上其中一个特点，可以利用kubernetes中提供的绑核策略去给应用绑核，提升应用性能，减少应用的调度延迟。cpu manager会优先在一个Socket上分配资源，也会优先分配完整的物理核，避免一些干扰。 如何为Pod绑核想要让Pod能够绑核，有如下几点要求： 节点上开启静态绑核策略。 Pod的定义里都要设置request和limits，request和limits要一致。 对于要绑核的容器，request值必须是整数。 如果有init container希望进行绑 ...

问题描述1、磁盘容量告警 2、对主机进行磁盘检查并尝试清理磁盘占用较高的pod，有5900多个文件描述符被打开没有关闭。 通过平台删除该pod: product-center-query-pro-remain-5bfb5f4c98-m2l55 3、主机负载冲高，触发告警 根因排查1、根据系统日志发现磁盘最早在5月28日就出现了磁盘inode统计超时情况。 2、发现有个容器在/tmp目录创建了很多小文件，占用了大量的磁盘空间及Inode，可能是导致磁盘响应变慢的直接原因。 解决方案 立即对主机进行疏散，避免再次出现异常，导致主机负载升高，影响业务pod。 增加该kubelet日志告警（fs: disk usage and inodes count on following dirs took 1），提前发现及时人工介入进行处理。

问题描述1、根据业务方的反馈，有2个容器之前存在网络延迟，但同一集群并未有其他人反馈异常 pod1（10.165.74.252） —> pod2（10.165.210.88） ping延迟稳定4个包出现一个包延迟200-400ms 根因分析1、检查物理机管理控制台日志，排查是否存在异常日志，登录带外检查并未发现异常。 2、检查了容器网络，我们集群CNI用的是calico，检查主机上calico-node状态正常，并且日志并未发现异常。 123# 2个容器所在节点上calico-node状态正常，日志并未发现异常日志。calico-node-7np2p 1/1 Running 0 322d 10.165.6.25 10.165.6.25 <none> <none>calico-node-gcn4c 1/1 Running 0 11d 10. ...

题目要求 用执行命令**’date; echo Hello from the Kubernetes cluster’**的镜像 busybox ，创建一个名为 busybox-job 的 Job 。 修改此 Job ，确保在执行时间超过 3000 秒后，kubernetes 会自动终止该 Job。 如果容器失败，则尝试重启容器，但最多尝试重启 5 次。 检查此Job的日志 参考https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/job/ 12345678910111213141516# 参考命令kubectl explain job.spec# 配置示例apiVersion: batch/v1kind: Jobmetadata: name: pispec: template: spec: containers: - name: pi image: perl:5.34.0 command: ["perl", "-Mbign ...