前言

欢今天来讲讲pod中的各种网络的通信

目录：

Cluster IP

Target Ports

NodePort

Ingress

Load Balancer

Cluster IP

创建Kubernetes服务时，群集IP是默认方法。为该服务分配了一个内部IP，其他组件可以使用该IP来访问Pod。

通过使用单个IP地址，它可以使服务在多个Pod之间实现负载平衡。

clusterip.yaml

apiVersion: v1
kind: Service
metadata:
  name: webapp1-clusterip-svc
  labels:
    app: webapp1-clusterip
spec:
  ports:
  - port: 80
  selector:
    app: webapp1-clusterip
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: webapp1-clusterip-deployment
spec:
  replicas: 2
  template:
    metadata:
      labels:
        app: webapp1-clusterip
    spec:
      containers:
      - name: webapp1-clusterip-pod
        image: katacoda/docker-http-server:latest
        ports:
        - containerPort: 80
---

首先简单的介绍一下上面Yaml define的内容：

 （1）创建服务

 创建一个名为 webapp1-clusterip-svc 的服务并将它

 给自己创建一个标签名为 webapp1-clusterip

 开通的端口为 80 端口

 通过 selector 去筛选 Pod 上筛选标签 app:webapp1-clusterip

 （2）创建 Deployment Pod组

 创建一个名为 webapp1-clusterip-deployment 的 Pod组

 并为每一个 Pod 标注标签为 app:webapp1-clusterip-pod 

 后面紧接着是 Pod 名称，镜像与容器中端口的定义

启动 Kubernetes proxy 模式：

$ kubectl proxy --port=8080

这样你可以通过Kubernetes API，使用如下模式来访问这个服务：

http://localhost:8080/api/v1/proxy/namespaces/<NAMESPACE>/services/<SERVICE-NAME>:<PORT-NAME>/

要访问我们上面定义的服务，你可以使用如下地址：

http://localhost:8080/api/v1/proxy/namespaces/default/services/my-internal-service:http/

创建yaml文件中的定义

查看相关定义

kubectl apply -f clusterip.yaml
kubectl get svc --show-labels
kubectl describe svc/webapp1-clusterip-svc

如图所示：

验证结果：

Target Ports

目标端口允许我们将应用程序可用的端口与应用程序正在侦听的端口分开。TargetPort是应用程序配置为侦听的端口。端口是从外部访问应用程序的方式。

clusterip-target.yaml

apiVersion: v1
kind: Service
metadata:
  name: webapp1-clusterip-targetport-svc
  labels:    app: webapp1-clusterip-targetport
spec:  ports:
  - port: 8080
    targetPort: 80
  selector:
    app: webapp1-clusterip-targetport
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:  name: webapp1-clusterip-targetport-deployment
spec:
  replicas: 2
  template:
    metadata:
      labels:
        app: webapp1-clusterip-targetport
    spec:
      containers:
      - name: webapp1-clusterip-targetport-pod
        image: katacoda/docker-http-server:latest
        ports:
        - containerPort: 80
---

上脚本

kubectl apply -f clusterip-target.yaml
kubectl get svc
kubectl describe svc/webapp1-clusterip-targetport-svc

结果：

NodePort

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

NodePort 服务的 YAML 文件类似如下：

apiVersion: v1
kind: Service
metadata:  
name: my-nodeport-service
selector:    
app: my-app
spec:
type: NodePort
ports:  
- name: http
port: 80
targetPort: 80
nodePort: 30036
protocol: TCP

NodePort 服务主要有两点区别于普通的“ClusterIP”服务。第一，它的类型是“NodePort”。有一个额外的端口，称为 nodePort，它指定节点上开放的端口值 。如果你不指定这个端口，系统将选择一个随机端口。大多数时候我们应该让 Kubernetes 来选择端口，因为如评论中 thockin 所说，用户自己来选择可用端口代价太大。

何时使用这种方式？

这种方法有许多缺点：

1. 每个端口只能是一种服务

2. 端口范围只能是 30000-32767

3. 如果节点/VM 的 IP 地址发生变化，你需要能处理这种情况。

基于以上原因，我不建议在生产环境上用这种方式暴露服务。如果你运行的服务不要求一直可用，或者对成本比较敏感，你可以使用这种方法。这样的应用的最佳例子是 demo 应用，或者某些临时应用。

Ingress

有别于以上所有例子，Ingress 事实上不是一种服务类型。相反，它处于多个服务的前端，扮演着“智能路由”或者集群入口的角色。

你可以用 Ingress 来做许多不同的事情，各种不同类型的 Ingress 控制器也有不同的能力。

GKE 上的默认 ingress 控制器是启动一个 HTTP(S) Load Balancer。它允许你基于路径或者子域名来路由流量到后端服务。例如，你可以将任何发往域名 foo.yourdomain.com 的流量转到 foo 服务，将路径 yourdomain.com/bar/path 的流量转到 bar 服务。

GKE 上用 L7 HTTP Load Balancer 生成的 Ingress 对象的 YAML 文件类似如下：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: my-ingress
spec:
backend:
serviceName: other
servicePort: 8080
rules:
- host: foo.mydomain.com
http:
  paths:
  - backend:
      serviceName: foo
      servicePort: 8080
- host: mydomain.com
http:
  paths:
  - path: /bar/*
    backend:
      serviceName: bar
      servicePort: 8080

何时使用这种方式？

Ingress 可能是暴露服务的最强大方式，但同时也是最复杂的。Ingress 控制器有各种类型，包括 Google Cloud Load Balancer， Nginx，Contour，Istio，等等。它还有各种插件，比如 cert-manager，它可以为你的服务自动提供 SSL 证书。

如果你想要使用同一个 IP 暴露多个服务，这些服务都是使用相同的七层协议（典型如 HTTP），那么Ingress 就是最有用的。如果你使用本地的 GCP 集成，你只需要为一个负载均衡器付费，且由于 Ingress是“智能”的，你还可以获取各种开箱即用的特性（比如 SSL，认证，路由，等等）。

Load Balaner

LoadBalancer 服务是暴露服务到 internet 的标准方式。在 GKE 上，这种方式会启动一个 Network Load Balancer，它将给你一个单独的 IP 地址，转发所有流量到你的服务。

何时使用这种方式？

如果你想要直接暴露服务，这就是默认方式。所有通往你指定的端口的流量都会被转发到对应的服务。它没有过滤条件，没有路由等。这意味着你几乎可以发送任何种类的流量到该服务，像 HTTP，TCP，UDP，Websocket，gRPC 或其它任意种类。

这个方式的最大缺点是每一个用 LoadBalancer 暴露的服务都会有它自己的 IP 地址，每个用到的 LoadBalancer 都需要付费，这将是非常昂贵的。

【转载】：http://dockone.io/article/4884