【三小时学会Kubernetes！（三）】Service实践

服务Service

Kubernetes 服务资源可以作为一组提供相同服务的 Pod 的入口。这个资源肩负发现服务和平衡 Pod 之间负荷的重任，如图 16 所示。

图16：Kubernetes 服务维护 ID 地址

在 Kubernetes 集群内，我们拥有提供不同服务的 Pod（前端、Spring 网络应用和 Flask Python 应用程序）。所以这里的问题是：服务如何知道该处理哪个 Pod？例如：它如何生成这些 Pod 的终端列表？

这个问题可以用标签来解决，具体分两个步骤：

给所有服务处理的对象 Pod 贴上标签；
在服务中使用一个选择器，该选择器定义了所有贴有标签的对象 Pod。
下列视图看起来更清晰：

图17：带有标签的 Pod 和它们的清单文件

我们可以看到 Pod 都贴着标签“app: sa-frontend”，服务用这个标签找到目标 Pod。

kubectl apply -f sa-frontend-pod.yaml
Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply
pod "sa-frontend" configured
kubectl apply -f sa-frontend-pod2.yaml
Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply
pod "sa-frontend2" configured

我们看到了一个警告（在应用的时候，而非创建，明白了）。在第二行我们看到部署了 pod “sa-frontend”和 “sa-frontend2”。我们可以过滤想要查看的 Pod：

kubectl get pod -l app=sa-frontend
NAME           READY     STATUS    RESTARTS   AGE
sa-frontend    1/1       Running   0          2h
sa-frontend2   1/1       Running   0          2h

验证带有标签的 Pod 的另一种方法是在上述命令中加入标志符 --show-labels，那么结果中会显示每个 Pod 的所有标签。

很好！Pod 已经贴上了标签，我们准备好通过服务找到它们了。让我们定义 LoadBalancer 类型的服务，如图 18 所示。

图18：用 LoadBalancer 服务平衡负荷

服务的定义

LoadBalancer 服务的 YAML 定义如下所示：

apiVersion: v1
kind: Service              # 1
metadata:
  name: sa-frontend-lb
spec:
  type: LoadBalancer       # 2
  ports:
  - port: 80               # 3
    protocol: TCP          # 4
    targetPort: 80         # 5
  selector:                # 6
    app: sa-frontend       # 7

#1 kind：服务；

#2 type：指定类型，我们选择 LoadBalancer，因为我们想平衡 Pod 之间的负荷；

#3 ports：指定服务获取请求的端口；

#4 protocol：定义交流；

#5 targetPort：可以将来访的请求转发到这个端口；

#6 selector：包含选择pod属性的对象；

#7 app：sa-frontend定义了哪个是目标 Pod，只有拥有标签“app: sa-frontend”的才是目标 Pod。

通过运行如下命令创建服务：

kubectl create -f service-sa-frontend-lb.yaml
service "sa-frontend-lb" created

可以通过运行如下命令检查的服务的状态：

kubectl get svc
NAME             TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
sa-frontend-lb   LoadBalancer   10.101.244.40   <pending>     80:30708/TCP   7m

External-IP 处于 pending 状态（不用再等了，这个状态不会变的）。这是因为我们使用的是 Minikube。如果我们在 Azure 或 Google 云服务上运行，那么我们可以得到一个公开的 IP，那么全世界都可以访问我们的服务了。

尽管如此，Minikube 也不会置我们于不顾，它提供一个非常有用的本地调试命令，如下所示：

minikube service sa-frontend-lb
Opening kubernetes service default/sa-frontend-lb in default browser...

这可以在浏览器中打开指向该服务的 IP。服务受到请求后，会将请求转发给其中一个 Pod（不用理会是哪个）。通过利用服务作为访问入口，这种抽象可以让我们看到并将多个 Pod 当成一个来交互。

服务的总结

在本节中，我们介绍了给资源贴标签，在服务中使用标签作为选择器，我们还定义并创建了一个 LoadBalancer 的服务。这满足了我们希望伸缩应用程序规模的需求（只需加入新的贴了标签的 Pod），并通过将服务作为访问入口在 Pod 之间做负载均衡。\

来自：CSDN（微信号：CSDNnews），作者：Rinor Maloku，译者：弯月，责编：郭芮