引言

本文将会描述一个典型的系统架构，然后分析其在理论上是否能够支撑百万并发的请求。

典型系统架构及分析

为了降低复杂性，笔者将系统简化为了下图所示：

序言

Redis 除了我们所熟知的缓存功能之外，还通过 RedisJSON、RediSearch、RedisTimeSeries、RedisBloom 等模块支持了 JSON 数据、查询与搜索（包括全文检索、向量搜索、GEO 地理位置等）、时序数据、概率计算等等扩展功能。这些模块既可以按需导入，也被全部打包到了 Redis Stack 中方便我们直接使用。

序言

Redis 除了我们所熟知的缓存功能之外，还通过 RedisJSON、RediSearch、RedisTimeSeries、RedisBloom 等模块支持了 JSON 数据、查询与搜索（包括全文搜索、向量搜索、GEO 地理位置等）、时序数据、概率计算等等扩展功能。这些模块既可以按需导入，也被全部打包到了 Redis Stack 中方便我们直接使用。

序言

以图搜图系统指的是从图像内容提取特征向量，然后使用向量数据库进行向量数据的插入、删除、相似性检索等操作，进而提供根据图像内容搜索出具有相似内容的其它图像的功能。

kube-scheduler

kube-scheduler 是 k8s 集群中控制平面的一个重要组件，其负责的工作简单且专一：给未分配的 pod 分配一个 node 节点。

调度器的大致工作过程可以分为以下几步：

• 监听到未绑定 node 的 pod。
• 过滤节点：挑选出来适合分配这个 pod 的 node 节点（可能有多个）。
• 节点打分：给过滤出来的节点进行打分。
• 最后选择得分最高的那个 node 与 pod 绑定（如果最高得分有多个 node 则随机选择一个）。

更加详细的步骤则参考下图所示：

本文将会介绍：

• 从 pod 到 service 再到 pod，kubernetes 中的流量是怎么走的？
• 对于 long-lived connection 长连接又是怎样的情况？

从 pod 到 service 再到 pod

如上图所示：

背景说明

大家好，我是凌虚。

我于 2024 年 3 月 14 日参加了 Elastic Certified Engineer（ECE）认证考试，并与 18 日收到了考试通过的邮件。本文将会回顾我的考试过程、考试真题、个人感受。

背景说明

如上图所示，本人于 2024 年 1 月 22 号晚上 11 点进行了 CKA 的认证考试，并以 95 分（满分100）顺利通过拿证。本文将会介绍我的 CKA 考试心得和速通攻略。

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 的全过程。