Kubernetes学习周报（第17期 ）：了解StatefulSet的拓扑状态；实现高级Rollout策略；K8S攻击威胁矩阵

欢迎点击下方👇关注我，记得星标哟~

文末会有重磅福利赠送

往期回顾

Kubernetes学习周报（第16期 ）：RBAC的工作原理；K8S网络策略；探索 Istio 流量管理

Kubernetes学习周报（第15期 ）：容器干扰检测和缓解；网络解决方案比较；Pod 资源大小调整方案；迁移Hpa到Keda

Kubernetes学习周报（第14期 ）：如何将节点服务无缝过渡到 K8S；OpenAI 的容器运行时和沙盒架构；存储性能比较

Kubernetes学习周报（第13期 ）K8S APIs 之CRD; PDB详解; 解决由大量IPVS规则引起的网络延迟问题

Kubernetes学习周报（第12期 ）何时无法在容器中终止 PID 1 进程;容器中僵尸进程解决办法; K8S中的DNS

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 中的部署详细说明

https://blog.devops.dev/detailed-explanation-of-deployments-in-kubernetes-80450a62aa0b

本文全面概述了  Kubernetes 中的 Deployment 控制器模式，重点介绍了它的实现以及在管理 Pod 和 ReplicaSet 中的重要性。

关键概念

Deployment

·目的：促进应用程序的水平扩展和滚动更新。

·功能：通过 ReplicaSet 管理 Pod 的生命周期。

apiVersion: apps/v1kind: Deploymentmetadata:  name: nginx-deployment  labels:    app: nginxspec:  replicas: 3  selector:    matchLabels:      app: nginx  template:    metadata:      labels:        app: nginx    spec:      containers:        - name: nginx          image: nginx:1.7.9          ports:            - containerPort: 80

ReplicaSet 副本集

示例

apiVersion: apps/v1kind: ReplicaSetmetadata:  name: nginx-set  labels:    app: nginxspec:  replicas: 3  selector:    matchLabels:      app: nginx  template:    metadata:      labels:        app: nginx    spec:      containers:        - name: nginx          image: nginx:1.7.9

滚动更新

·过程：当 Deployment 更新时（例如，更改容器镜像），它会触发滚动更新，创建新的 Pod，同时逐渐缩减旧的 Pod。

用于管理 Deployment 的命令

·创建 Deployment：

·kubectl create -f nginx-deployment.yaml --record

·扩展部署：

·kubectl scale nginx-deployment --replicas=4

·检查状态：

·kubectl rollout status deployment/nginx-deployment·

回滚命令：

·kubectl rollout undo deployment/nginx-deployment

管理 ReplicaSet

Kubernetes 保留有限数量的历史 ReplicaSet，由 spec.revisionHistoryLimit 控制。

结论

Kubernetes 中的 Deployment 控制器对于管理应用程序版本和通过 ReplicaSets 确保 Pod 的所需状态至关重要。它支持滚动更新和扩展操作，使其成为 Kubernetes 编排的关键组件。

深入了解 Kubernetes 中 StatefulSet 中的拓扑状态

https://freedium.cfd/https://blog.devops.dev/in-depth-understanding-of-topology-state-in-statefulset-in-kubernetes-50d2306588df

本

关键概念

1. 有状态应用程序与无状态应用程序：

   - 无状态应用程序：Pod 是相同的，可以创建或销毁，而无需担心顺序。

   - 有状态应用程序：实例具有依赖关系（例如，主从关系），需要特定的排序和稳定的身份。

2. StatefulSet （有状态集）：    

   - 旨在通过维护两种状态来管理有状态的应用程序：

   - 拓扑状态：确保 Pod 以特定顺序启动并保留其网络身份。

   -存储状态：保证每个实例都有唯一的存储，该存储在 Pod 重启后仍然存在。

3. 无服务：

   - 一种特殊类型的服务，允许在没有虚拟 IP （VIP） 的情况下直接访问 Pod。

   - 它使用 DNS 记录来暴露 Pod，从而实现稳定的网络身份。

具体实现

- YAML 配置：提供了用于创建 Headless Service 和 StatefulSet 的 YAML 文件示例。

- Pod 创建：使用编号方案 （name-index） 命名 Pod 以保持顺序和身份。

- DNS 解析：每个 Pod 都可以通过唯一的 DNS 记录访问，确保稳定的通信。

观察

- Pod 是按顺序创建的，严格遵守其定义的顺序。

- 删除 Pod 时，Kubernetes 会使用相同的身份重新创建它们，同时保持拓扑状态。

结论

StatefulSet 通过提供强大的机制来管理有状态应用程序，通过使用无服务和 DNS 记录确保稳定的身份和操作顺序，从而增强了部署。本文为进一步探索 StatefulSet 在以后的讨论中如何处理存储状态奠定了基础。   

高级Rollout技术：Kubernetes 中有状态应用的自定义策略    

https://slack.engineering/kube-stateful-rollouts/

本文讨论了 Slack 使用通过 Kubebuilder 构建的自定义 Operator 在 Kubernetes 中部署有状态应用程序的方法。它涵盖了 StatefulSet 的原生 Kubernetes 更新策略的限制、Bedrock Rollout Operator 的架构和工作流程，以及 Slack 在支持大规模应用程序时面临的挑战。 

关键点

- Slack 的团队要求更可控的Rollout，包括更快的基于百分比的发布、更快的回滚、暂停Rollout的能力，以及与他们的内部服务发现和 Slack 的集成。 

- Slack 构建了 Bedrock Rollout Operator，这是一个管理 StatefulSet 部署的 Kubernetes Operator，提供暂停、基于百分比的部署和 Slack 通知等功能。 

- Operator 的工作原理是将自定义 StatefulsetRollout 资源中定义的所需状态与集群的实际状态进行协调，并采取措施使目标更接近预期状态。 

- Operator将元数据保存在自定义资源的状态中，使其能够执行顺序调节并避免竞争情况。 

- Slack 在对具有数千个 Pod 的大型 StatefulSet 进行速率限制 Slack 通知方面遇到了挑战，并且在使用 OnDelete 更新策略时遇到了“版本泄漏”问题。 

- Slack 正在探索在未来使用现有的 CNCF 项目（如 Argo Rollouts 和 OpenKruise）来管理部署资源。

 Kubernetes 网络策略指南

https://buoyant.io/blog/a-guide-to-modern-kubernetes-network-policies

本文讨论了网络策略在 Kubernetes 中控制集群内流量的重要性，帮助 Kubernetes 用户和传统网络工程师实现有关网络流量的基于策略的控制。

什么是网络策略？

·定义：网络策略定义了允许进入（ingress）、退出（egress）和在 pod 之间移动的流量。

·配置：它们是 Kubernetes 组件用于强制执行流量规则的声明性配置。

网络策略的类型

网络策略大致可以分为两种主要类型：

1.第四层（L4）策略：

·在传输层（例如 TCP）操作。

·由容器网络接口（CNI）插件实现。

·使用 NetworkPolicy.networking.k8s.io 资源根据 IP 地址和端口控制流量。

·优点：简单，内置于大多数 CNI 插件中。

·缺点：表达能力有限，没有日志记录，易受欺骗和“分脑”场景的影响。

2.第七层（L7）策略：

·在应用层（例如 HTTP、gRPC）操作。

·通过服务网格如 Linkerd 实现。

·允许对流量进行更细粒度的控制，包括特定端点的规则。

·优点：细粒度控制，支持用于身份验证和加密的互 TLS，提供日志记录。

·缺点：需要运行服务网格，不适用于未网格化的工作负载或非 TCP 流量。

结合 L4 和 L7 策略

·可以同时使用这两种策略以增强安全性。    

·L4 策略适合对未网格资源强制执行规则，而 L7 策略提供复杂的细粒度控制。

结论

网络策略是保护 Kubernetes 集群的基本要素。通过利用 L4 和 L7 策略，并使用像 Linkerd 这样的服务网格，组织可以实施强大的零信任安全模型，以应对现代安全挑战。

了解 Kubernetes 攻击矩阵

https://medium.com/beyond-devsecops/a-pragmatic-look-at-the-kubernetes-threat-matrix-d58504e926b5

本文提供了一种实用的方法来理解和解决 Kubernetes 环境中的安全挑战。它强调了上下文优先级、构建安全路线图和了解 Kubernetes 威胁矩阵的重要性。

关键点

上下文优先级

·构建一个安全的Kubernetes平台需要关注最相关的漏洞。

·不是所有漏洞都可以同等优先考虑；上下文至关重要。

·关键考虑因素包括：

·漏洞的可利用性。

·环境（生产环境与开发环境）。

·容器的提升访问级别。

Kubernetes威胁矩阵    

·提供从威胁行为者的角度看潜在威胁的高层次概述。

·需要根据特定环境、工作负载和配置进行定制。

·有助于基于识别的漏洞创建安全路线图。

Kubernetes安全路线图

·涉及优先考虑安全要求并理解攻击面。

·需要探索的关键领域：

·容器注册表和镜像。

·Kubernetes秘密的注入和加密。

·CI/CD流程和入口配置。

Kubernetes Secret

·Secret存储在ETCD中，与元数据一起。

·加密Secret的重要性，以防在备份过程中暴露。

·保护Secret的深度防御策略，包括：

·在运行时访问Secret。

·监控异常使用情况。

·最小权限访问控制。

结论

维护Kubernetes安全性具有挑战性。基于上下文优先级和对威胁矩阵的深入理解的策略至关重要。组织应记录最佳实践和模式，以增强其安全态势。

加入知识星球，共同探索云原生学习之旅！

更多云架构、K8S学习资料以及SRE学习手册，加入星球免费领取哦！

感兴趣的朋友们可以加我微信：sre_k8s，备注：云原生交流