Kubernetes 采用的是基于扁平地址空间的网络模型，集群中的每个Pod都有自己的IP地址，Pod之间不需要配置 NAT就能直接通信。另外同一个Pod 中的容器共享Pod的IP，能够通过localhost通信。
这种网络模型对应用开发者和管理员相当友好，应用可以非常方便地从传统网络迁移到 Kubernetes 。每个Pod可被看作是一个个独立的系统，而Pod中的容器则可被看作同一系统中的不同进程。

Kubernetes的网络主要存在四种类型的通信：
1）同一 Pod 内容器之间通信
2）各个 Pod 之间彼此通信
3）Pod 与 Service 之间的通信
4）集群外部流量与 Service之间的通信

Container Networking Interface (CNI)

CNI 是由 CoreOS 提出的容器网络规范，使用了插件(Plugin)模型创建容器的网络栈
CNI 的优点是支持多种容器 runtime ，不仅仅是 Docker。 CNI 的插件模型支持不同组织 和公司开发的第三方插件，这对运维人员来说很有吸引力，可以灵活选择适合的网络方案。
目前己有多种支持 Kubernetes 的网络方案，比如 Flannel、 Calico 、 Canal、 Weave Net 等。 因为它们都实现了 CNI 规范，用户无论选择哪种方案，得到的网络模型都一样，即每个 Pod 都有独立的Pod IP，可以直接通信。区别在于不同方案的底层实现不同，有的采用基于 VxLAN 的 Overlay 实现 ， 有的则是 Underlay，性能上有区别 。再有就是是否支持 Network Policy。

网络策略Network Policy

Network Policy 是 Kubernetes 的一种资源。 Network Policy 通过 Label 选择 Pod， 并指定其他 Pod或外界如何与这些 Pod 通信。 默认情况下，所有 Pod 是非隔离的 ，即任何来源的网络流量都能够访问 Pod，没有任何限制。当为 Pod 定义了 Network Policy 时，只有 Policy允许的流量才能访问 Pod 。 不过，不是所有Kubernetes 网络方案都支持 Network Policy。 比如 Flannel 就不支持，
Calico 是支持的。 Canal 这个开源项目很有意思，它用 Flannel 实现 Kubernetes 集群网络，同时又用 Calico 实现 Network Policy。

集群内部->集群外部

IP+Port

Service+Endpoint

ClusterIP

ClusterIP 服务是 Kubernetes 的默认服务。它给你一个集群内的服务，集群内的其它应用都可以访问该服务。集群外部无法访问它。在某些场景下我们可以使用 Kubernetes 的 Proxy 模式来访问服务，比如调试服务时。

集群外部->集群内部

NodePort

NodePort 服务是引导外部流量到你的服务的最原始方式。NodePort，正如这个名字所示，在所有节点（虚拟机）上开放一个特定端口，任何发送到该端口的流量都被转发到对应服务。
NodePort 服务特征如下：

  • 每个端口只能是一种服务
  • 端口范围只能是 30000-32767（可调）
  • 不在 YAML 配置文件中指定则会分配一个默认端口

    建议： 不要在生产环境中使用这种方式暴露服务，大多数时候我们应该让 Kubernetes 来选择端口

Kubernetes——网络 - 图1

Kubernetes——网络 - 图2


Ingress

Ingress 事实上不是一种服务类型。相反，它处于多个服务的前端，扮演着 “智能路由” 或者集群入口的角色。你可以用 Ingress 来做许多不同的事情，各种不同类型的 Ingress 控制器也有不同的能力。它允许你基于路径或者子域名来路由流量到后端服务。
Ingress 可能是暴露服务的最强大方式，但同时也是最复杂的。Ingress 控制器有各种类型，包括 Google Cloud Load Balancer， Nginx，Contour，Istio，等等。它还有各种插件，比如 cert-manager (它可以为你的服务自动提供 SSL 证书)/
如果你想要使用同一个 IP 暴露多个服务，这些服务都是使用相同的七层协议（典型如 HTTP），你还可以获取各种开箱即用的特性（比如 SSL、认证、路由等等）
Kubernetes——网络 - 图3

什么是 Ingress

通常情况下，Service 和 Pod 的 IP 仅可在集群内部访问。集群外部的请求需要通过负载均衡转发到 Service 在 Node 上暴露的 NodePort 上，然后再由 kube-proxy 通过边缘路由器 (edge router) 将其转发给相关的 Pod 或者丢弃。而 Ingress 就是为进入集群的请求提供路由规则的集合
Ingress 可以给 Service 提供集群外部访问的 URL、负载均衡、SSL 终止、HTTP 路由等。为了配置这些 Ingress 规则，集群管理员需要部署一个 Ingress Controller，它监听 Ingress 和 Service 的变化，并根据规则配置负载均衡并提供访问入口。

使用 Nginx Ingress Controller

本次实践的主要目的就是将入口统一，不再通过 LoadBalancer 等方式将端口暴露出来，而是使用 Ingress 提供的反向代理负载均衡功能作为我们的唯一入口。通过以下步骤操作仔细体会。

注意： 下面包含资源配置的步骤都是自行创建 YAML 配置文件通过 kubectl create -f <YAML> 和 kubectl delete -f <YAML> 部署和删除

部署 Tomcat

部署 Tomcat 但仅允许在内网访问，我们要通过 Ingress 提供的反向代理功能路由到 Tomcat 之上

  1. apiVersion: extensions/v1beta1
  2. kind: Deployment
  3. metadata:
  4.   name: tomcat-app
  5. spec:
  6.   replicas: 2
  7.   template:
  8.     metadata:
  9.       labels:
  10.         name: tomcat
  11.     spec:
  12.       containers:
  13.       - name: tomcat
  14.         image: tomcat
  15.         ports:
  16.         - containerPort: 8080
  17. ---
  18. apiVersion: v1
  19. kind: Service
  20. metadata:
  21.   name: tomcat-http
  22. spec:
  23.   ports:
  24.     - port: 8080
  25.       targetPort: 8080
  26.   # ClusterIP, NodePort, LoadBalancer
  27.   type: LoadBalancer
  28.   selector:
  29.     name: tomcat

安装 Nginx Ingress Controller

Ingress Controller 有许多种，我们选择最熟悉的 Nginx 来处理请求，其它可以参考 官方文档

  • 下载 Nginx Ingress Controller 配置文件

    1. wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/mandatory.yaml

    1

  • 修改配置文件，找到配置如下位置 (搜索 serviceAccountName) 在下面增加一句 hostNetwork: true

    1. apiVersion: apps/v1
    2. kind: Deployment
    3. metadata:
    4. name: nginx-ingress-controller
    5. namespace: ingress-nginx
    6. labels:
    7.   app.kubernetes.io/name: ingress-nginx
    8.   app.kubernetes.io/part-of: ingress-nginx
    9. spec:
    10. # 可以部署多个实例
    11. replicas: 1
    12. selector:
    13.   matchLabels:
    14.     app.kubernetes.io/name: ingress-nginx
    15.     app.kubernetes.io/part-of: ingress-nginx
    16. template:
    17.   metadata:
    18.     labels:
    19.       app.kubernetes.io/name: ingress-nginx
    20.       app.kubernetes.io/part-of: ingress-nginx
    21.     annotations:
    22.       prometheus.io/port: "10254"
    23.       prometheus.io/scrape: "true"
    24.   spec:
    25.     serviceAccountName: nginx-ingress-serviceaccount
    26.     # 增加 hostNetwork: true，意思是开启主机网络模式，暴露 Nginx 服务端口 80
    27.     hostNetwork: true
    28.     containers:
    29.       - name: nginx-ingress-controller
    30.         image: quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.24.1
    31.         args:
    32.           - /nginx-ingress-controller
    33.           - --configmap=$(POD_NAMESPACE)/nginx-configuration
    34.           - --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services
    35.           - --udp-services-configmap=$(POD_NAMESPACE)/udp-services
    36.           - --publish-service=$(POD_NAMESPACE)/ingress-nginx
    37. // 以下代码省略...

部署 Ingress

Ingress 翻译过来是入口的意思，说白了就是个 API 网关（想想之前学的 Zuul 和 Spring Cloud Gateway）

  1. apiVersion: networking.k8s.io/v1beta1
  2. kind: Ingress
  3. metadata:
  4.   name: nginx-web
  5.   annotations:
  6.     # 指定 Ingress Controller 的类型
  7.     kubernetes.io/ingress.class: "nginx"
  8.     # 指定我们的 rules 的 path 可以使用正则表达式
  9.     nginx.ingress.kubernetes.io/use-regex: "true"
  10.     # 连接超时时间，默认为 5s
  11.     nginx.ingress.kubernetes.io/proxy-connect-timeout: "600"
  12.     # 后端服务器回转数据超时时间，默认为 60s
  13.     nginx.ingress.kubernetes.io/proxy-send-timeout: "600"
  14.     # 后端服务器响应超时时间，默认为 60s
  15.     nginx.ingress.kubernetes.io/proxy-read-timeout: "600"
  16.     # 客户端上传文件，最大大小，默认为 20m
  17.     nginx.ingress.kubernetes.io/proxy-body-size: "10m"
  18.     # URL 重写
  19.     nginx.ingress.kubernetes.io/rewrite-target: /
  20. spec:
  21.   # 路由规则
  22.   rules:
  23.   # 主机名，只能是域名，修改为你自己的
  24.   - host: k8s.test.com
  25.     http:
  26.       paths:
  27.       - path:
  28.         backend:
  29.           # 后台部署的 Service Name，与上面部署的 Tomcat 对应
  30.           serviceName: tomcat-http
  31.           # 后台部署的 Service Port，与上面部署的 Tomcat 对应
  32.           servicePort: 8080

验证是否成功

查看 Tomcat

  1. kubectl get deployment
  2. # 输出如下
  3. NAME         READY   UP-TO-DATE   AVAILABLE   AGE
  4. tomcat-app   2/2     2            2           88m
  1. kubectl get service
  2. # 输出如下
  3. NAME          TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
  4. kubernetes    ClusterIP   10.96.0.1       <none>        443/TCP    2d5h
  5. tomcat-http   ClusterIP   10.97.222.179   <none>        8080/TCP   89m

查看 Nginx Ingress Controller

  1. kubectl get pods -n ingress-nginx -o wide
  2. # 输出如下，注意下面的 IP 地址，就是我们实际访问地址
  3. NAME                                        READY   STATUS    RESTARTS   AGE   IP                NODE                 NOMINATED NODE   READINESS GATES
  4. nginx-ingress-controller-76f9fddcf8-vzkm5   1/1     Running   0          61m   192.168.141.160   kubernetes-node-01   <none>           <none>

查看 Ingress

  1. kubectl get ingress
  2. # 输出如下
  3. NAME        HOSTS          ADDRESS   PORTS   AGE
  4. nginx-web   k8s.test.com             80      61m

测试访问

成功代理到 Tomcat 即表示成功

  1. # 不设置 Hosts 的方式请求地址，下面的 IP 和 Host 均在上面有配置
  2. curl -v http://192.168.141.160 -H 'host: k8s.test.com'

扩展阅读

解决无法下载 quay.io 地址镜像的问题

在实际操作中我们需要拉取 Nginx Ingress 镜像，默认地址为：quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.24.1，由于国内网络等原因，可能无法正常拉取该镜像，此时我们可以使用 Azure 提供的镜像加速器，将 quay.io 替换为 quay.azk8s.cn，其它类似地址的镜像无法下载均可尝试使用该方式解决，替换后的地址如：quay.azk8s.cn/kubernetes-ingress-controller/nginx-ingress-controller:0.24.1