K8s入门指南：架构解析浓缩版与服务间调用实战演示

前言

小马最近在重拾微服务，上一篇介绍了《领域驱动设计（DDD）初见面（附示例代码）》，本次自然而然到了k8s这一趴。k8s无疑是云原生中的庞然大物，也是云原生的基石。本次小马顺手做了对k8s整个体系理解的浓缩版整理，无论是k8s知识快速入门还是极速复盘，本文都是居家良药。本文旨在一文理解k8s基本概念和原理，并实现了一个k8s部署微服务架构服务间调用demo实践，便于加深理解和指引，希望对大家有所帮助。如果需要完整版的也可以通过这个链接直达k8s官方官网教程。

一、k8s概念理解

Google 在 2000 年代开发了名为 ‌Borg‌ 的大规模容器集群管理系统，用于管理其全球数据中心的容器化应用（如搜索、广告服务）。Borg 积累了十多年的分布式系统运维经验，为 Kubernetes 提供了核心技术基础。

2014 年，Google 将 Borg 的核心设计思想开源，推出 ‌Kubernetes‌（希腊语“舵手”之意），旨在推动容器编排技术的标准化。

名称缩写 ‌K8s‌ 源于用“8”替代“ubernete”这 8 个字符。

1、k8s整体架构

Kubernetes 架构从宏观上来看，包括 Master、Node 以及 Etcd。

（1） Master 主节点

Master 即主节点，负责控制整个 Kubernetes 集群。它包括 Api Server、Scheduler、Controller 等组成部分，这些组件都需要和 Etcd 进行交互以存储数据。

（2） Node 工作节点

Node 即工作节点，为整个集群提供计算力，是容器真正运行的地方，Node包括运行容器container、kubelet、kube-proxy。

Kubernetes 通过将容器放入在节点（Node）上运行的 Pod 中来执行你的工作负载。 节点可以是一个虚拟机或者物理机器，取决于所在的集群配置。 每个节点包含运行 Pod 所需的服务； 这些节点由控制面负责管理。通常集群中会有若干个节点；而在一个学习所用或者资源受限的环境中，你的集群中也可能只有一个节点。节点上的组件包括 kubelet、 容器运行时以及 kube-proxy。

在Kubernetes中，控制面指的是Kubernetes集群的控制和管理部分，负责协调和管理整个集群的运行。它可以理解为集群的“大脑”，负责决定集群中的资源分配、调度、监控等关键任务。
更具体地来说，Kubernetes控制面由以下几个核心组件组成：

1. API服务器(API Server):
   这是控制面的核心，负责暴露Kubernetes API，接收来自用户和控制组件的请求，并对集群资源进行管理。
2. etcd:
   这是Kubernetes集群的存储，用于存储集群的状态和配置信息。
3. 控制器管理器(Controller Manager):
   负责运行集群的控制器，这些控制器会监控集群的状态，并根据需要采取相应的操作，例如部署新的Pod、删除故障的Pod等。
4. 调度器(Scheduler):
   负责将Pod分配到集群中的节点上，保证资源得到有效的利用。

Node 节点是相对于 Master 来说的工作主机，以前叫 Minion，现在叫 Node，它既可以是物理的，也就可以是虚拟的，每个Node 上管理着 Pod 生命周期的 Kubelet 同时也被 Master 管理，在 Node上面运行的服务进程主要有：Kubelet、Kube-proxy 和 docker daemon。

Node 的主要信息有：地址、运行状态、条件、系统容量等。

Node 管理

有个看起来不太令人相信的事情是：Node 并不是由 K8s 创建的，Node 节点其实是由物理机、虚拟机或者是云服务商提供的资源，我们在K8s 创建的其实是 Node 对象，创建完成在之后再进行一系列的检查，比如服务是否正常启动、是否可以创建 Pod等，如果检查不通过则会被标记为不可用；

Node Controller

Node Controller 是管理 Node 对象的，主要负责集群范围内的 Node 信息同步和单个 Node 的生命周期的管理。

在 Kubernetes 集群里使用了 Service（服务），它提供了一个虚拟的 IP 地址（Cluster IP）和端口号，Kubernetes 集群里的任何服务都可以通过 Cluster IP+端口的方式来访问此服务，至于访问请求最后会被转发到哪个 Pod，则由运行在每个 Node 上的 kube-proxy 负责。kube-proxy 进程其实就是一个智能的软件负载均衡器，它负责把对 Service 的请求转发到后端的某个 Pod 实例上，并在内部实现服务的负载均衡与会话保持机制。

在 Kubernetes 中，Pod 的 IP 地址是动态分配的，Pod 可能随时被销毁或重建，因此不能直接依赖 Pod IP 进行通信。为了解决这个问题，Kubernetes 提供了 Service 作为稳定的访问入口。

Service 共有四种类型(即Service的type值有四个)：

ClusterIP（默认） ：仅能在集群内部访问，适用于微服务之间的通信，是默认的type也是最常用的架构形式。例如，后端服务暴露 ClusterIP（集群IP），前端 Pod 通过 DNS 访问它；
NodePort：将 Service 绑定到每个节点的固定端口，使得外部可以通过 : 来访问服务，适合测试环境，但端口范围（30000-32767）受限；
LoadBalancer：集成云厂商的负载均衡器（如 AWS ELB、GCP Load Balancer），适用于生产环境。外部流量可以通过云负载均衡器访问后端 Pod；
ExternalName：将 K8s 内部请求映射到外部 DNS（如 example.com），适用于集成外部 API；

我们来看一个最精简的Service的配置示例：

#serverb 的 Service yaml配置
apiVersion: v1
kind: Service
metadata:
  name: serverb-svc #服务的访问名称
  namespace: my-test-space
spec:
  ports:
    - port: 9602 #服务暴露的端口，服务间其他服务访问serverb的地址http://serverb-svc:9602 
      protocol: TCP
      targetPort: 9502 #容器暴露的端口
  selector:
    app: serverb #对应服务标签
  type: ClusterIP #可不写，默认也是ClusterIP 

详细各种配置可看这里《k8s Ingress、Service配置各样例大全》。

（3） Etcd 键值存储数据库

在K8s中，Etcd是一个高度可靠、分布式的键值存储数据库，用于存储集群的共享配置和服务发现信息。Etcd 在 Kubernetes架构中扮演着核心组件的角色，是集群状态数据的关键存储后端。

Kubernetes 已经成为容器编排领域的王者，它是基于容器的集群编排引擎，具备扩展集群、滚动升级回滚、弹性伸缩、自动治愈、服务发现等多种特性能力。

２、Pod被视为最小的部署单元

Pod在Kubernetes众多的API资源中，是最重要和基础的，被视为最小的部署单元。一个Pod可以包含一个或多个容器,这些容器共享相同的网络命名空间、存储卷和资源限制。

首先，我们需要理解为什么需要Pod。Pod是一种容器设计模式，专为那些具有“超亲密”关系的容器而设计。例如，在servlet容器部署war包、日志收集等场景中，这些容器之间往往需要共享网络、共享存储和共享配置。因此，Pod的概念应运而生。

对于Pod来说，不同的容器之间通过infra container的方式统一识别外部网络空间。这意味着，尽管容器可能运行在不同的宿主机上，但它们通过Pod的网络命名空间相互通信（可以理解为在逻辑上构建了虚拟网络），就像它们在同一台机器上一样。此外，通过挂载同一份volume，容器可以共享存储。例如，这个volume可能对应宿主机上的一个目录，使得容器可以访问相同的文件系统区域。（即各个容器都可以共享宿主机的某个目录）

Kubernetes 不会直接管理容器，而是通过 Pod 来管理。一个Pod包含如下内容：
一个或多个容器，一般是一个，除非多个容器紧密耦合共享资源才放在一个 Pod 中；
共享的存储资源（如数据卷），一个 Pod 中的容器是可以共享存储空间的；
一个共享的 IP 地址，Pod 中容器之间可以通过 localhost:port 彼此访问；
定义容器该如何运行的选项。

Pod 中的容器可包括两种类型：
工作容器：就是我们通常运行服务进程的容器；
初始化容器：完成一些初始化操作的容器，初始化容器在工作容器之前运行，所有的初始化容器成功执行后，才开始启动工作容器；

容器编排是Kubernetes的看家本领。Kubernetes提供了多种编排相关的控制资源，如编排无状态应用的deployment、编排有状态应用的statefulset、编排守护进程的daemonset以及编排离线业务的job/cronjob等。(这里的应用可理解为等同于一些可视化平台上的工作负载)

以应用最广泛的deployment为例，deployment（负责replicaset的版本控制，可支持更新或回滚）、replicaset（负责控制pod的数量，replicaset这个对象的存在是有“个数”版本的）和pod之间的关系是一种层级控制的关系。
简单来说，replicaset负责控制pod的数量，确保有足够的pod实例在运行以满足应用的需求。而deployment则负责控制replicaset的版本属性，使得我们可以轻松地更新或回滚应用版本。这种设计模式为两种最基本的编排动作提供了基础：数量控制的水平扩容（或缩容）以及版本属性控制的更新/回滚。

３、k8s的五种控制器类型

Kubernetes中内建了很多controller（控制器），这些相当于一个状态机，用来控制Pod的具体状态和行为。总体来说k8s有五种控制器，分别对应处理无状态应用、有状态应用、守护型应用和批处理应用。

（1）一个创建 deployment 的流程原理

从创建 deployment （编排无状态应用的资源控制deployment ）开始，整个流程涉及多个组件的协作。以下是各组件在创建 deployment 资源过程中的具体作用：

kubectl 发起创建 deployment 的请求。（kubectl是K8S官方的命令行工具，用于与Kubernetes集群交互，管理集群中的资源如Pod、Service、Deployment等‌。它通过向Kubernetes API发送REST请求实现资源的增删改查操作，是运维和开发人员管理K8S集群的核心工具。）
apiserver 接收到该请求后，将相关资源写入 etcd。 之后，所有组件与 apiserver/etcd 的交互都遵循类似的模式。
deployment controller 通过 list/watch 机制检测到资源变化，并发起创建 replicaSet 的请求。（replicaSet 也叫副本集合，是Replication Controller的下一代副本控制器）
replicaSet controller 同样通过 list/watch 机制检测到资源变化，并发起创建 pod 的请求。
scheduler 检测到未绑定的 pod 资源，通过一系列匹配和过滤规则，选择合适的 node 进行绑定。
kubelet 发现自己 node 上需要创建新 pod，负责 pod 的创建及其后续生命周期管理。
kube-proxy 负责初始化 service 相关的资源，包括服务发现、负载均衡等网络规则。

至此，经过 Kubernetes 各组件的分工协调，完成了从创建一个 deployment 请求开始到具体各 pod 正常运行的全过程。

（2）水平扩缩容和更新／回滚

水平扩缩容：
Deployment 水平扩缩容非常好理解，只需修改 replicaset 控制的 pod 副本数量即可。
例如，从 2 个副本增加到 3 个副本，即完成了水平扩容；反之，则是水平收缩。

更新/回滚：
更新/回滚则体现了 replicaset 这个对象的存在必要性。
当需要应用 3 个实例的版本从 v1 改到 v2 时，v1 版本 replicaset 控制的 pod 副本数会逐渐从 3 变到 0。
同时，v2 版本 replicaset 控制的 pod 数会从 0 变到 3。
当 deployment 下只存在 v2 版本的 replicaset 时，就完成了更新。
回滚的动作与之相反。

在同一个 Kubernetes 集群中，这些微服务副本（Pod）通过一个统一的 Service 对外暴露，IP 和端口是一样的。

拟最佳实践部署方式参考：
每个微服务都用一个kind：Deployment + type: ClusterIP 类型的 Service部署；
统一使用一个 Ingress Controller（如 Nginx Ingress）提供对外访问； 编写一个 Ingress
资源，根据不同的 path 或域名转发到对应服务；

我们来看一个最精简的Deployment的配置示例：

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: serverb
  name: deployment-test-name #Deployment name
  namespace: my-test-space #命名空间（隔离）
spec:
  replicas: 2
  selector:
    matchLabels:
      app: serverb #label标签
  template:
    metadata:
      labels:
        app: serverb #label标签
    spec:
      containers:
        - image: 'mirrors-registry-hub.com/mytestspace:serverb-v2' #容器将运行的镜像仓库中的镜像serverb-v2
          name: serverb #容器name
          ports:
            - containerPort: 9502 #容器的端口（相当于docker run时指定的端口）
          resources:
            limits:
              cpu: 250m
              memory: 128Mi
            requests:
              cpu: 250m
              memory: 128Mi

一个Deployment部署不直接等于一个微服务部署，但通常被用作为一个微服务对应一个Deployment。通常情况下一个微服务的某个服务会对应一个Deployment。下面是一个更复杂的yaml案例。

如上，气氛都烘托到这了，我们下一步来讲网络调用。

4、k8s中的服务发现和网络调用

这一块内容似乎和上文提到的service四种type类型息息相关。

（1）服务间调用

首先是东西向的流量调用，即服务间调用。这部分主要包括两种调用方式：

clusterIp 模式：clusterIp 是 service 的一种类型，在这种类型模式下，kube-proxy 通过 iptables/ipvs 为 service 实现了一种 VIP（虚拟 ip）的形式。只需要访问该 VIP，即可负载均衡地访问到 service 背后的 pod。此外，clusterIp 的实现方式还包括 userSpace 代理模式（基本不用）以及 ipvs 模式（性能更好）。
如创建一个type:clusterIp 的service 则将会得到一个clusterIp。

dns 模式：对 clusterIp 模式的 service 来说，它有一个 A 记录是 service-name.namespace-name.svc.cluster.local，指向 clusterIp 地址。所以一般使用过程中，直接调用 service-name 即可。参考上文对service的 yaml 配置文件来理解。

（2）服务外访问

南北向的流量，即外部请求访问 kubernetes 集群（service 服务），主要包括三种方式：

nodePort：同样是 service 的一种类型，通过 iptables 赋予了调用者主机上的特定 port 就能访问到其后 service 的能力。
loadbalancer：是另一种 service 类型，通过公有云提供的负载均衡器实现。
ingress（进入）：通过 ingress 控制器实现外部访问。

我们来看一个最精简的ingress的配置示例：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: / #路由转发
  name: ingress-test-name
  namespace: my-test-space
spec:
  rules: #路由规则
    - http:
        paths:
          - backend:
              service:
                name: serverb-svc
                port:
                  number: 9602
            path: /myservers #外部域名/myservers/路径下的请求访问转发到服务b即serverb-svc:9602/
            pathType: Prefix

详细各种配置可看这里《k8s Ingress、Service配置各样例大全》。

Kubernetes集群里有三种IP地址，分别如下：
Node IP：Node 节点的IP地址，即物理网卡的IP地址。但不绝对node就是物理的。
Pod IP：Pod 的IP地址，即 docker 容器的IP地址，此为虚拟IP地址。
Cluster IP：Service 的IP地址，此为虚拟IP地址。

如上，一个Deployment应用serverb下的两个pod，可以看到会出现有多种ip。(因为集群里有两个node所以pod被自动合理分配到两个node上)

ip互通性经验总结:
（1）同一Deployment应用之内（同一服务之间不同pod），pod ip可以互通，host ip不行；
（2）不同Deployment应用之间（不同服务之间不同pod），pod ip也可以互通；

也就是呼应了上文说到的服务之间的调用其实可以直接通过pod ip 即可。但是【Pod 的 IP 地址是动态分配的，Pod 可能随时被销毁或重建，因此不能直接依赖 Pod IP 进行通信。为了解决这个问题，Kubernetes 提供了 Service 作为稳定的访问入口。】
Service 有分配ClusterIP。

外部访问 Kubernetes 集群里的某个节点或者服务时，必须要通过 Node IP 进行通信。 Pod IP 是 Docker Engine 根据 flannel.1 网桥的 IP 地址段进行分配的一个虚拟二层网络IP地址，Pod 与 Pod 之间的访问就是通过这个虚拟二层网络进行通信的，而真实的TCP/IP 流量则是通过 Node IP 所在的物理网卡流出的。

5、注解、ConfigMap与Secret

（1）注解与标签的区别

‌标签（Labels）‌：用于标识和选择对象，通常用于组织和选择一组对象，例如标识应用程序的不同版本、环境类型或角色。标签可以通过Label Selector来过滤或选择具有特定标签的对象，这对于部署和服务发现非常有用‌。

‌注解（Annotations）‌：不用于标识和选择对象，主要用于存储不会影响系统行为的信息，如构建信息、发布日期、团队联系人等。注解不能作为选择器使用，因此对于键值的内容没有太多的限制，可以存放较长的文本或结构化的数据‌。

（2）ConfigMap与Secret

ConfigMap 是 Kubernetes 中用于管理‌非敏感配置数据‌的核心资源对象，实现配置与应用容器的解耦，支持动态更新与集中管理。

二、k8s可视化平台部署微服务架构服务间调用demo实践

本次案例将实现基于k8s可视化平台部署的微服务架构服务间调用demo的过程，旨在说明k8s中微服务架构中内部服务之间的通信调用方式，非完整微服务架构部署案例（计划将在后续文章逐步介绍）。相对比较适合新手参考理解。

我们将编写两个服务，servera和serverb，并由serverb在服务内通过servera的 service name来调用servera服务的api。
在进行本地案例之前，需要先在本地安装好docker，最好也一起安装好swoole运行环境（可用于本地验证服务run success）。

1、服务代码打包成镜像文件上传到镜像仓库

我们为了便捷，server代码仅写了一份，同时兼容servera和serverb，注意甄别即可。

server代码start.php和Dockerfile文件参考如下：

//servera的代码同时也是serverb的代码
$server->on('request', function (Swoole\Http\Request $request, Swoole\Http\Response $response) {
    $ip = 'servera-svc'; // 由server B调用server A的api
    $port = 9601; // 服务端口
    $response->header('Content-Type', 'text/plain');

    $path = $request->server['request_uri']; 
    switch ($path) {
        case '/clientapi':
            $client = new Swoole\Coroutine\Http\Client($ip, $port); //创建HTTP客户端
            $client->set(['timeout' => 5]); 
            $client->get('/serverapi'); //发起GET请求
            if ($client->statusCode === 200) {
                $response->end("callapi succ, strlen: ".strlen($client->body));
            } else {
                $response->end("callapi fail, code: ".$client->statusCode); 
            }
            $client->close(); 
            break;
        case '/serverapi':
            $response->end(json_encode(['iRet'=>0,'sMsg'=>'ok','data'=>'this is serverapi'])); 
            break;
        case '/':
            $response->end("Hello, Swoole!"); 
            break;
    }
});

# Dockerfile文件
# To install the MySQL extensions.
# NOTE: The pdo_mysql extension is included in 4.8.12+ and 5.0.1+ images.
FROM phpswoole/swoole:php8.3-alpine

#RUN docker-php-ext-install mysqli pdo_mysql
# 设置工作目录
WORKDIR /var/www

# 复制项目文件到容器中
COPY . .
# 暴露端口
EXPOSE 9502

# 设置容器启动时运行的命令
CMD ["php", "/var/www/start.php"]

我们在代码目录下运行命令docker build -t my-php-serverab .，构建打包成镜像文件，my-php-serverab为本地镜像的名字。我们在本地可以查看到当前的镜像ID。类似于这个值：

我们平常在本地运行的起容器类似命令docker run -d -p 9502:9502 --name my-swoole-server-name my-php-serverab将交由Deployment来处理。

现在，我们根据docker仓库操作相关命令，仓库一般也有直接的命令提示，copy即可；通过本地镜像ID将本地镜像推送到远程镜像仓库中（需要先在远程仓库创建一个仓库用来推动镜像）。
因为我们在这里用了同一份server代码和镜像，所以镜像名取名serverab-v2。

假设push成功后镜像地址：mirrors-registry-hub.com/mytestspace:serverab-v2

2、创建Deployment

创建两个Deployment，对应两个服务servera和serverb。
yaml文件的参考代码：

# servera的Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: servera
  name: deployment-test-name #Deployment name
  namespace: my-test-space #命名空间（隔离）
spec:
  replicas: 2
  selector:
    matchLabels:
      app: servera #label标签
  template:
    metadata:
      labels:
        app: servera #label标签
    spec:
      containers:
        - image: 'mirrors-registry-hub.com/mytestspace:serverab-v2' #容器将运行的镜像仓库中的镜像
          name: servera #容器name
          ports:
            - containerPort: 9502 #容器的端口
          resources:
            limits:
              cpu: 250m
              memory: 128Mi
            requests:
              cpu: 250m
              memory: 128Mi

# serverb的Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: serverb
  name: deployment-test-name #Deployment name
  namespace: my-test-space #命名空间（隔离）
spec:
  replicas: 2
  selector:
    matchLabels:
      app: serverb #label标签
  template:
    metadata:
      labels:
        app: serverb #label标签
    spec:
      containers:
        - image: 'mirrors-registry-hub.com/mytestspace:serverab-v2' #容器将运行的镜像仓库中的镜像
          name: serverb #容器name
          ports:
            - containerPort: 9502 #容器的端口
          resources:
            limits:
              cpu: 250m
              memory: 128Mi
            requests:
              cpu: 250m
              memory: 128Mi

3、创建Service抽象层

#servera 的 Service yaml配置
apiVersion: v1
kind: Service
metadata:
  name: servera-svc #服务的访问名称
  namespace: my-test-space
spec:
  ports:
    - port: 9601 #服务暴露的端口，服务间其他服务访问servera的地址http://servera-svc:9601 
      protocol: TCP
      targetPort: 9502 #容器暴露的端口
  selector:
    app: servera #对应服务标签
  type: ClusterIP #可不写，默认也是ClusterIP 

#serverb 的 Service yaml配置
apiVersion: v1
kind: Service
metadata:
  name: serverb-svc #服务的访问名称
  namespace: my-test-space
spec:
  ports:
    - port: 9602 #服务暴露的端口，服务间其他服务访问serverb的地址http://serverb-svc:9602 
      protocol: TCP
      targetPort: 9502 #容器暴露的端口
  selector:
    app: serverb #对应服务标签
  type: ClusterIP #可不写，默认也是ClusterIP 

我们在上文中其实也能找到创建成功的截图。
至此，两个服务已经搭建完毕。

4、服务间调用验证

我们访问serverb的api，通过serverb内部发起的对servera的调用来验证服务间的调用成功。（如果想更清晰点可以优化代码，将serverapi的json返回也在clientapi中返回打印即可）

至此，k8s可视化平台部署微服务架构服务间调用demo实践成功结束。至于整个微服务架构如何实现我们只有下次再见啦，感谢评阅！

参考资料：
kubernetes.io官方 https://kubernetes.io/zh-cn/docs/home/
Kubernetes中文社区 https://www.kubernetes.org.cn/doc-11
docker菜鸟教程 https://www.runoob.com/docker/docker-tutorial.html