GKE是Google Cloud的Kubernetes的服务。其架构如下：

Master Node是Google免费提供的，用户自己创建Node Pool，不同的Node Pool可以采用不同的硬件配置，比如带GPU或不带GPU。
在GKE上，创建不同的对外的服务接口，相应的将自动生成不同的服务：

如果创建一个ingress，系统将自动创建一个http(s)的负载均衡或L7的internal LB；
如果创建一个LoadBalancer类型的Service，系统将自动创建一个TCP的负载均衡；
如果创建一个LoadBalancer类型的内网地址的service，系统将自动创建一个TCP的Internal loadbalancer；
如果创建一个nodeport类型的Service，不会自动生成loadBalancer

本文将介绍这几种service如何创建，并特别介绍如何同时支持ingress和内网地址的service。

创建GKE cluster

创建cluster

通过界面创建GKE的cluster：

Cluster创建成功：

kubectl与cluster连接

在界面上点击connect

复制gcloud命令
并在cloud shell中运行：

连接成功，可以通过kubectl控制cluster：

二部署workload

通过kubectl命令创建3个pod nginx的deployment：

$ kubectl run nginx --image=nginx
deployment.apps "nginx" created

$ kubectl scale deployment nginx --replicas=3
deployment.extensions "nginx" scaled

在console上可以看到：

通过kubectl查看：

cluster网络

pod IP地址段

查看cluster的详情：

因为Google的GKE采用的是per pod per IP的模式，Pod的IP地址在VPC内：

这段地址是在创建cluster时自动创建的，专门用于pods的IP地址。另外在VPC内还有一段IP地址用于将来Service使用，比如cluster IP。

node IP地址

查看node的IP：

可以看到，除标准段primary Internal IP外，这个node有一个alias IP，是在pods IP内的一个24位掩码的地址段。在这个node上的pod将会使用这段地址。这样，每个node会有一段IP地址。这种设计和K8s网络的flannel类似：

GKE中，这段Alias IP用于Pod间通讯，也可以用于和GCE的通讯。如上图，Node2的IP地址为10.1.1.22，Pod的IP地址段是10.40.2.0/24。此Node上的Pod地址都在这个Alias IP段内。GCE 10.100.1.10与Node2的Pod进行通讯，可以直接和10.40.2.10或10.40.2.11直接通讯。跨Node的Pod间通讯，也直接用Pod IP进行通讯，比如10.40.1.10 <-> 10.40.2.10。

pod的IP

查看pod信息可以看到3个pod，运行在不同的node上，并且IP地址是10.40.0.0/24，10.40.1.0/24， 10.40.2.0/24的地址段。印证了我们前面观察到的node ip地址段。

在同一个网段的VM去ping和curl一个pod，发现可以直接访问：

如前所述，这样的设计解决了在K8s集群中，跨node的pod通讯问题，也解决了非cluster内IP和pod通讯的问题。

创建Load Balancer类型的service

创建Service

在Google Cloud console中，

在workload界面中选择expose

填入相应的参数，点击expose：

由于类型选择的是loadbalancer，GCP会自动创建一个TCP的loadbalancer。

Service详情

首先查看service：

看到service已经创建成功，类型是load balancer的。

负载均衡详情

再查看loadbalancer：

可以看到一个TCP的load balancer已经创建成功。

后端采用的是添加Instance的方式：

前端生成一个公网IP地址：

通过这个IP地址，可以访问到访问：

创建内部IP的service

通过yaml文件创建

在cloud shell中创建一个yaml文件：

apiVersion: v1

kind: Service
metadata:
  annotations:
    cloud.google.com/load-balancer-type: Internal
  labels:
    run: nginx
  name: nginx-internal
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    run: nginx
  type: LoadBalancer

通过kubectl创建这个内部IP的service：

$ kubectl apply -f ./internallb.yaml
service "nginx-internal" created

service详情

在console上可以看到已经创建成功。

详细信息中，可以看到：

内部IP是10.1.1.27，这个地址是这个网段的primary IP地址段，Cluster IP在cluster中定义的一致，后端有3个pod，服务端口是80，node port是30660，pod内的port是80.

ILB详情

查看ilb信息：

在详细信息中，可以看到backend信息：

ILB的后端采用instance group的形式。

ILB的前端：

创建ingress

创建基于node port的service

创建yaml文件：

apiVersion: v1
kind: Service
metadata:
  labels:
    run: nginx
  name: nginx-nodeport
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    run: nginx
  type: NodePort

通过kubectl创建：

$ kubectl apply -f ./nodeport.yaml
service "nginx-nodeport" created

nodeport service详情

详情如下：

创建ingress

创建ingress的yaml文件：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: prod-ingress-2
spec:
  rules:
  - http:
      paths:
      - backend:
          serviceName: nginx-nodeport
          servicePort: 80

创建ingress：

$ kubectl apply -f ./ingress01.yaml
ingress.extensions "prod-ingress-2" created

Ingress详情

可以看到ingress创建成功：

详细内容：

http负载均衡详情

可以看到http负载均衡已经创建成功：

后端情况，有两个backend，但instance group相同：

Load balancer mode采用的是rate模式：

Rule有3条，分布引用这两个backend service：

前端是有公网IP的HTTP配置：

通过这个公网IP，同样可以访问到服务：

注意事项

注意到在ingress的http负载均衡中，load balancer模式采用的是rate模式。
在实际操作中，如果先创建ingress，有可能会采用utilization模式，而ILB的backend只能采用rate模式，此时再创建内部IP的service时，会出错：

查看HTTP负载均衡情况：

这个是utilization模式。造成不能创建ILB。

目前，建议先创建内部IP的service，再创建ingress，这样可以避免这个问题。

总结

通过介绍如何创建GKE上各种Service类型，介绍了Cluster的创建、GKE的网络组成、Ingress、ILB模式的Service，nodeport模式的service的Yaml文件。以及在需要同时支持ingress和ILB模式Service是要注意的问题。

创作场景

GKE 上同一组 pod 同时支持多种 Service 模式