本文介绍了 API 网关、Kubernetes 网关和服务网格的综合指南。API 网关和 Kubernetes 网关解决了边缘问题和 API 抽象化，而服务网格解决了服务之间的通信挑战。文章还介绍了如何在不同的网关中配置金丝雀部署，并讨论了 Kubernetes Gateway API 的发展和服务网格接口（SMI）规范。最后，文章提供了一些关于何时使用哪种网关的建议。
本文介绍了 Kubernetes 网关 API，该 API 旨在提供一种在 Kubernetes 中管理网关和负载均衡器的标准方法。文章解释了 Kubernetes 网关 API 的核心组件和概念，并且详细介绍了如何使用网关 API 来配置和管理网关和负载均衡器。文章还介绍了一些常见的网关实现，例如 Istio 和 Contour，以及如何使用它们与 Kubernetes 网关 API 进行集成。最后，文章还讨论了 Kubernetes 网关 API 的未来发展方向。
在 Kubernetes 上，从部署 Deployment 到正常提供服务，整个流程可能会出现各种各样问题，有兴趣的可以浏览 Kubernetes Deployment 的故障排查可视化指南（2021 中文版）[1]。从可视化指南也可能看出这些问题实际上都是有迹可循，根据错误信息基本很容易找到解决方法。随着 ChatGPT 的流行，基于 LLM 的文本生成项目不断涌现，k8sgpt[2] 便是其中之一。 k8sgpt 是一个扫描 Kubernetes 集群、诊断和分类问题的工具。它将 SRE 经验编入其分析器，并通过 AI 帮助提取并丰富相关的信息。
您是否应该让多个团队使用同一个 Kubernetes 集群? 您是否可以安全地运行来自不信任用户的不信任工作负载? Kubernetes 是否具备多租户功能? 本文将探讨在运行具有多个租户的集群时面临的挑战。 多租户可分为: 1. 软多租户，适用于信任您的租户 - 比如与同一家公司的团队共享集群时。 2. 硬多租户，适用于您不信任的租户。 您还可以混合使用！
随着云原生技术的普及，其暴露出来的攻击面也被黑客们念念不忘，相关的攻击技术也跟着被“普及”，自动化漏洞利用攻击工具更是如雨后春笋般出现在GitHub开源平台，其中比较有代表性的如cdk-team/CDK。其是一款为容器环境定制的渗透测试工具，在已攻陷的容器内部提供零依赖的常用命令及PoC/EXP。集成Docker/K8s场景特有的 逃逸、横向移动、持久化利用方式，插件化管理。 在漏洞利用门槛如此低廉的今天，作为企业安全的建设者（搬砖人），除了考虑部署容器层面运行时检测平台，在k8s api-server层面，启用日志审计功能，也是一个成本低廉又高效发现入侵攻击的途径。 通过对api-server的日志进行审计分析，对于攻击者的信息收集行为，部署k8s cronjob后门、利用rbac做权限提升等持久化攻击行为都能及时的发现并输出告警。
Kubernetes 作为一项核心技术已成为现代应用程序架构的基础，越来越多的企业使用 Kubernetes 作为容器编排系统。 下面的数据来自 2020 CNCF Survey 的原始数据，可以看到使用 Kubernete 的企业占比达到了 80%。
Kubernetes 定义了一种简单、一致的网络模型，基于扁平网络结构的设计，无需将主机端口与网络端口进行映射便可以进行高效地通讯，也无需其他组件进行转发。该模型也使应用程序很容易从虚拟机或者主机物理机迁移到 Kubernetes 管理的 pod 中。 这篇文章主要深入探索Kubernetes网络模型，并了解容器、pod间如何进行通讯。对于网络模型的实现将会在后面的文章介绍。
网络和操作系统内核，对我来说是既陌生又满是吸引，希望能够拨开层层迷雾找到背后的真相。 在 上一篇文章 中我深入探讨了 Kubernetes 网络模型，这次我想更深入一点：了解数据包在 Kubernetes 中的传输，为学习 Kubernetes 的 eBPF 网络加速做准备，加深对网络和操作系统内核的理解。 文中可能有疏漏之处，还望大家赐教。 在开始之前，我可以用一句话来总结我的学习成果：数据包的流转其实就是一个网络套接字描述符（Socket File Descriptor，中文有点冗长，以下简称 socket fd）的寻址过程。 它不是简单的指 socket fd 的内存地址，还包括它的网络地址。
在 上篇文章 用了整篇的内容来描述网络数据包在 Kubernetes 网络中的轨迹，文章末尾，我们提出了一种假设：同一个内核空间中的两个 socket 可以直接传输数据，是不是就可以省掉内核网络协议栈处理带来的延迟？ 不论是同 pod 中的两个不同容器，或者同节点的两个 pod 间的网络通信，实际上都发生在同一个内核空间中，互为对端的两个 socket 也都位于同一个内存中。而在上篇文章的开头也总结了数据包的传输轨迹实际上是 socket 的寻址过程，可以进一步将问题展开：同一节点上的两个 socket 间的通信，如果可以 快速定位到对端的 socket -- 找到其在内存中的地址，我们就可以省掉网络协议栈处理带来的延迟。
近期由于产品需求需要打通多个 K8s 集群的容器网络，要求在一个集群的容器内，通过 Pod IP直接访问另外一个集群的容器，因此笔者对相关网络技术进行了一番学习。本文将解释整体的组网思路，简单分析数据包的流转过程，最后给出详细的实验步骤。
