从Spark 2.4 版本开始，Spark 实验性支持 Kubernetes 作为资源管理器。不过虽然是实验性质，但是已经有很多单位将之用于生产环境了，并取得很好的效果，在可移植性，可扩展性，成本等方面都取得了收益。

为了更好地管理不断增长的服务和流量，Houzz基础架构工程团队最近将Web Server服务从Amazon Elastic Compute Cloud（Amazon EC2）迁移到Kubernetes集群。这次迁移使资源减少了33%，首页延迟有了30%的改善。

尽管在诞生之初，WebAssembly（简称Wasm）目的是为浏览器带来高级编程的功能 -- 它提供了一条途径，以使得以各种语言编写的代码都可以以接近原生的速度在Web中运行。在这种情况下，以前无法以此方式运行的客户端软件都将可以运行在Web中。

在 Istio 1.8中多集群支持的演变 一文中，我们介绍了4种Istio多集群部署模型，并且简单介绍了单网络 Primary-Remote部署模型的部署步骤。今天我们通过对源码分析，来介绍Istio如何支持多集群模式。

可观察性是Istio4大特性之一。在 Istio可观察性--Metrcis篇 文中我们讲到，Istio会为Istio服务网格内，外所有服务流量生成指标。这些度量标准提供有关行为的信息，例如总流量，流量中的错误率以及请求的响应时间。

Istio是一种具备流量管理，安全性，可观察性，可扩展的服务网格解决方案。那么Istio的授权模型是什么？其如何实现对网格中的工作负载进行访问控制的？

传统上，Kubernetes使用Ingress控制器来处理从外部进入集群的流量。使用Istio时，情况不再如此。 Istio已用新的Gateway和VirtualServices资源替换了熟悉的Ingress资源。它们协同工作，将流量路由到网格中。在网格内部，不需要Gateway，因为服务可以通过集群本地服务名称相互访问。

数据平面由部署为Sidecar的一组智能代理(Envoy+Polit-agent)组成。这些代理承载并控制微服务之间的所有网络通信。他们还收集并报告所有服务网格流量的遥测。

在此配置中，每个集群都具有自己的Istio控制平面部署，而不是使用共享的Istio控制平面来管理网格，每个集群管理自己的端点。为了执行策略和确保安全，所有集群都处于共享的管理控制之下。

在共享控制平面部署模型下，多个Kubernetes远程集群连接到在主集群中运行的共享Istio控制平面。远程群集可以与主群集位于同一网络中，也可以位于不同网络中。连接一个或多个远程集群后，主集群的控制平面将管理所有服务端点上的服务网格。

容器是一种流行的技术，用于加速当今的应用程序开发。多亏了Docker这样的容器平台，与虚拟机相比，您可以有效地打包应用程序。使用容器，应用程序及其所有依赖项一起打包到一个最小的可部署镜像中。作为开发人员，您可以使用容器在环境之间移动应用程序，并确保您的应用程序按预期运行。这些目标导致了容器编排平台的创...

Akri 使您可以轻松地将异构叶子设备（例如IP摄像机和USB设备）公开为Kubernetes集群中的资源，同时还支持公开嵌入式硬件资源（例如GPU和FPGA）。 Akri不断检测有权访问这些设备的节点，并根据这些节点调度工作负载。

Kubernetes网络模型的核心要求之一是每个Pod应该获得自己的IP地址，并且集群中的每个Pod应该能够使用该IP地址与其进行对话。有几种网络提供商（flannel, calico, canal等）实现此网络模型。

Contour继续添加新功能，以帮助大家更好地管理集群中的ingress操作。我们的最新release版本Contour 1.9.0现在包括：

您是否想知道站点可靠性工程（SRE）团队如何有效地管理复杂的应用程序？在Kubernetes生态系统中，只有一个答案：Kubernetes Operator！在本文中，我们将研究它们是什么以及它们如何工作。

Kubernetes提供了Horizo​​ntal Pod Autoscaler，它可以根据您提供的指标自动缩放资源（Deployment，ReplicationController，ReplicaSet，StatefulSet）中副本的数量。通常，所使用的度量标准是CPU /内存负载，对于大多数应用程序而言已足够。

Etcd是Kubernetes的关键组件，因为它存储了集群的整个状态：其配置，规格以及运行中的工作负载的状态。在本文中，我们将会揭开其神秘的面纱，了解etcd如何存储所有这些信息。

本文是对我之前的基准测试（2018年和2019年）的更新，该基准测试基于Kubernetes 1.19和Ubuntu 18.04，并于2020年8月更新了CNI版本。

Seccomp(全称：secure computing mode)在2.6.12版本(2005年3月8日)中引入linux内核，是一种限制系统调用的安全机制。在严格模式下，将进程可用的系统调用限制为四种：read，write，exit，sigreturn，其他的系统调用都会杀死进程。过滤模式下，可以指定允许那些系统调用，Seccomp进行过滤的方式是基于使用SECCOMP_MODE_FI...

Linux内核一直是实现监视/可观察性，网络和安全性的理想场所。不幸的是，这通常是不切实际的，因为它需要更改内核源代码或加载内核模块，并导致彼此堆叠的抽象层。 eBPF是一项革命性的技术，可以在Linux内核中运行沙盒程序，而无需更改内核源代码或加载内核模块。通过使Linux内核可编程，基础架构软件可以利用现有的层，...

Open Service Mesh (OSM) 是微软开源的一个轻量级，可扩展的云原生 service mesh 解决方案。其遵循了SMI 规范。并且微软承诺，会尽快交给CNCF基金会管理，这就意味着这是一个社区主导的项目，而不是微软。

Kubernetes提供了支持复杂容器应用程序所需的一切。对于开发人员和运营人员来说，这是最便捷，最受欢迎的框架，几乎所有组织的DevOps团队都广泛使用它。

上一章讲了flink 的 application mode。今天我们主要通过该模式提交WordCount作业，并且选择的是native kubernetes。

gRPC (gRPC Remote Procedure Calls) 是Google发起的一个开源远程过程调用 (Remote procedure call) 系统。该系统基于 HTTP/2 协议传输，使用Protocol Buffers 作为接口描述语言。

上一章我们讲了，kubelet如何通过计算容器的hash来判断是否需要升级容器。 本文主要讲如何判断Pod就地升级完成。 在ContainerStatus中不仅有hash filed。还记录了ImageID filed。 {代码...} 关于ImageID的更加详细的讲述，大家可以参考这个系列文章的第一篇。 我们任意查看一个Pod的具体信息： {代码...} 如上 imageID: ...

当创建一个Pod的时候，kubelet会计算每个容器的hash，并且把该hash值写到ContainerStatus中，该status的定义如下：

Readiness gates，又被称为pod “ready++”，该特性kubernetes1.11被引入，在kubernetes1.14 达到稳定状态。

Docker 镜像是用于创建容器的只读模板，并提供了基于多层文件和路径的有序联合文件系统，该文件系统可以与其他镜像和容器共享。共享镜像层是Docker平台的基本组成部分，并且通过实现写​​时复制（COW）机制来实现。在其生命周期内，如果容器需要从提供其文件系统的只读映像中更改文件，它将在进行更改之前将文件复制到其...

一个Kubernetes的Service是一种抽象，它定义了一组Pods的逻辑集合和一个用于访问它们的策略 - 有的时候被称之为微服务。一个Service的目标Pod集合通常是由[Label Selector](https://link.zhihu.com/?target=http%3A//kubernetes.kansea.com/docs/user-guide/labels/%23label-selectors) 来决定的（下面有讲一个没有选择...

Kubernetes文档指出“管理存储与管理计算实例是一个不同的问题”。这概括了现代数据中心设计的基本原则，即从规划和部署角度出发，最好将计算和存储分开考虑。在Kubernetes中，通过诸如容器存储接口（CSI）之类的子系统，计算和存储的逻辑分离已变得越来越普遍。因此，与Kubernetes一起使用是一种强大的策略。 计算机存储...