往期回顾
Kubernetes学习周报（第11期 ）Golang在 K8S中运行的内存限制; 探索Cilium和Istio实现; 容器分层
Kubernetes学习周报（第10期 ）如何保持容器运行以调试; ETCD Raft 协议;Kubectl端口转发详解
Kubernetes学习周报（第9期 ）: CNI 和网络命名空间；网络插件基准测试；K8S备份解决方案Velero实施指南
Kubernetes学习周报（第8期 ）:K8S网络数据包管理之旅；当K8S和 Go 不能很好地协同工作时；K8S探针配置
Kubernetes学习周报（第7期 ）:K8S容器运行时CRI接口；Kluctl管理集群API；K8S无服务器应用监控
Kubernetes学习周报（第六期 ）:K8S API 实用指南；Etcd灾难恢复方案；K8S Gateway API介绍
Kubernetes学习周报（第五期 ）: K8S隐藏的“OOM 终止”问题；一个K8S命令引发的悲剧；Cilium的BGP功能
Kubernetes学习周报（第四期 ）: K8S中使用 Wireshark；K8S安全清单；如何缩小Docker镜像
Kubernetes学习周报（第三期 ）: Kubernetes 健康检查，如何使用 runc 生成容器
Kubernetes学习周报 : 一周好文推荐，K8s 网络请求分析，多集群 Kubernetes 的 7 个注意事项
为什么有时无法在容器中终止 PID 1 进程
https://freedium.cfd/https://blog.devops.dev/why-sometimes-the-pid-1-process-cannot-be-killed-in-a-container-b1c2debb4ca1
本文解释了为什么无法使用 'kill' 命令杀死容器中的 PID 1 进程（init 进程），即使使用像 SIGKILL 这样的信号也是如此。它涵盖两个主要概念：init 进程和 Linux 信号。
关键点：
1. 初始化进程：
- 每个容器运行一个 PID 为 1 的主进程，称为 init 进程。
- 此进程负责管理容器内的其他进程。
- init 进程不能轻易终止，因为它在 Linux 内核中具有特殊处理。
2. Linux 信号：
- 信号是发送到进程以触发特定操作的通知。
- 常见信号包括 SIGTERM （请求终止） 和 SIGKILL （强制终止）。
- init 进程被标记为 “SIGNAL_UNKILLABLE”，这意味着它默认忽略这些信号。
3. 不同程序的行为：
- 本文将各种程序（bash、C、Golang）作为 init 进程进行测试，以观察它们对 kill 命令的响应。
- 结果各不相同：虽然 SIGKILL 无法终止 init 进程，但如果该进程为其注册了处理程序，则 SIGTERM 可以成功。
4. 内核实现：
- 内核的信号处理逻辑根据进程是否注册了自定义处理程序等条件来确定是否处理信号。
- 如果没有自定义处理程序，init 进程默认忽略 SIGTERM。
结论：
无法杀死容器中的 init 进程源于它在 Linux 内核中的独特角色和处理方式。了解 init 进程和信号处理之间的相互作用对于在容器化环境中管理进程至关重要。
容器中 Zombie 进程的原因和解决方案
https://freedium.cfd/https://blog.devops.dev/causes-and-solutions-for-zombie-processes-in-containers-35a9da1b8bd3
本文探讨了容器中僵尸进程的原因和解决方案，这是操作系统访谈中的一个常见话题。
关键点：
1. 定义：僵尸进程是指那些已经完成执行但在进程表中仍有条目的进程。当与“ps”等命令一起列出时，它们显示为“defunct
2. 症状：用户在正在运行的容器中执行命令时可能会注意到僵尸进程，从而导致资源问题。
3. 进程状态：在 Linux 中，进程会经历各种状态，包括运行、休眠和终止 （EXIT_DEAD） 前的僵尸 （EXIT_ZOMBIE）。
4. 资源限制：容器可以达到它们可以运行的进程数量限制，由“pids”控制组 （Cgroup） 控制。如果超过限制，则无法创建新进程，从而导致操作失败。
5. 创建机制：当父进程无法调用 'wait（）' 或 'waitpid（）' 从其终止的子进程中回收资源时，就会出现僵尸进程。
6. 解决方案：
- 使用 Cgroup 中的 'pids.max' 文件对容器中的进程数量实施限制。
- 确保父进程正确处理子进程出口以防止出现僵停状态。
- 使用 'waitpid（）' 和 'WNOHANG' 选项来避免在检查僵尸进程时阻塞。
结论：
了解僵尸进程及其管理对于维护正常运行的容器化应用程序至关重要。正确处理子进程可以防止资源耗尽并确保系统稳定性。
了解 Kubernetes 中的 DNS
https://povilasv.me/understanding-dns-in-kubernetes/
本文讨论了 DNS 在 Kubernetes 中的关键作用，重点介绍了它如何通过允许应用程序使用人类可读的域名而不是 IP 地址来促进服务发现。CoreDNS 被标识为 Kubernetes 中的默认 DNS 提供程序。
关键点：
1. CoreDNS 概述
- CoreDNS 在 Kubernetes 集群中作为部署运行，负责 DNS 解析和服务发现。
2. Kubernetes DNS 策略
- ClusterFirst：Pod 的默认策略，将 DNS 查询定向到 kube-dns 服务。
- 默认：从节点继承 DNS 设置。
- ClusterFirstWithHostNet：将 ClusterFirst 行为应用于使用主机网络的 Pod。
- 无：允许自定义 DNS 配置。
3. DNS 解析机制：
- 应用程序通常使用 'getaddrinfo' 函数通过 C 标准库 （libc） 与 DNS 交互。
- “/etc/resolv.conf”文件配置至关重要，它指定 DNS 服务器的 IP 地址。
4. DNS 库比较：
- 讨论了 glibc 和 musl 库之间的差异，特别是 musl 如何并行解析 DNS 查询，从而可能加快解析速度。
5. 实验进行：
- 各种实验展示了不同的 DNS 策略和实施如何影响查询行为，包括处理不存在的域、无响应的名称服务器和缓慢的 DNS 响应。
6. 性能详情：
- 结果表明，DNS 客户端实现的选择会显著影响应用程序性能，尤其是在涉及超时或响应缓慢的情况下。
结论
本文强调了选择适当的 DNS 设置以优化 Kubernetes 环境中的应用程序性能的重要性。
Helm + Kustomize + Raw Manifests组合
https://itnext.io/helm-kustomize-raw-manifests-combination-570f81acf996
本文讨论了 Helm、Kustomize 和raw manifests的集成，以简化 Kubernetes manifests管理。它概述了如何组合这些工具来创建高度可定制的部署工作流，从而提高 Kubernetes 环境中的适应性和效率。
关键点：
1. 工具介绍：
- Helm：一个适用于 Kubernetes 的包管理器，可简化应用程序的部署。
- Helmfile：在单个规范文件中管理多个 Helm chart。
- Kustomize：允许通过补丁自定义 Kubernetes manifests
- Raw manifests：可以直接应用于 Kubernetes 的基本 YAML 文件
2. 组合工具的基本原理：
- 自定义 Helm chart可能会导致与原始chart不同，从而使更新变得困难。
- 当无法修改现有 Helm chart时，可以包含Raw manifests。
3. 实现方式：
- 本文介绍了一种融合了 Helm、Kustomize 和原始清单优势的算法。
- 流程图说明了该过程，强调Raw manifests具有最高优先级。
4. 目录结构：
- 提供了一个示例目录布局，展示了如何组织 Helm、Kustomize 和原始清单文件。
5. 管道代码：
- 共享一个示例 GitLab CI 管道，以使用这些工具自动化部署过程。
6. 结论：
- 集成方法提供了前所未有的灵活性和对 Kubernetes 部署的控制，可有效适应各种场景。
保护生产工作负载的 Kubernetes Pod
https://dev.to/thenjdevopsguy/securing-kubernetes-pods-for-production-workloads-51oh
本文强调了正确保护 Kubernetes Pod 以降低与潜在攻击相关的风险的重要性。
关键点：
1. 保护 Pod 的重要性：Pod 是攻击者的重要切入点，其安全性至关重要。本文重点介绍策略实施、用户访问、服务账户和流量管理等方面。
2. SecurityContext：这是一个关键功能，可以同时应用于 Pod 和 Container 级别。主要配置包括：
- runAsNonRoot：确保 Pod 以非 root 用户身份运行。
- allowPrivilegeEscalation：阻止进程获取其他权限。
- readOnlyRootFilesystem：将文件系统挂载为只读以增强安全性。
3. Pod 安全标准 （PSS）：这些标准将安全策略分为三个级别：
- 特权：不受限制的访问。
- Baseline：有一些限制的中间立场。
- 受限：遵循严格的安全最佳实践。
4. 策略实施：建议使用带有 Gatekeeper 和 Kyverno 的 Open Policy Agent （OPA） 等工具来实施安全策略和防止错误配置。
5. 网络策略：这些策略管理 Pod 之间的流量，确保通信受控和安全。
6. 准入控制器：所有 Kubernetes 流量都通过这些控制器进行验证，这些控制器会执行策略并阻止未经授权的请求。
本文提供了实际示例和配置，以帮助用户在其 Kubernetes 环境中有效地实施这些安全措施。
《K8S容器基础培训》系列视频
更多K8S学习资料以及SRE学习手册，请扫码私信领取哦！
