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 个注意事项 

Kubernetes学习周报 : 一周好文推荐'

从零开始构建容器：分层

https://depot.dev/blog/building-container-layers-from-scratch

本文深入解释了容器映像的结构以及容器运行时如何处理这些映像的分层性质。它还讨论了用于提高容器构建过程的速度和效率的各种优化技术。

关键点

- 容器镜像由一组“层”组成，这些“层”本质上是 tar 存档，可以组合起来形成容器的最终文件系统。

- 容器运行时使用像 OverlayFS 这样的特殊文件系统来有效地将这些层组合成一个文件系统，通过使用 “whiteout” 文件来处理修改和删除的文件。

- 本文讨论了 eStargz image格式，该格式允许在层内延迟加载单个文件，从而加快容器启动时间和更高效的构建。

- 作者的公司 Depot 正在探索对层构建过程的各种优化，例如并行压缩和探索构建层的替代方法。

Golang 在 Kubernetes 中运行的内存限制

https://fenyuk.medium.com/golang-memory-limits-for-running-in-kubernetes-87835cfd2518

本文讨论了优化在 Kubernetes 环境中运行的 Golang Web 服务的内存限制。它强调了设置适当的资源请求和限制以确保操作稳定性的重要性，尤其是在流量较重的情况下。

关键点：   

1. 资源管理：Kubernetes 集群有严格的资源限制，超出内存分配可能会导致 Pod 终止。在性能和内存使用之间找到平衡至关重要。

2. 进行的实验：

   - 实验 #1：允许最大资源使用量，显示尽管有 12Gi 的限制，但只使用了 2.5Gi 的内存。观察到频繁的垃圾收集 （GC）。

   - 实验 #2：调整设置以最大化内存分配，从而提高内存使用率并减少 GC 运行。

   - 实验 #3：在保持性能的同时降低了内存设置，根据之前的发现，目标限制为 5000Mi。

   - 实验 #4：进一步减少内存，直到发生内存不足 （OOM） 异常，这表明 Web 服务的容量受到限制。  

结论：本文强调了仔细调整 Golang 内存设置和 Kubernetes 资源限制的必要性，以实现最佳性能而不浪费资源。结果特定于测试的 Web 服务，结果可能因应用程序而异。

这种方法旨在确保 Kubernetes 中的 Golang 应用程序高效可靠，尤其是在资源受限的环境中。

从 Pod 访问 Default Namespace 中的 kubernetes 服务

https://medium.com/@jinha4ever/accessing-the-kubernetes-service-in-the-default-namespace-from-your-pods-976d60326fbd

本文概述了默认命名空间中的 Kubernetes 服务，以及如何从 Pod 中访问 Kubernetes API 服务器。

关键点

• - 默认命名空间中的 Kubernetes 服务没有与之关联的后端 Pod，其目的是供集群内部使用。

• - Pod 可以利用服务帐户安全地访问 Kubernetes API 服务器，该服务帐户会自动注入集群 CA 证书和服务帐户令牌。

• - 访问 Kubernetes API 服务器时，您可以使用 Kubernetes 服务域名或环境变量 KUBERNETES_SERVICE_HOST 和 KUBERNETES_SERVICE_PORT。

• - 默认情况下，默认服务账户没有特定的权限，因此您需要使用 Role 和 RoleBinding 授予权限。

• - 授予必要的权限后，您可以从 Pod 中成功读取 default 命名空间中的服务

Kubernetes 网络安全：探索 Cilium 和 Istio 实现

https://medium.com/@noah_h/on-kubernetes-network-security-exploring-cilium-and-istio-implementations-ba687b685d26

本文讨论了 Kubernetes 网络安全，重点介绍了 Cilium 和 Istio 的实现。以下是要点：

• 1. 网络基础设施：Kubernetes 本身没有实现加密和流量控制等安全功能;这些由容器网络接口 （CNI） 和服务网格处理。

• 2. 服务网格：构建在 CNI 之上的服务网格，通过自己的控制和数据平面管理流量。它提供相互身份验证、加密、流量控制、授权、指标和可见性等功能。 

• 3. Istio 平台：

•    - Sidecar 实现：Istio 使用 Sidecar 容器来代理每个 Pod 的流量，从而增强可扩展性并最大限度地减少升级期间的停机时间。

•    - 环境模式：一种将 L4 和 L7 处理分开的较新方法，对 L4 使用每节点代理 （ztunnel），对 L7 功能使用专用工作负载。   

   

• 4. Cilium：

•    - Cilium 最初是一个 CNI，现在已经开始使用 eBPF 整合服务网格功能，以获得更好的性能和更低的复杂性。

•    - 它将身份与传统 IP 地址分离，从而提高管理网络策略的安全性和效率。

• 5. 权衡：Istio 和 Cilium 在资源消耗、复杂性和安全影响方面都有优点和缺点。

• 6. 可观测性：Cilium 的 Hubble 组件提供了对流量的可见性，而 Istio 的日志记录则受到更多限制。

本文强调了 Kubernetes 网络和安全不断发展的形势，强调了在 CNI 和服务网格之间仔细实施和兼容性考虑的必要性。

构建 Service Mesh：代理

https://dev.to/ramonberrutti/build-your-service-mesh-part-1-10ed   

 

本文介绍了一个 DIY 服务网格，这是一个了解服务网格内部的简单教程。该项目旨在提供一个简单易懂的服务网格参考实现，可用于了解像 Linkerd 这样的服务网格使用的各种概念和技术。   

关键点

• - 构建一个简单的代理并向其添加服务网格功能。

• - 使用 Netfilter 拦截和修改网络数据包。

• - 创建一个简单的控制平面来管理服务网格。

• - 使用 gRPC 在代理和控制平面之间进行通信。

• - 创建一个准入控制器来验证和改变 Kubernetes 资源。

• - 在服务之间实施证书生成流程和 mTLS。

• - 了解 HTTP/2 的工作原理，以及如何将其与 gRPC 结合使用来平衡服务之间的流量。

• - 添加有用的功能，如熔断、重试、超时和负载均衡。

• - 使用 OpenTelemetry 向服务网格添加指标和跟踪。

• - 实施 Canary 部署。

在 Kubernetes 中对长期连接进行负载均衡和扩展

https://learnk8s.io/kubernetes-long-lived-connections

Kubernetes 服务无法有效地对长期连接进行负载均衡，例如数据库、gRPC、WebSockets 和其他持久协议中使用的连接。为了解决这个问题，本文提出了两种主要方法：

关键点

• - Kubernetes 服务使用 iptables 来分配流量，但这并不是为长期连接的负载均衡而设计的。Kubernetes 无法有效地对长连接（例如 HTTP/2、gRPC、数据库）进行负载均衡，导致 Pod 之间的请求分配不均匀。

• - 使用持久连接时，流量被路由到单个 Pod，导致其他 Pod 未得到充分利用，负载均衡算法可能导致 Pod 利用率不足。

解决方案

•    - Client-Side Load Balancing：应用程序可以从 Services 中检索终端节点列表并自行管理连接。

•    - 使用代理：实施 Envoy 或 HAProxy 等代理可以帮助平衡长期连接的负载。

•    - 服务网格：Istio 或 Linkerd 等工具可以自动发现终端节点并更有效地管理流量。

降低 Kubernetes 集群的云成本

https://medium.com/adidoescode/reducing-cloud-costs-of-kubernetes-clusters-c8c1e3bdb669

本文讨论了 adidas 如何通过使用各种开源工具和技术，将 Kubernetes 集群的运行成本降低多达 50%。它涵盖了在此过程中面临的挑战和经验教训。

关键点

• - 使用集群自动扩展程序 Karpenter，根据应用程序需求预置和删除节点，包括使用 Spot 实例。

• - 使用策略工具 Kyverno 为开发和暂存集群中的所有工作负载自动创建垂直 Pod 自动扩展器 （VPA）。    

• - 使用 kube-downscaler 在非办公时间将应用程序缩减到 1 个副本，以减少计算时间和成本。

• - 使用 KEDA（Kubernetes 事件驱动的自动扩展）根据外部指标扩展应用程序，以克服单独使用资源指标的限制。

• - 实施 Kyverno 策略，以确保正确配置 Pod 中断预算 （PDB） 以允许删除节点。

• - 持续监控和调整措施，以确保最佳的成本节约和性能。

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

更多K8S学习资料以及SRE学习手册，请扫码关注哦！