Kubernetes 是一头巨大的野兽。在它开始有用之前，您需要了解许多概念。在这里，学习几种访问集群外 pod 的方法。

Kubernetes 是一头巨大的野兽。在它开始有用之前，您需要了解许多不同的概念。一切都设置好后，您可能希望将一些 pod 暴露给集群外部。Kubernetes 提供了不同的方法来做到这一点：我将在这篇文章中描述它们。

设置

为了演示，我将使用kind：

kind 是一个使用 Docker 容器“节点”运行本地 Kubernetes 集群的工具。kind 主要是为测试 Kubernetes 本身而设计的，但也可以用于本地开发或 CI。

我将使用一个两节点集群：

YAML

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
  extraPortMappings:
  - containerPort: 30800             # 1
    hostPort: 30800                  # 1
- role: worker                       # 2
- role: worker                       # 2

• #1：端口转发以应对 Mac 上的 Docker VM 层（见下文）
• #2：两个节点

kind create cluster -- config kind.yml

接下来，我们需要一个容器。它不应该只是运行和停止。让我们使用撰写本文时可用的最新 Nginx 映像。

使用 kind，我们必须预加载镜像以便它们可用。

docker pull nginx:1.23
kind load docker-image nginx:1.23

最后，我别名kubetcl为k：

alias k=kubectl

默认情况下无外部访问

默认情况是不提供对集群外部的访问。

k create deployment nginx --image=nginx:1.23 # 1

• #1：创建单个 pod 的部署。

让我们检查一下是否一切正常：

k get pods

纯文本

NAME                     READY   STATUS    RESTARTS   AGE
nginx-6c7985744b-c7cpl   1/1     Running   0          67s

pod 有一个 IP，但我们无法在集群外访问它。

k get pod nginx-6c7985744b-c7cpl --template '{{.status.podIP}}'

纯文本

10.244.1.2

让我们通过在 pod 内部运行 shell 来确认 IP：

k exec -it nginx-6c7985744b-c7cpl -- /bin/bash
hostname -I

纯文本

10.244.1.2

我们无法在集群外成功 ping 此 IP：它是一个内部 IP。

内部 IP 不稳定

我们创建了一个部署；因此，如果我们删除单个 Pod，Kubernetes 将检测到它并创建一个新 Pod，这要归功于它的自我修复功能。

k delete pod nginx-6c7985744b-c7cpl
k get pods

纯文本

NAME                     READY   STATUS    RESTARTS   AGE
nginx-6c7985744b-c6f92   1/1     Running   0          71s

让我们检查一下它的新IP：

k exec -it nginx-6c7985744b-c6f92 -- /bin/bash
hostname -I

纯文本

10.244.2.2

Kubernetes 创建了一个新的 Pod，但它的 IP 与删除的 Pod 不同。我们不能依赖这个 IP 进行 pod 到 pod 的通信。事实上，我们永远不应该直接使用 pod 的 IP。

为了解决这个问题，Kubernetes 提供了Service对象。服务代表 pod 前面的稳定接口。Kubernetes 管理服务与其 Pod 之间的映射。它绑定新的 Pod 并取消绑定已删除的 Pod。

ClusterIPService：在集群内部 IP 上公开。选择此值使Service唯一可从集群内访问。这是默认设置ServiceType。

-出版服务 (ClusterIP)

让我们使用服务公开现有部署：

k expose deployment nginx --type=ClusterIP --port=8080
k get svc

纯文本

NAME         TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)    AGE
kubernetes   ClusterIP   10.96.0.1     <none>        443/TCP    9m47s
nginx        ClusterIP   10.96.93.97   <none>        8080/TCP   4s

从此时起，可以通过服务的ClusterIP.

全部设置为在集群内部进行访问。从外面看，这还不可能。那么我们为什么要使用ClusteIP呢？它对于您不想暴露给外界的服务非常有用：数据库、ElasticSearch 节点、Redis 节点等。

访问 Pod

当事情变得有趣时，从集群外部访问一个 pod。

我们首先需要删除现有的部署和服务。

k delete deployment nginx
k delete svc nginx

允许外部访问的最简单方法是将服务的类型更改为NodePort.
NodePort将访问端口添加到ClusterIP.

NodePort: 在每个节点的 IP 上的静态端口 (the NodePort) 上公开服务。ClusterIPService 路由到的ServiceNodePort是自动创建的。您可以NodePort通过请求从集群外部联系服务:。

- 发布服务（NodePort）

我希望 pod 返回其 IP 和主机名以进行演示。我们必须从命令行转移到专用的 Kubernetes 清单文件，因为我们必须配置 Nginx。它导致与命令行相同的状态，并添加了 Nginx 配置：

YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.23
        volumeMounts:                                                     # 1
          - name: conf
            mountPath: /etc/nginx/nginx.conf
            subPath: nginx.conf
            readOnly: true
      volumes:                                                            # 1
        - name: conf
          configMap:
            name: nginx-conf
            items:
              - key: nginx.conf
                path: nginx.conf
---
apiVersion: v1                                                            # 1
kind: ConfigMap
metadata:
  name: nginx-conf
data:
  nginx.conf: |
    events {
        worker_connections  1024;
    }
    http {
        server {
            location / {
                default_type text/plain;
                return 200 "host: $hostname\nIP:   $server_addr\n";
            }
        }
    }
---
apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  selector:
    app: nginx
  type: NodePort                                                          # 2
  ports:
    - port: 80
      nodePort: 30800

• #1：覆盖默认配置以返回主机名和 IP 地址。
• #2：NodePort将 pod 的端口映射到外部可访问的端口。

让我们应用配置：

k apply -f deployment.yml

请注意，我在 Mac 上运行；因此，Docker 周围有一个 VM 容器，就像在 Windows 中一样。出于这个原因，kind 需要将 VM 端口转发到主机。请查看有关如何实现它的文档。

一旦 Kubernetes 调度了 pod，我们就可以在配置的端口上访问它：

curl localhost:30800

纯文本

host: nginx-b69d8877c-p2s79
IP:   10.244.2.2

请求的路径如下（尽管 Mac/Windows 上有 VM 层）：

• curl请求发送到任何节点。
• 请注意，在云提供商设置中，您可以针对托管部署的 pod 部分的任何 Kubernetes 节点。通过本地设置，我们定位localhost并让 VM 层以节点为目标。
• 节点看到端口30800并将请求转发到NodePort具有相关端口的服务。
• 该服务将请求转发到 pod，将端口从 转换30800为80。

现在，让我们将部署中的 pod 数量增加到两个：

k scale deployment nginx --replicas=2
k get pods -o wide

Kubernetes 平衡集群，以便每个 pod 驻留在不同的节点上：

纯文本

NAME                    READY   STATUS    RESTARTS   AGE    IP           NODE           NOMINATED NODE   READINESS GATES
nginx-b69d8877c-w7db4   1/1     Running   0          129m   10.244.2.2   kind-worker    <none>           <none>
nginx-b69d8877c-z5kqs   1/1     Running   0          38m    10.244.1.2   kind-worker2   <none>           <none>

请求将发送到哪个节点/pod？

while true; do curl localhost:30800; done

纯文本

host: nginx-b69d8877c-w7db4
IP:   10.244.2.2
host: nginx-b69d8877c-w7db4
IP:   10.244.2.2
host: nginx-b69d8877c-z5kqs
IP:   10.244.1.2
host: nginx-b69d8877c-z5kqs
IP:   10.244.1.2
host: nginx-b69d8877c-w7db4
IP:   10.244.2.2
host: nginx-b69d8877c-w7db4
IP:   10.244.2.2

该服务平衡所有可用 pod 之间的请求。

负载平衡抽象

NodePort允许查询任何集群节点。LoadBalancer是集群上的一个外观，它确实......负载平衡。它是 Kubernetes 提供的一个抽象对象：每个云提供商根据其特性以不同的方式实现它，尽管行为是相同的。

LoadBalancer：使用云提供商的负载均衡器在外部公开服务。自动创建外部负载均衡器路由到的 NodePort 和 ClusterIP 服务。

- 发布服务（LoadBalander）

首先，我们需要一个LoadBalancer实现。kind 与 MetalLB 具有开箱即用的集成：

MetalLB 是裸机 Kubernetes 集群的负载均衡器实现，使用标准路由协议。

-金属LB

解释 kind 关于如何安装 MetalLB的优秀文档是没有用的。我们可以相应地更新清单：

YAML

apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  selector:
    app: nginx
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: 30800

让我们看看服务：

k get svc

纯文本

NAME         TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
kubernetes   ClusterIP      10.96.0.1       <none>        443/TCP          4h37m
nginx        LoadBalancer   10.96.216.126   127.0.0.240   8080:31513/TCP   82m     # 1

• #1：它有一个外部IP！

不幸的是，正如我上面提到的，在 Mac（和 Windows）上，Docker 在 VM 中运行。因此，我们无法从主机访问“外部”IP。拥有适当 Linux 系统的读者应该可以访问它。

根据云提供商的不同，LoadBalancer可能会提供额外的专有功能。

入口，当您需要路由时

Ingress专注于将请求路由到集群中的服务。

它与以下内容共享一些方面LoadBalancer：

• 它拦截入站流量。
• 它依赖于实现，并且实现提供不同的功能：例如. , Nginx , Traefik , HAProxy等

但是，它不是一个Service.

Ingress 将来自集群外部的 HTTP 和 HTTPS 路由暴露给集群内的服务。流量路由由 Ingress 资源上定义的规则控制。

-什么是入口？

安装一个Ingress很大程度上取决于实现。唯一的共同因素是它涉及CRD。

为了演示，我将使用Apache APISIX Ingress 控制器。我不会解释Minikube 上 Ingress APISIX 的安装说明。唯一的区别是将 设置NodePort为设定值：

helm install apisix apisix/apisix \
  --set gateway.type=NodePort \
  --set gateway.http.nodePort=30800 \
  --set ingress-controller.enabled=true \
  --namespace ingress-apisix \
  --set ingress-controller.config.apisix.serviceNamespace=ingress-apisix

请注意，虽然文档中提到了 Minikube，但它适用于任何本地集群，包括 kind。

命名空间中应提供以下服务ingress-apisix：

纯文本

NAME                        TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)             AGE
apisix-admin                ClusterIP   10.96.98.159   <none>        9180/TCP            22h
apisix-etcd                 ClusterIP   10.96.80.154   <none>        2379/TCP,2380/TCP   22h
apisix-etcd-headless        ClusterIP   None           <none>        2379/TCP,2380/TCP   22h
apisix-gateway              NodePort    10.96.233.74   <none>        80:30800/TCP        22h
apisix-ingress-controller   ClusterIP   10.96.125.41   <none>        80/TCP              22h

为了演示，我们将有两个服务：每个服务都有一个 pod 的底层部署。请求/left将命中一项服务并返回left；/right, right.

让我们相应地更新拓扑：

YAML

apiVersin: apps/v1
kind: Deployment
metadata:
  name: left
  labels:
    app: left
spec:
  replicas: 1
  selector:
    matchLabels:
      app: left
  template:
    metadata:
      labels:
        app: left
    spec:
      containers:
      - name: nginx
        image: nginx:1.23
        volumeMounts:
          - name: conf
            mountPath: /etc/nginx/nginx.conf
            subPath: nginx.conf
            readOnly: true
      volumes:
        - name: conf
          configMap:
            name: left-conf
            items:
              - key: nginx.conf
                path: nginx.conf
---
apiVersion: v1
kind: Service
metadata:
  name: left
spec:
  selector:
    app: left
  ports:
    - port: 80
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: left-conf
data:
  nginx.conf: |
    events {
        worker_connections  1024;
    }
    http {
        server {
            location / {
                default_type text/plain;
                return 200 "left\n";
            }
        }
    }

上面的片段只描述了left路径。它应该包含类似的right路径配置。

此时，我们可以创建配置以将路径路由到服务：

YAML

apiVersion: apisix.apache.org/v2beta3            # 1
kind: ApisixRoute                                # 1
metadata:
  name: apisix-route
spec:
  http:
  - name: left
    match:
      paths:
      - "/left"
    backends:
    - serviceName: left                          # 2
      servicePort: 80                            # 2
  - name: right
    match:
      paths:
        - "/right"
    backends:
    - serviceName: right                         # 3
      servicePort: 80                      

1. 使用ApisixRoute安装创建的 CRD。
2. 将请求转发到left服务。
3. 将请求转发到right服务。

这是它应该是什么样子。请注意，我选择仅表示left路径和一个节点，以免图表过载。

为了检查它是否有效，让我们再次卷曲。

curl localhost:30800

纯文本

{"error_msg":"404 找不到路由"}

这是一个好兆头：APISIX 正在响应。

我们现在可以尝试 curlright路径以确保它会转发到相关的 pod。

curl localhost:30800/right

纯文本

正确的

/left，它也有效。

结论

在这篇文章中，我描述了几种访问集群外部 pod 的方法：NodePort以及LoadBalancerservices 和Ingress. 对于Ingress，您可能已经注意到该ApisixRoute对象是专有 CRD。为了避免这种情况，Kubernetes 旨在提供一个抽象：CNCF 正在开发一个网关 API项目。

我会在以后的文章中描述它。

这篇文章的完整源代码可以在GitHub上找到。