Question 1 | NamespacesThe DevOps team would like to get the list of all Namespaces in the cluster. Get the list and save it to /opt/course/1/namespaces. Answer:12k get ns > /opt/course/1/namespaces The content should then look like: 12# /opt/course/1/namespacesNAME           STATUS   AGEdefault       Active   150mearth         Active   76mjupiter       Active   76mkube-public   Active   150mkube-system   Active   150mmars           Active   76mmercury       Active   76mmoon           ...

简述 这个认证相比较CKA，难度一般，内容在k8s应用上会更丰富一些，但也都比较基础，运维/开发同学报考1-2周考下来，毫无压力。 惟手熟尔，考试时间很充裕，但前提是要有一定Linux命令基础，考试课程提供了1套练习题，可以练习2次，尽可能2小时内完成所有题目，个人考试80分钟就完成了，20分钟所有题目都检查一遍，另外，不会做的要跳过，切勿因小失大。 考试期间是可以翻看官方文档的，一定是根据关键字搜索使用的。另外kubectl 命令行帮助文档很有用，大部分题目是不需要翻官方文档的，通过命令行就可以创建大部分资源。如果每道题都翻看文档，时间就可能不会特别充裕。 考试结果 考试大纲参考：https://training.linuxfoundation.cn/certificates/4 考试课程包括这些一般领域及其在考试中的权重： 应用程序设计和构建–20% 应用部署 - 20％ 应用观察和维护 - 15％ 应用环境、配置与安全 - 25％ 服务与网络 - 20％ 详细内容 应用程序设计和构建–20% 定义、构建和修改容器鏡像 了解Jobs 和 CronJobs 了解多容器Pod ...

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

背景由于公司目前开始全面开始推进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 ...

考试心得我是去年3月份考的CKA，5月份考了2次都没有过CKS，主要还是因为个人没有复习好，刷题太少，2次考试都没有过。后来又重新找了几篇2023年最新的真题，针对的进行练习。我几次考CKS经验来看，如果考试题目不熟练的话，时间大概率不够的。由于2022年7月份之后考试PSI系统进行了升级，所有操作都要在ubuntu20.04主机上进行，包括浏览器。 第一题 kube-bench 修复不安全项12345678910111213141516171819Context针对kubeadm创建的cluster运行CIS基准测试工具时，发现了多个必须立即解决的问题。Task通过配置修复所有问题并重新启动受影响的组件以确保新的设置生效。修复针对API服务器发现的所有以下违规行为：1.2.7 Ensure that the --authorization-mode argument is not set to AlwaysAllow FAIL1.2.8 Ensure that the --authorization-mode argument includes Node F ...

环境信息 os 版本： centos7.9 kernel 版本：3.10.0-1160.59.1.el7.x86_64 k8s 版本：v1.19.4 calico-node 版本：v3.8.8-1 问题描述calico异常重启导致容器网络异常超时，查看日志发现报错如下：failed to create new OS thread 123456789101112131415161718192021222324252627282930313233343536373839404142# 获取异常节点calico-node重启多次kubectl -n kube-system get pod -owide | grep calico-node-56bgmcalico-node-56bgm 1/1 Running 21 246d 10.165.6.26 10.165.6.26 <none> <none># 查看calico-node历史日志如下：kub ...

vmcore是什么？vmcore是指操作系统在遇到致命错误（比如内核崩溃）时所生成的内存转储文件。这个文件包含了操作系统在崩溃前的内存状态，因此可以用于诊断崩溃的原因。 在 Linux 系统中，当内核崩溃时，通常会生成一个称为vmcore的文件。该文件位于/var/crash目录下，其命名类似于vmcore.<时间戳>。vmcore文件通常是非常大的，因为它包含了操作系统在崩溃前的全部内存内容。 一般情况下，vmcore文件可以通过分析工具进行分析，以确定崩溃的原因。例如，可以使用GNU Debugger（GDB）或crash工具来分析vmcore文件。 手动触发vmcore的文件vmcore文件通常是在系统遇到严重故障、例如操作系统崩溃或Panic时自动生成的，而无法手动触发。在一些情况下，我们可能需要手动触发一个vmcore文件的生成，例如在进行内核调试时。这时，可以使用kdump工具来手动触发vmcore文件的生成。 安装kexec-tools和kernel-debuginfo包这里系统采用的CentOS7.9 12# yum install yum-utils ke ...

在Linux系统内默认对所有进程打开的文件数量有限制（也可以称为文件句柄，包含打开的文件，套接字，网络连接等都算是一个文件句柄） 查看当前系统限制最大文件打开数量12cat /proc/sys/fs/file-max2000000 查询当前系统已打开文件数量12cat /proc/sys/fs/file-nr8640 0 2000000 # 左边的值为当前系统已打开文件数量，右侧表示当前系统限制最大文件打开数 以上查询得知当前系统打开文件句柄数未达到上限，往下排查Docker进程的最大文件句柄数限制及已打开文件数 查询当前Docker进程最大可打开文件数量及已打开文件数量123456systemctl status docker | grep PID #获取Docker进程的PID号Main PID: 14644 (dockerd)cat /proc/`pidof dockerd`/limits# 或者使用ls -l /proc/`pidof dockerd`/fd/* | wc -l ## 获取当前Docker进程已打开的文件数量65342 ...

环境信息 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 ...

问题描述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. ...