Redis Stack

虽然 Redis 作为一个 key-value 数据库早已被广泛应用于各种缓存相关的场景，然而其团队的却并未故步自封，他们希望更进一步为开发者提供一个不只有缓存功能的强大的实时数据平台，用于处理所有实时数据的应用场景。

Kubernetes 集群外部的 HTTP/HTTPS 请求是如何达到 Pod 中的 container 的？

HTTP 请求流转过程概述

如上图所示，全过程大致为：

1. 用户从 web/mobile/pc 等客户端发出 HTTP/HTTPS 请求。
2. 由于应用服务通常是通过域名的形式对外暴露，所以请求将会先进行 DNS 域名解析，得到对应的公网 IP 地址。
3. 公网 IP 地址通常会绑定一个 Load Balancer 负载均衡器，此时请求会进入此负载均衡器。
   • Load Balancer 负载均衡器可以是硬件，也可以是软件，它通常会保持稳定（固定的公网 IP 地址），因为如果切换 IP 地址会因为 DNS 缓存的原因导致服务某段时间内不可达。
   • Load Balancer 负载均衡器是一个重要的中间层，对外承接公网流量，对内进行流量的管理和转发。
4. Load Balancer 再将请求转发到 kubernetes 集群的某个流量入口点，通常是 ingress。
   • ingress 负责集群内部的路由转发，可以看成是集群内部的网关。
   • ingress 只是配置，具体进行流量转发的是 ingress-controller，后者有多种选择，比如 Nginx、HAProxy、Traefik、Kong 等等。
5. ingress 根据用户自定义的路由规则进一步转发到 service。
   • 比如根据请求的 path 路径或 host 做转发。
6. service 根据 selector（匹配 label 标签）将请求转发到 pod。
   • service 有多种类型，集群内部最常用的类型就是 ClusterIP。
   • service 本质上也只是一种配置，这种配置最终会作用到 node 节点上的 kube-proxy 组件，后者会通过设置 iptables/ipvs 来完成实际的请求转发。
   • service 可能会对应多个 pod，但最终请求只会被随机转发到一个 pod 上。
7. pod 最后将请求发送给其中的 container 容器。
   • 同一个 pod 内部可能有多个 container，但是多个容器不能共用同一个端口，因此这里会根据具体的端口号将请求发给对应的 container。

以上就是一种典型的集群外部 HTTP 请求如何达到 Pod 中的 container 的全过程。

分布式选主

在分布式系统中，应用服务常常会通过多个节点（或实例）的方式来保证高可用。然而在某些场景下，有些数据或者任务无法被并行操作，此时就需要由一个特定的节点来执行这些特殊的任务（或者进行协调及决策），这个特定的节点也就是领导者（Leader），而在多个节点中选择领导者的机制也就是分布式选主（Leader Election）。

当用户向 Kubernetes 提交了一个创建 deployment 的请求后，Kubernetes 从接收请求直至创建对应的 pod 运行这整个过程中都发生了什么呢？

kubernetes 架构简述

在搞清楚从 deployment 提交到 pod 运行整个过程之前，我们有先来看看 Kubernetes 的集群架构：

Kubernetes CRD

在 kubernetes 中有一系列内置的资源，诸如：pod、deployment、configmap、service …… 等等，它们由 k8s 的内部组件管理。而除了这些内置资源之外，k8s 还提供了另外一种方式让用户可以随意地自定义资源，这就是 CRD (全称 CustomResourceDefinitions) 。

容器运行时的内部结构和最新趋势（2023）

原文为 Akihiro Suda 在日本京都大学做的在线讲座，完整的 PPT 可 点击此处下载

本文内容分为以下三个部分：

1. 容器简介
2. 容器运行时的内部结构
3. 容器运行时的最新趋势

1. 容器简介

什么是容器？

容器是一组用于隔离文件系统、CPU 资源、内存资源、系统权限等的各种轻量级方法。容器在很多意义上类似于虚拟机，但它们比虚拟机更高效，而安全性则往往低于虚拟机。

引言

如何结合使用 JVM Heap 堆和 Kubernetes 内存的 requests 和 limits 并远离麻烦。

在容器环境中运行 Java 应用程序需要了解两者 —— JVM 内存机制和 Kubernetes 内存管理。这两个环境一起工作会产生一个稳定的应用程序，但是，错误配置最多可能导致基础设施超支，最坏情况下可能会导致应用程序不稳定或崩溃。我们将首先仔细研究 JVM 内存的工作原理，然后我们将转向 Kubernetes，最后，我们将把这两个概念放在一起。

Admission Controller

Kubernetes Admission Controller（准入控制器）是什么？

如下图所示：

当我们向 k8s api-server 提交了请求之后，需要经过认证鉴权、mutation admission、validation 校验等一系列过程，最后才会将资源对象持久化到 etcd 中（其它组件诸如 controller 或 scheduler 等操作的也是持久化之后的对象）。而所谓的 Kubernetes Admission Controller 其实就是在这个过程中所提供的 webhook 机制，让用户能够在资源对象被持久化之前任意地修改资源对象并进行自定义的校验。

引言

你一定知道 JSON 吧，那专门用于修改 JSON 内容的 JSON PATCH 标准你是否知道呢？

RFC 6902 就定义了这么一种 JSON PATCH 标准，本文将对其进行介绍。

JSON PATCH

JSON Patch 本身也是一种 JSON 文档结构，用于表示要应用于 JSON 文档的操作序列；它适用于 HTTP PATCH 方法，其 MIME 媒体类型为 "application/json-patch+json"。

文本翻译自: https://blog.palark.com/why-cilium-for-kubernetes-networking/

原文作者是 Palark 平台工程师 Anton Kuliashov，其说明了选择 Cilium 作为 Kubernetes 网络接口的原因以及喜爱 Cilium 的地方。

多亏了 CNI（容器网络接口），Kubernetes 提供了大量选项来满足您的网络需求。在多年依赖简单的解决方案之后，我们面临着对高级功能日益增长的客户需求。Cilium 将我们 K8s 平台中的网络提升到了一个新的水平。