从部署 httpd 入手，理清 k8s 配置中的 containerPort、port、nodePort、targetPort

注：文中各种内网、公网 IP 仅为示例，不保证所有 IP 都可以访问，且你的环境中 IP 可能不同。

背景

在上一篇文章 自己搭建一个k8s环境 中，我们一顿操作猛如虎，搭建出了由 1 个 master 和 1 个 worker 节点组成的 k8s 集群，大概是这样的效果：

为了验证我们搭建的环境是否好使，本篇文章就借搭建 httpd 来复习复习 k8s 的部署，顺便理清 k8s 配置中的 containerPort、port、nodePort、targetPort。

如果你没有听说过 httpd，那么只需要知道它是一款功能类似于 nginx、IIS 的 Web 服务器，它的全名是 Apache HTTP Server。当部署好后访问它默认的首页，会收获 It Works 这样一行令人愉快的提示语。

nginx https://nginx.org/en/
IIS https://www.iis.net/
Apache HTTP Server https://httpd.apache.org/

先把最终效果放上，图中展示了下面会用到的各种 k8s 资源以及访问效果，阅读后面的内容时可以对照着图看看：

部署 httpd

为了部署 httpd，我们需要用到以下知识：

• Namespace：通过 Namespace 可以对集群内的资源进行分组，例如我希望所有和部署 httpd 有关的资源都在同一个分组中，那么就可以通过设置 namespace 实现（当然，Namespace 还影响着诸如 DNS 等内容，可以在官方文档中查看）

• Deployment：我们知道，Pod 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元，但通常我们不需要直接创建 Pod，而是通过 Deployment 之类的 工作负载 资源来管理它。所以我们通过 Deployment 来部署 httpd

• Service：当部署妥当后，需要有一种方式来访问部署好的程序，Service 就是将 Pod 里的程序公开为网络服务的抽象方法

Namespace https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/
Deployment https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
Pod https://kubernetes.io/zh/docs/concepts/workloads/pods/
工作负载 https://kubernetes.io/zh/docs/concepts/workloads/
Service https://kubernetes.io/zh/docs/concepts/services-networking/service/

了解了相关知识后，马上开干，我们通过 kubectl 来管理集群，所以需要登录到 master 节点上来使用 kubectl。

kubectl https://kubernetes.io/zh/docs/reference/kubectl/overview/

下面会通过 yaml 文件的方式创建相关资源，

YAML is a human-friendly data serialization language for all programming languages.
YAML 是一种人类友好的数据序列化语言，适用于所有编程语言。

简而言之就是通过一种易于书写和阅读的格式，来描述数据（和大家熟悉的 JSON 以及 XML 做的事情一样）。

创建 Namespace

首先创建一个 httpd-namespace.yaml 文件：

apiVersion: v1
kind: Namespace
metadata:
  name: httpd

• 通过 kind 指定要创建的资源为 Namespace

• 通过 metadata.name 来指定 Namespace 的名称

然后执行

kubectl create -f ./httpd-namespace.yaml

表示通过文件创建资源。

然后查看我们创建的 namespace：

kubectl get namespace httpd

得到结果：

NAME    STATUS   AGE
httpd   Active   11s

一些资源有自己的缩写，例如 namespace 可以缩写为 ns：

kubectl get ns httpd

这样能少打几个字母，提高效率。
通过 kubectl api-resources 可以查看相关列表。

创建 Deployment

接下来创建 httpd-deployment.yaml 文件：

apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: httpd
  name: httpd
spec:
  selector:
    matchLabels:
      app: httpd
  template:
    metadata:
      labels:
        app: httpd
    spec:
      containers:
      - name: httpd
        image: httpd:alpine
        ports:
        - containerPort: 80

• 通过 kind 指定要创建的资源为 Deployment

• metadata

  • 通过 namespace 设置该 Deployment 属于 httpd Namespace 下

  • 通过 name 将该 Deployment 的名称设为 httpd（有的朋友喜欢加上前缀或后缀表示是 Deployment，例如 httpd-deployment。都是可以的，只是我个人更喜欢资源类型加名称已经可以唯一标识一个资源了，就不再添加前后缀了）

• spec

  • selector 表示 Deployment 如何找到要管理的 Pod。这里使用的 matchLabels 表示，匹配带有 app 这个 label，且值为 httpd 的 Pod

  • template 中的

  • metadata.labels 会为 Pod 增加 app: httpd label，这个 label 必须和前面 selector 定义的匹配

  • spec.containers 表示创建一个名为 httpd 的 container，使用 httpd:alpine 镜像，并开放容器的 80 端口

然后创建 Deployment：

kubectl create -f ./httpd-deployment.yaml

查看创建好的 Deployment：

kubectl get deploy -n httpd

• deploy 是 deployments 的缩写

• 因为我们的 Deployment 在 httpd Namespace 下，所以还需要 -n 设置 Namespace

可以看到创建好的 Deployment：

NAME    READY   UP-TO-DATE   AVAILABLE   AGE
httpd   1/1     1            1           17s

由于 Deployment 会为我们管理 Pod，这时 Pod 已经创建好了，查看 Pod：

kubectl get pods -n httpd

可以看到创建好的 Pod：

NAME                     READY   STATUS    RESTARTS   AGE
httpd-76f7455774-mdk4t   1/1     Running   0          33s

由 Deployment 生成的 Pod 的名称为 httpd 和随机字符串组成，所以你看到的 Pod 名称可能和我不同。

观察 Pod 的网络

让我们来看看这个 Pod 的 IP 地址，通过 -o 可以设置输出的格式：

kubectl get pod -n httpd -o wide

得到的返回如下：

NAME                     READY   STATUS    RESTARTS   AGE     IP             NODE            NOMINATED NODE   READINESS GATES
httpd-76f7455774-mdk4t   1/1     Running   0          1m15s   10.10.229.95   bun-worker-01              

可以看到 httpd Pod 运行于 bun-worker-01 节点，并且有一个 IP 地址。由于我们开放的端口为 80 ，试试访问一下：

wget -qO - 10.10.229.95

wow，可以访问，并得到了响应：

It works!

说明 httpd 工作良好。

再来看看这个 IP 地址 10.10.229.95，和之前通过 kubeadm init 设置的 pod-network-cidr=10.10.0.0/16 正好一致，使用的是我们为 Pod 划分的网段。

现在，我们的 Worker 节点里大概是这个模样：

这是不是意味着只要在 master 或 worker 节点上装一个 nginx 来反向代理这个 IP 地址，就能把 Pod 里的内容发布出去了呢？是，也不是

我们的这个 Pod 是通过 Deployment 管理的，可以试试删掉这个 Pod，然后 Deployment 应该自动会重新创建一个新的 Pod：

kubectl delete pod httpd-76f7455774-mdk4t -n httpd
kubectl get pods -n httpd -o wide

果然，又创建出一个新的 Pod：

NAME                     READY   STATUS    RESTARTS   AGE   IP             NODE            NOMINATED NODE   READINESS GATES
httpd-76f7455774-mrx79   1/1     Running   0          6s    10.10.229.96   bun-worker-01              

不过 IP 地址变了
当然，也有奇技淫巧可以固定住 Pod 的 IP，但我们并不需要，因为有专业人士负责把 Pod 内的资源公开出去，那就是 Service。

创建 Service

创建 httpd-service.yaml 文件：

apiVersion: v1
kind: Service
metadata:
  namespace:  httpd
  name: httpd
spec:
  selector:
    app: httpd
  type: NodePort
  ports:
  - protocol: TCP
    port: 8081
    targetPort: 80
    nodePort: 30000

• 通过 kind 指定要创建的资源为 Service

• spec

  • selector 用于查找 Service 要服务的 Pod

  • type 这里指定了 NodePort，表示通过 Node 节点的端口暴露服务

  • ports 下面设置了使用的协议为 TCP 以及一系列的端口，后面会介绍（这里特地为各种端口设置了不同的值，方便下面进行试验）

在生产环境中，一般直接使用的是云厂商提供的负载均衡服务（即 type 设为 LoadBalancer）。但我们的宗旨是低成本(qiong)自建 k8s，所以选用 NodePort 方式非常合适。

创建 Service：

kubectl create -f ./httpd-service.yaml

查看创建好的 Service：

kubectl get svc -n httpd

返回的内容：

NAME    TYPE       CLUSTER-IP    EXTERNAL-IP   PORT(S)          AGE
httpd   NodePort   10.1.96.193           8081:30000/TCP   6s

Cluster IP 和 port

首先来看 CLUSTER-IP，这也是通过 kubeadm init 设置的 service-cidr=10.1.0.0/16 决定的，通过 Cluster IP 可以在集群内部进行通信。

我们进入 httpd 的 Pod 里试验一下：

kubectl exec -it httpd-76f7455774-mrx79 -n httpd /bin/sh

exec 可以对 Pod 内的容器执行命令，例如这里执行的是 /bin/sh 命令，让我们可以直接与容器内部进行交互。注意将 exec 后方的 Pod 名称换成你自己的。

注意：现在，终端的内容来自 httpd Pod 内部。

在 Service 中，我们指定的 port 为 8081，那么通过 ClusterIP:port 就可以访问到通过 Service 公开的内容：

wget -qO - 10.1.96.193:8081

确实可以，相当于我（httpd Pod）绕了一圈访问了我自己：

It works!

k8s 中还有另一种访问 Service 的方式，那就是通过 ..svc.cluster.local 域名，来试一试：

wget -qO - httpd.httpd.svc.cluster.local:8081

鹅妹子嘤，也可以访问！
它背后的原理则是创建 Service 时，k8s 会创建对应的 DNS 记录 ，用 nslookup 命令看看 httpd.httpd.svc.cluster.local 解析后的 IP 是哪里：

nslookup httpd.httpd.svc.cluster.local

结果：

Server:        10.1.0.10
Address:    10.1.0.10:53


Name:    httpd.httpd.svc.cluster.local
Address: 10.1.96.193

域名解析后又指向了 Cluster IP。

DNS 记录 https://kubernetes.io/zh/docs/concepts/services-networking/dns-pod-service/

输入 exit 退出和 Pod 的交互，回到 master。

Node IP 和 nodePort

nodePort 顾名思义就是从节点上开放的端口，它确实在物理上占用了这个节点（主机）的一个端口，可以通过 NodeIP:nodePort 访问。在这里 httpd Pod 运行在 bun-worker-01 节点上，节点的 IP 是 172.17.0.2，那么这样也可以访问到 httpd：

wget -qO - 172.17.0.2:30000

默认情况下，nodePort 可用的范围为 30000-32767，当不设置 nodePort 时会在这个范围内随机分配一个。

Pod IP 和 targetPort

在 Service 的配置中，如果不设置 targetPort，那么它默认会被设为和 port 一样的值。不过我们为 Pod 开放的端口为 80，所以在 Service 中配置的 targetPort 需要和 Deployment 中的 containerPort 对应上。

这样通过 NodeIP:nodePort 以及 ClusterIP:port 来的流量才能通过 PodIP:targetPort 进入到容器中。

通过公网 IP 访问 httpd

最后，我们可以通过公网访问 Pod 里的 httpd！因为 NodePort 类型的 Service 是真的在节点上开放了一个端口，即 nodePort，那么我们只需要用节点的公网 IP + nodePort 就能访问到 httpd 了！

记得先在云主机的防火墙中开放 30000 端口：

接下打开浏览器，见证奇迹。我的 bun-worker-01 节点公网 IP 为 101.35.132.54：

但是不管静态设置或动态分配节点的 Port 总归是有些麻烦，而且目前这样如果想通过域名解析来访问 httpd，意味着域名后还需要接上 30000 端口才行，且不易实现负载均衡访问，不是主流的方案。

下一篇我们将使用 ingress-nginx，直接公开节点的 80 和 443 端口，像是安装了 nginx 一样，通过简单的配置，就能使用域名直接访问 Pod 里的资源。

ingress-nginx https://kubernetes.github.io/ingress-nginx/