service【svc】所有概念

去这篇博客：

【Kubernetes】k8s的svc所有概念和实操详细说明【1】

环境准备

首先需要有一套集群

[root@master ~]# kubectl get nodes
NAME     STATUS   ROLES    AGE   VERSION
master   Ready    master   59d   v1.21.0
node1    Ready    <none>   59d   v1.21.0
node2    Ready    <none>   59d   v1.21.0
[root@master ~]# 

然后我们创建一个文件用来放后面的测试文件，创建一个命名空间，后面测试都在这个命名空间做

[root@master ~]# mkdir svc
[root@master ~]# cd svc
[root@master svc]# kubectl create ns svc
namespace/svc created
[root@master svc]# kubens svc
Context "context" modified.
Active namespace is "svc".
[root@master svc]# 
[root@master svc]# kubectl get pods
No resources found in svc namespace.
[root@master svc]# 

端口映射常规测试

创建pod

现在创建一个pod，我们将虚拟机的80端口映射到主机上的3300

[root@master svc]# cat web1.yaml
apiVersion: apps/v1
kind: Deployment
metadata:creationTimestamp: nulllabels:app: web1name: web1
spec:replicas: 1selector:matchLabels:app: web1strategy: {}template:metadata:creationTimestamp: nulllabels:app: web1spec:terminationGracePeriodSeconds: 0containers:- image: nginxname: nginximagePullPolicy: IfNotPresentports:- name: httpcontainerPort: 80hostPort: 3300resources: {}
status: {}
[root@master svc]# kubectl apply -f web1.yaml
deployment.apps/web1 created
[root@master svc]# 
[root@master svc]# kubectl get pods
NAME                    READY   STATUS    RESTARTS   AGE
web1-5887ddb95c-szjp5   1/1     Running   0          4s
[root@master svc]# kubectl get pods -o wide
NAME                    READY   STATUS    RESTARTS   AGE   IP              NODE    NOMINATED NODE   READINESS GATES
web1-5887ddb95c-szjp5   1/1     Running   0          7s    10.244.104.50   node2   <none>           <none>
[root@master svc]#

上面生成的一个ip，这种就属于内部网络，在集群内是可以直接通的

[root@node2 ~]# ping 10.244.104.50
PING 10.244.104.50 (10.244.104.50) 56(84) bytes of data.
64 bytes from 10.244.104.50: icmp_seq=1 ttl=64 time=0.096 ms
64 bytes from 10.244.104.50: icmp_seq=2 ttl=64 time=0.100 ms
^C
--- 10.244.104.50 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 0.096/0.098/0.100/0.002 ms
[root@node2 ~]# [root@node1 ~]# ping 10.244.104.50
PING 10.244.104.50 (10.244.104.50) 56(84) bytes of data.
64 bytes from 10.244.104.50: icmp_seq=1 ttl=63 time=0.804 ms
64 bytes from 10.244.104.50: icmp_seq=2 ttl=63 time=0.667 ms
^C
--- 10.244.104.50 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 0.667/0.735/0.804/0.073 ms
[root@node1 ~]# 

主机端口映射测试

因为上面生成的pod是运行在node2上的，并且我们将pod的80端口映射为节点的3300，所以这个时候我们可以访问node2ip:3300就会转发到容器内部了

而我们使用node1就不会通的【因为pod没有运行在node1上】

修改pod副本数并测试

之前是一个副本数，现在我们修改为2，这时候node1上就会也运行这个pod了【因为3300端口node2已经被占用了，不可能分配在上面了】

[root@master svc]# kubectl scale deployment web1 --replicas=2
deployment.apps/web1 scaled
[root@master svc]# kubectl get pods
NAME                    READY   STATUS              RESTARTS   AGE
web1-5887ddb95c-sqjrp   0/1     ContainerCreating   0          3s
web1-5887ddb95c-szjp5   1/1     Running             0          11m
[root@master svc]# kubectl get pods -o wide
NAME                    READY   STATUS    RESTARTS   AGE   IP               NODE    NOMINATED NODE   READINESS GATES
web1-5887ddb95c-sqjrp   1/1     Running   0          8s    10.244.166.140   node1   <none>           <none>
web1-5887ddb95c-szjp5   1/1     Running   0          11m   10.244.104.50    node2   <none>           <none>
[root@master svc]# 

pod运行在node1上了，这个时候我们就可以使用node1的ip的3300端口访问了

注：我这只有2个node节点，如果我把副本改为3或，那么只有2个pod状态会为running，另一个状态会为pending【master上有污点，不会被分配，我下面这个报错是因为mster节点上没有镜像】

[root@master svc]# kubectl scale deployment web1 --replicas=3
deployment.apps/web1 scaled
[root@master svc]# kubectl get pods -o wide
NAME                    READY   STATUS             RESTARTS   AGE    IP               NODE     NOMINATED NODE   READINESS GATES
web1-5887ddb95c-4n9cm   0/1     ImagePullBackOff   0          19s    10.244.219.109   master   <none>           <none>
web1-5887ddb95c-sqjrp   1/1     Running            0          2m7s   10.244.166.140   node1    <none>           <none>
web1-5887ddb95c-szjp5   1/1     Running            0          13m    10.244.104.50    node2    <none>           <none>
[root@master svc]# kubectl get pods -o wide

测试完就先删了吧

[root@master svc]# kubectl delete -f web1.yaml 
deployment.apps "web1" deleted
[root@master svc]# 
[root@master svc]# kubectl get pods
No resources found in svc namespace.
[root@master svc]#

上面这种方式呢就是常规的，另外呢，可以使用svc来实现哦。

svc【service】

关于Service

• Kubernetes Service定义了这样一种抽象：一个Pod的逻辑分组，一种可以访问它们不同的策略–通常称为微服务。这一组Pod能够被Service访问到，通常是通过Label Sekector实现的；

• 举个例子，考虑一个图片处理backend，它运行了3个副本。这些副本是可交换的 – frontend不需要关心它们调用了哪个backend副本。然后组成这一组backend程序的Pod实际上可能会发生变化，frontend客户端不应该也没必要知道，而且也不需要跟踪这一组backend的状态。Service定义的抽象能够解耦这种关联。

• 对Kubernetes集群中的应用，Kubernetes提供了简单的Endpoints API，只要service中的一组Pod发生变更，应用程序就会被更新。对非Kubernetes集群中的应用，Kubernetes提供了基本VIP的网桥的方式访问Service，再由Service重定向到backend Pod。

定义Service的意义

• 一个Service在Kubernetes中是一个REST对象，和Pod类似。像所有的REST对象一样，Service定义可以基于POST方式，请求apiserver创建新的实例。例如，假定有一组Pod，它们对外暴漏了9376端口，同时还被打上“app=MyApp”标签。

kind: Service
apiVersion: v1
metadata:name: my-service
spec:selector:app: MyAppports:- protocol: TCPport: 80targetPort: 9376

• 上述配置将创建一个名称为“my-service”的Service对象，它会将请求代理到使用TCP端口9376，并且具有标签“app=MyApp”的pod上。这个Service将被指派一个IP地址（通常为“Cluster IP”）它会被服务的代理使用。该Service的selector将会持续评估，处理结果将被POST到一个名称为"my-service"的Endpoints对象上。

• 需要注意的是，Servie能够将一个接收端口映射到任意的targetPort。默认情况下，targetPort将被设置为与port字段相同的值。可能更有趣的是，targetPort可以是一个字符串，引用了backend Pod的一个端口的名称；但是，实际指派给该端口名称的端口号，在每个backend Pod中可能并不相同。对于部署和设计Service，这种方式会提供更大的灵活性。例如，可以在backend软件下一个版本中，修改Pod暴露的端口，并不会中断客户端的调用。

• Kubernetes service能够支持TCP和UDP协议，默认TCP协议

没有selector的Service

• Service抽象了该如何访问Kubernetes Pod，但也能抽象其他类型的backend，例如：
  • 希望在生产环境中使用外部的数据库集群，但测试环境使用自己的数据库。
  • 希望服务指向另一个Namespace中或其他集群中的服务。
  • 正在将工作负载转移到Kubernetes集群，和运行在Kubernetes集群之外的backend。
• 在任何这些场景中，都能够定义没有selector 的 Service ：

kind: Service
apiVersion: v1
metadata:name: my-service
spec:ports:- protocol: TCPport: 80targetPort: 9376

• 由于这个Service没有selector，就不会创建相关的Endpoints对象。可以手动将Service映射到指定的Endpoints：

kind: Endpoints
apiVersion: v1
metadata:name: my-service
subsets:- addresses:- ip: 1.2.3.4ports:- port: 9376

• 注意：Endpoint IP地址不能loopback（127.0.0.0/8），link-local(169.254.0.0/16),或者link-local多播（224.0.0.0/24）。

• 访问没有selector的Service，与selector的Service的原理相同。请求被路由到用户定义的Endpoint（该示例中为1.2.3.4:9376）

• ExternalName service是Service的特别，它没有selector，也没有定义任何的端口和Endpoint。相反地，对于运行在集群外部的服务，它通过返回该外部服务的别名这种方式来提供服务。

kind: Service
apiVersion: v1
metadata:name: my-servicenamespace: prod
spec:type: ExternalNameexternalName: my.database.example.com

• 当查询主机 my-service.prod.svc.CLUSTER时，集群的DNS服务将返回一个值为my.database.example.com的CNAME记录，访问这个服务的功能方式与其他的相同，唯一不同的是重定向发生的DNS层，而且不会进行代理或转发。如果后续决定要将数据库迁移到Kubetnetes中，可以启动对应的Pod，增加合适的Selector或Endpoint，修改service的typt。

创建svc

pod准备

svc是基于pod标签的，所以我们可以先创建2个pod，且定义下标签，内容和创建后如下

[root@master svc]# cat web1.yaml
apiVersion: apps/v1
kind: Deployment
metadata:creationTimestamp: nulllabels:app: web1name: web1
spec:replicas: 2selector:matchLabels:app1: web1strategy: {}template:metadata:creationTimestamp: nulllabels:app1: web1app2: web2app3: web3spec:terminationGracePeriodSeconds: 0containers:- image: nginxname: nginximagePullPolicy: IfNotPresentports:- name: httpcontainerPort: 80hostPort: 3300resources: {}
status: {}
[root@master svc]# 
[root@master svc]# kubectl apply -f web1.yaml 
deployment.apps/web1 created
[root@master svc]# 
[root@master svc]# kubectl get pods --show-labels 
NAME                    READY   STATUS    RESTARTS   AGE   LABELS
web1-6ccf7b9ffb-6tl9r   1/1     Running   0          5s    app1=web1,app2=web2,app3=web3,pod-template-hash=6ccf7b9ffb
web1-6ccf7b9ffb-f4z4n   1/1     Running   0          5s    app1=web1,app2=web2,app3=web3,pod-template-hash=6ccf7b9ffb
[root@master svc]# 

后

命令行创建svc

svc常用命令

• 下面几项都是可以在下面分类中看到的，就不单独做说明了
  • 查看svc的ip
  • 查看svc详情
  • 删除svc
  • svc的pod说明
  • 。。。

语法

kubectl expose --name=名字 资源类型/名字 --port=xxx  --target-port=yyy --selector=标签名=标签内容  --type=TYPE类型--name=名字 # svc名字，自定义#资源类型/名字 也可以用这种方式展现  资源类型名字 
#资源类型/名字 如下2行：
kubectl expose --name=名字 deploy/web1 --port=xxx  --target-port=yyy
kubectl expose --name=名字 pod pod1 --port=xxx  --target-port=yyy--port=xxx #这个是svc的端口，可以随便定义
--target-port=yyy #这个是容器的实际业务端口，不可以随便填写，必须根据业务端口如实填写【也可不填写，则默认和port端口一致】--selector=标签名=标签内容  # 标签名和标签内容在pod文件中必须存在（labels:里面的内容）】
#如 selector=app2=web2 【这个标签决定了svc下的pod数量】
#如果我们不定义这个标签的话，那么就会使用deploy所定义的默认标签内容（matchLabels:里的内容）--type=TYPE类型 # 定义type类型的【可不填写，默认是ClusterIP类型】# 这个类型呢可选有下面服务发布中的几种类型

svc指定标签说明

• 下面是对svc指定标签说明
  上面说过，创建svc的时候，如果我们不指定用哪个标签定位pod时，使用的是和deploy所用一样的标签
  下面我分别展示不指定标签和指定标签的情况

#默认标签创建svc
[root@master svc]# kubectl expose --name=svc1 deploy web1 --port=80
service/svc1 exposed
[root@master svc]# 
[root@master svc]# kubectl get svc svc1 -o wide
NAME   TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE   SELECTOR
svc1   ClusterIP   10.102.129.139   <none>        80/TCP    7s    app1=web1
[root@master svc]# 
[root@master svc]# kubectl delete svc svc1
service "svc1" deleted
[root@master svc]## 指定标签创建svc
[root@master svc]# kubectl expose --name=svc1 deploy web1 --port=80 --selector=app2=web2
service/svc1 exposed
[root@master svc]# kubectl get svc svc1 -o wide
NAME   TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE   SELECTOR
svc1   ClusterIP   10.106.85.106   <none>        80/TCP    3s    app2=web2
[root@master svc]# 
[root@master svc]# kubectl delete svc svc1
service "svc1" deleted
[root@master svc]# 

svc详情查看【svc的pod数量规则说明】

• 注意看下面后面的说明，其实selector就是决定svc的pod数量内容了【一个pod有一个svcip】。

[root@master ~]# kubectl expose --name=svc1 deploy web1 --port=80 --selector=app2=web2
service/svc1 exposed
[root@master ~]# kubectl describe svc svc1 
Name:              svc1
Namespace:         svc
Labels:            app=web1 # svc本身的标签，可不用管
Annotations:       <none>
Selector:          app2=web2 # 定义svc的pod数量标签【svc指定该标签创建后，有这个标签的pod都属于该svc】
Type:              ClusterIP
IP Family Policy:  SingleStack
IP Families:       IPv4
IP:                10.99.7.214
IPs:               10.99.7.214
Port:              <unset>  80/TCP
TargetPort:        80/TCP # 因为没有指定，所以默认和port一样。
Endpoints:         10.244.104.58:80,10.244.166.161:80 # 这个就是svc的ip和后面的端口【svc数量取决于有有上面标签的pod】
Session Affinity:  None
Events:            <none>
[root@master ~]# 

• 现在我们手动创建一个拥有app2=web2标签的pod，看是否能自动识别到【正常情况是能自动识别到的】

[root@master ~]# kubectl run pod1 --image=nginx --image-pull-policy=IfNotPresent --labels="app2=web2"
pod/pod1 created
[root@master ~]# kubectl get pods --show-labels 
NAME                    READY   STATUS    RESTARTS   AGE   LABELS
pod1                    1/1     Running   0          9s    app2=web2
web1-6ccf7b9ffb-6tl9r   1/1     Running   0          42m   app1=web1,app2=web2,app3=web3,pod-template-hash=6ccf7b9ffb
web1-6ccf7b9ffb-f4z4n   1/1     Running   0          42m   app1=web1,app2=web2,app3=web3,pod-template-hash=6ccf7b9ffb
[root@master ~]# # 可以看到svc的ip数量已经变成3个了
[root@master ~]# kubectl describe svc svc1 
Name:              svc1
Namespace:         svc
Labels:            app=web1
Annotations:       <none>
Selector:          app2=web2
Type:              ClusterIP
IP Family Policy:  SingleStack
IP Families:       IPv4
IP:                10.99.7.214
IPs:               10.99.7.214
Port:              <unset>  80/TCP
TargetPort:        80/TCP
Endpoints:         10.244.104.58:80,10.244.104.59:80,10.244.166.161:80
Session Affinity:  None
Events:            <none>
[root@master ~]# 

• 下面我们把web1的副本数改为1，这下svc的数量就会变成2 了

[root@master svc]# kubectl scale deployment web1 --replicas=1
deployment.apps/web1 scaled
[root@master ~]# 
[root@master ~]# kubectl describe svc svc1 
Name:              svc1
Namespace:         svc
Labels:            app=web1
Annotations:       <none>
Selector:          app2=web2
Type:              ClusterIP
IP Family Policy:  SingleStack
IP Families:       IPv4
IP:                10.99.7.214
IPs:               10.99.7.214
Port:              <unset>  80/TCP
TargetPort:        80/TCP
Endpoints:         10.244.104.59:80,10.244.166.161:80
Session Affinity:  None
Events:            <none>
[root@master ~]# 

• 将上面创建的pod1给删了吧

[root@master ~]# kubectl delete pod pod1 --force
warning: Immediate deletion does not wait for confirmation that the running resource has been terminated. The resource may continue to run on the cluster indefinitely.
pod "pod1" force deleted
[root@master ~]#

svc的IP测试【svc和pod的关系说明】【iptables和ipvs区别】

测试流程说明大概如下图：

• 现在我们给同一个svc下的3个po分别d写入一个nginx文件，并查看svc的ip

[root@master ~]# kubectl get pods -o wide
NAME                    READY   STATUS    RESTARTS   AGE   IP               NODE    NOMINATED NODE   READINESS GATES
pod1                    1/1     Running   0          6s    10.244.104.60    node2   <none>           <none>
web1-6ccf7b9ffb-6tl9r   1/1     Running   0          60m   10.244.166.161   node1   <none>           <none>
web1-6ccf7b9ffb-8286p   1/1     Running   0          51s   10.244.104.61    node2   <none>           <none>
[root@master ~]# kubectl exec -it web1-6ccf7b9ffb-6tl9r -- sh -c "echo 111 > /usr/share/nginx/html/index.html"
[root@master ~]# kubectl exec -it web1-6ccf7b9ffb-8286p -- sh -c "echo 222 > /usr/share/nginx/html/index.html"
[root@master ~]# kubectl exec -it pod1 -- sh -c "echo 333 > /usr/share/nginx/html/index.html"
[root@master ~]# kubectl get svc
NAME   TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)   AGE
svc1   ClusterIP   10.99.7.214   <none>        80/TCP    25m
[root@master ~]#

• 这时候我们curl测试这个svc的ip，可以发现，svc会负载均衡的形式出现该svc下pod的内容。

[root@master svc]# while true ; do 
> curl 10.99.7.214
> sleep 1
> done
333
111
222
111
222
111
111
222
333
222
222
222
222
111
222
^C        
[root@master svc]# 
[root@master svc]# while true ; do  curl 10.99.7.214; sleep 1; done

• 开始图中说了，默认是iptables模式，所以端口通，但是ping不通这个svc的ip，这是正常的。

[root@master ~]# ping 10.99.7.214
PING 10.99.7.214 (10.99.7.214) 56(84) bytes of data.
^C
--- 10.99.7.214 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2000ms[root@master ~]# 
[root@master ~]# telnet 10.99.7.214 80
Trying 10.99.7.214...
Connected to 10.99.7.214.
Escape character is '^]'.^CConnection closed by foreign host.
[root@master ~]#

• svc命令创建到此结束，删除上面创建的3个opd

[root@master svc]# kubectl get pods
NAME                    READY   STATUS    RESTARTS   AGE
pod1                    1/1     Running   0          16h
web1-6ccf7b9ffb-6tl9r   1/1     Running   0          17h
web1-6ccf7b9ffb-8286p   1/1     Running   0          16h
[root@master svc]# kubectl delete pod pod1 
pod "pod1" deleted
[root@master svc]# kubectl delete -f web1.yaml 
deployment.apps "web1" deleted
[root@master svc]# kubectl get pods
No resources found in svc namespace.
[root@master svc]# 

服务的发现

• Kubernetes 支持3种基本的服务发现模式 —— 环境变量和 DNS【含一个扩展的ClusterIP方法】

说明【必看】

• 我们现在所创建的应用都比较单一
  有时需要创建多级的应用，如：wordpress+mysql
  具体配置看下面3个发现方法

• 下面的实验使用mysql和wordpress镜像做实验，所以需要先准备如下2个镜像

[root@node1 ~]# docker images | grep mysql
hub.c.163.com/library/mysql                                       latest     9e64176cd8a2   4 years ago     407MB
[root@node1 ~]# docker images | grep wordpress
hub.c.163.com/library/wordpress                                   latest     dccaeccfba36   4 years ago     406MB
[root@node1 ~]# [root@node2 ~]# docker images | grep mysql
hub.c.163.com/library/mysql                                       latest     9e64176cd8a2   4 years ago     407MB
[root@node2 ~]# docker images | grep wordp
hub.c.163.com/library/wordpress                                   latest     dccaeccfba36   4 years ago     406MB
[root@node2 ~]# 

1、clusterIP-发现

说明

• Kubernetes中服务发现主要通过每个主机上的kube-proxy组件实现，其作用是通过控制iptables将对Service ClusterIP的请求，转发到后端Endpoints中，剩下就交给容器网络。

• 下面的实验呢，实际上功能还是在pod中定义的，svc只是端口转发的一个作用。

实验流程

• 【这个实际上是变量方式过渡用的，这样能更容易理解服务发现的原理】
• 如，需要多级发现的话，如下图
  • 发现流程就是从上往下的流程
  • 创建流程的话就是从下往上依次创建

• 生成一个yaml文件，编辑并创建dbpod

[root@master svc]# kubectl run dbpod --image=hub.c.163.com/library/mysql --image-pull-policy=IfNotPresent --dry-run=client -o yaml > dbpod.yaml
[root@master svc]# vim dbpod.yaml                                            
[root@master svc]# cat dbpod.yaml
apiVersion: v1
kind: Pod
metadata:creationTimestamp: nulllabels:run: dbpodname: dbpod
spec:terminationGracePeriodSeconds: 0containers:- image: hub.c.163.com/library/mysqlimagePullPolicy: IfNotPresentname: dbpodresources: {}env:- name: MYSQL_ROOT_PASSWORD #定义root密码value: haha001- name: MYSQL_USER # 定义普通用户value: tom- name: MYSQL_PASSWORD #普通用户tom密码value: haha001- name: MYSQL_DATABASE #数据库名称value: wordpressdnsPolicy: ClusterFirstrestartPolicy: Always
status: {}
[root@master svc]# kubectl apply -f dbpod.yaml 
pod/dbpod created
[root@master svc]# 
[root@master svc]# kubectl get pods -o wide
NAME    READY   STATUS    RESTARTS   AGE   IP              NODE    NOMINATED NODE   READINESS GATES
dbpod   1/1     Running   0          5s    10.244.104.62   node2   <none>           <none>
[root@master svc]#

• 创建dbsvc

[root@master svc]# kubectl expose --name=dbsvc pod dbpod --port=3306 --target-port=3306
service/dbsvc exposed
[root@master svc]# 
[root@master svc]# kubectl get svc -o wide
NAME    TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE   SELECTOR
dbsvc   ClusterIP   10.105.80.230   <none>        3306/TCP   6s    run=dbpod
svc1    ClusterIP   10.99.7.214     <none>        80/TCP     22h   app2=web2
[root@master svc]# 

• blogpod文件编辑和创建

[root@master svc]# cp dbpod.yaml blogpod.yaml
[root@master svc]# vim blogpod.yaml
[root@master svc]# cat blogpod.yaml
apiVersion: v1
kind: Pod
metadata:creationTimestamp: nulllabels:run: blogpodname: blogpod
spec:terminationGracePeriodSeconds: 0containers:- image: hub.c.163.com/library/wordpressimagePullPolicy: IfNotPresentname: blogpodresources: {}env:- name: WORDPRESS_DB_HOSTvalue: 10.105.80.230 #dbsvc的ip- name: WORDPRESS_DB_USER #用户名value: root - name: WORDPRESS_DB_PASSWORD #root密码【信息来源于dbpod里面定义的】value: haha001- name: wORDPRESS_DB_NAME #数据库名称【信息来源于dbpod里面定义的】value: wordpressdnsPolicy: ClusterFirstrestartPolicy: Always
status: {}
[root@master svc]# kubectl apply -f blogpod.yaml
pod/blogpod created
[root@master svc]# 
[root@master svc]# kubectl get pods -o wide
NAME      READY   STATUS    RESTARTS   AGE     IP              NODE    NOMINATED NODE   READINESS GATES
blogpod   1/1     Running   0          8s      10.244.104.63   node2   <none>           <none>
dbpod     1/1     Running   0          7m34s   10.244.104.62   node2   <none>           <none>
[root@master svc]# 

• 创建blogsvc
  注意看，这个svc的类型已经变成了NodePort了

# type=NodePort 意思是负责发布
[root@master svc]# kubectl expose --name=blogsvc pod blogpod --port=80 --type=NodePort
service/blogsvc exposed
[root@master svc]# 
[root@master svc]# kubectl get svc 
NAME      TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
blogsvc   NodePort    10.109.29.73    <none>        80:31085/TCP   5s
dbsvc     ClusterIP   10.105.80.230   <none>        3306/TCP       7m38s
svc1      ClusterIP   10.99.7.214     <none>        80/TCP         22h
[root@master svc]# 

• 自此，就配置完毕了，并且blogsvc后面显示的端口是80:31085意思就是，blogsvc中的pod的80端口对应的主机的端口是31085，所以只要访问主机的31085端口，就可以访问到blogsvc的80端口了，并且，如果当blogsvc连接成功dbsvc的数据库以后，我们就可以直接访问这个wordpress了【所有node节点的ip均可使用哦】，测试
  
  

2、变量的方式方法-发现

说明

• 当Pod运行在Node上，kubelet会为每个活跃的Service添加一组环境变量。它同时支持Docker links兼容变量，简单的{SVCNAME}_SERVICE_HOST 【服务的ip】和{SVCNAME}_SERVICE_PORT【服务的端口】变量，这里 Service 的名称需大写，横线被转换成下划线。
  举个例子，一个名称为 dbsvc 的 Service 暴露了 TCP 端口 3306，同时给它分配了 Cluster IP 地址 10.105.80.230，这个 Service 生成了如下环境变量：

#该svc的容器内部执行【继续往下看，有步骤】
root@blogpod:/var/www/html# env | grep DBSVC
DBSVC_PORT_3306_TCP_ADDR=10.105.80.230
DBSVC_SERVICE_PORT=3306
DBSVC_PORT_3306_TCP_PORT=3306
DBSVC_PORT_3306_TCP=tcp://10.105.80.230:3306
DBSVC_SERVICE_HOST=10.105.80.230
DBSVC_PORT=tcp://10.105.80.230:3306
DBSVC_PORT_3306_TCP_PROTO=tcp

• 现在我们查看实际环境变量来做说明
  查看evc变量【注意，上面创建的2个pod并没有被删除，下面实验的pod内容是上面实验创建的】

[root@master svc]# kubectl get pods
NAME      READY   STATUS    RESTARTS   AGE
blogpod   1/1     Running   0          18h
dbpod     1/1     Running   0          18h
[root@master svc]# 
# 进入到容器
[root@master svc]# kubectl exec -it blogpod -- bash# 查看所有环境变量
root@blogpod:/var/www/html# env
HOSTNAME=blogpod
SVC1_PORT_80_TCP_ADDR=10.99.7.214
SVC1_PORT_80_TCP_PROTO=tcp
KUBERNETES_PORT=tcp://10.96.0.1:443
KUBERNETES_PORT_443_TCP_PORT=443
TERM=xterm
# 内容太多，我删了大部分
root@blogpod:/var/www/html##前面说过这个pod会以变量的方式去记录服务的信息
#大写服务名_SERVICE_HOST=服务的IP
#大写服务名_SERVICE_PORT=服务的端口
# 所以我们可以根据svc大写名称过滤出这2内容的
root@blogpod:/var/www/html# env | grep DBSVC_SERVICE
DBSVC_SERVICE_PORT=3306
DBSVC_SERVICE_HOST=10.105.80.230
root@blogpod:/var/www/html# 

• 这意味着需要有顺序的要求 —— Pod 想要访问的任何 Service 必须在 Pod 自己之前被创建，否则这些环境变量就不会被赋值。【简单来说，就是，只记录，在我pod之前创建的svc的信息，在我后面创建的svc我是不记录的=】=DNS 并没有这个限制。==

# 我现在在一个新的窗口创建一个dbpod的svc2
[root@master svc]# kubectl get svc
NAME      TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
blogsvc   NodePort    10.109.29.73    <none>        80:31085/TCP   18h
dbsvc     ClusterIP   10.105.80.230   <none>        3306/TCP       18h
svc1      ClusterIP   10.99.7.214     <none>        80/TCP         41h
[root@master svc]# kubectl expose --name=svc2 pod dbpod --port=3306
service/svc2 exposed
[root@master svc]## 然后在刚才的容器内部，是查看不到这个svc2的变量信息的
root@blogpod:/var/www/html# env | grep SVC2_SERVICE      
root@blogpod:/var/www/html# # 现在我们删除这个pod，并且新增一个svc2
[root@master svc]# kubectl delete pod blogpod 
[root@master svc]# kubectl expose --name=svc2 pod dbpod --port=3306# 回到刚才容器那个窗口，发现之前的容器被自动推迟了，因为容器被删了
# 然后我们重新进入该容器内部，就可以看到这2个svc的信息都有了
root@blogpod:/var/www/html# kubectexit
command terminated with exit code 1
[root@master svc]# 
[root@master svc]# 
[root@master svc]# kubectl exec -it blogpod -- bash
root@blogpod:/var/www/html# env | grep DBSVC_SERVICE
DBSVC_SERVICE_PORT=3306
DBSVC_SERVICE_HOST=10.105.80.230
root@blogpod:/var/www/html# env | grep SVC2_SERVICE   
SVC2_SERVICE_PORT=3306
SVC2_SERVICE_HOST=10.98.141.198
root@blogpod:/var/www/html# 

实验流程

• 上面的逻辑了解以后，我们现在就开始进行操作
  我们编辑blogpod的配置文件，把ip替换为变量形式创建看是否可行

#展示变量引用的区别，linux使用的是{}，而这个变量引用使用的是()
[root@master svc]# aa=1
[root@master svc]# echo ${aa}
1
[root@master svc]# echo $(aa)
bash: aa: command not found...[root@master svc]# [root@master svc]# kubectl get pods
NAME      READY   STATUS    RESTARTS   AGE
blogpod   1/1     Running   0          18h
dbpod     1/1     Running   0          8s
[root@master svc]# kubectl delete pod blogpod 
pod "blogpod" deleted
[root@master svc]# kubectl get pods
NAME    READY   STATUS    RESTARTS   AGE
dbpod   1/1     Running   0          18s
[root@master svc]# 
[root@master svc]# vi blogpod.yaml 
[root@master svc]# cat blogpod.yaml 
apiVersion: v1
kind: Pod
metadata:creationTimestamp: nulllabels:run: blogpodname: blogpod
spec:terminationGracePeriodSeconds: 0containers:- image: hub.c.163.com/library/wordpressimagePullPolicy: IfNotPresentname: blogpodresources: {}env:- name: WORDPRESS_DB_HOSTvalue: $(DBSVC_SERVICE_HOST) #固定的变量应用方式- name: WORDPRESS_DB_USERvalue: root- name: WORDPRESS_DB_PASSWORDvalue: haha001- name: wORDPRESS_DB_NAMEvalue: wordpressdnsPolicy: ClusterFirstrestartPolicy: Always
status: {}
[root@master svc]# 
[root@master svc]# kubectl apply -f blogpod.yaml
pod/blogpod created
[root@master svc]# 
[root@master svc]# kubectl get pods
NAME      READY   STATUS    RESTARTS   AGE
blogpod   1/1     Running   0          4s
dbpod     1/1     Running   0          47s
[root@master svc]#

• 测试
  说明看图中哈
  
• 总结
  1、这种方式适用于取任何变量
  2、只能获取相同namespace里的变量
  3、变量的获取有先后的顺序，引用的变量必须要先创建【就是这句话：只记录，在我pod之前创建的svc的信息，在我后面创建的svc我是不记录的】

3、NDS-发现

说明

• 一个可选（尽管强烈推荐）集群插件 是 DNS 服务器。 DNS 服务器监视着创建新 Service 的 Kubernetes API，从而为每一个 Service 创建一组 DNS 记录。 如果整个集群的 DNS 一直被启用，那么所有的 Pod 应该能够自动对 Service 进行名称解析。

• 例如，有一个名称为 “my-service” 的 Service，它在 Kubernetes 集群中名为 “my-ns” 的 Namespace 中，为 “my-service.my-ns” 创建了一条 DNS 记录。 在名称为 “my-ns” 的 Namespace 中的 Pod 应该能够简单地通过名称查询找到 “my-service”。 在另一个 Namespace 中的 Pod 必须限定名称为 “my-service.my-ns”。 这些名称查询的结果是 Cluster IP。

• Kubernetes 也支持对端口名称的 DNS SRV（Service）记录。 如果名称为 “my-service.my-ns” 的 Service 有一个名为 “http” 的 TCP 端口，可以对 “_http._tcp.my-service.my-ns” 执行 DNS SRV 查询，得到 “http” 的端口号。

• Kubernetes DNS 服务器是唯一的一种能够访问 ExternalName 类型的 Service 的方式。
  更多信息可以查看 DNS Pod 和 Service。

DNS测试

• DNS的流程原理如下图
  

• 既然是DNS发现，那么先丢出一个问题
  问题：kube-system下面有一个kube-dns的svc，那么如何查询到kube-dns这个svc所对应的pod呢？
  答案： 其实很简单的，前面我们说过，svc的pod是标签决定的，所以我们只要查看这个svc的标签，然后通过这个标签去查看所有的pod就可以了

[root@master svc]# kubectl get svc -n kube-system 
NAME             TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                  AGE
kube-dns         ClusterIP   10.96.0.10      <none>        53/UDP,53/TCP,9153/TCP   117d
metrics-server   ClusterIP   10.104.158.11   <none>        443/TCP                  112d
[root@master svc]# # 查看kube-dns标签
[root@master svc]# kubectl get svc -n kube-system -o wide
NAME             TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                  AGE    SELECTOR
kube-dns         ClusterIP   10.96.0.10      <none>        53/UDP,53/TCP,9153/TCP   117d   k8s-app=kube-dns
metrics-server   ClusterIP   10.104.158.11   <none>        443/TCP                  112d   k8s-app=metrics-server
[root@master svc]# 
#查看这个标签的虚拟机，可以看到有2个
[root@master svc]# kubectl get pods -n kube-system -l  k8s-app=kube-dns
NAME                       READY   STATUS    RESTARTS   AGE
coredns-545d6fc579-848f6   1/1     Running   4          111d
coredns-545d6fc579-94wgt   1/1     Running   4          111d
[root@master svc]# 
[root@master svc]#

• 现在我们做一个测试
  先创建一个任意nginx的pod出来，后面访问这个pod做测试
  然后对nginx的html随便写入内容，便于测试是否成功
  然后创建一个pod1的svc1出来

[root@master svc]# cat pod1.yaml 
apiVersion: v1
kind: Pod
metadata:labels:test: livenessname: pod1
spec:terminationGracePeriodSeconds: 0containers:- name: livenessimage: nginximagePullPolicy: IfNotPresent
[root@master svc]#
[root@master svc]# kubectl apply -f pod1.yaml
pod/pod1 created
[root@master svc]# kubectl get pods
NAME      READY   STATUS    RESTARTS   AGE
blogpod   1/1     Running   0          64m
dbpod     1/1     Running   0          65m
pod1      1/1     Running   0          4s
[root@master svc]# 
[root@master svc]# kubectl exec -it pod1 -- sh -c "echo 11 > /usr/share/nginx/html/index.html"
[root@master svc]# 
[root@master svc]# kubectl get svc
NAME      TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
blogsvc   NodePort    10.109.29.73    <none>        80:31085/TCP   19h
dbsvc     ClusterIP   10.105.80.230   <none>        3306/TCP       19h
svc1      ClusterIP   10.99.7.214     <none>        80/TCP         42h
svc2      ClusterIP   10.98.141.198   <none>        3306/TCP       72m
[root@master svc]# kubectl delete svc svc1
service "svc1" deleted
[root@master svc]# 
[root@master svc]# kubectl expose --name=svc1 pod pod1 --port=80
service/svc1 exposed
[root@master svc]# 

• 然后我们现在在同一命名空间中 重新创建一个临时的pod，用来访问svc1的内容试试
  正确情况：我们可以直接curl svc1出现pod1的内容，而不能直接curl pod1，是因为svc会自动注册dns

[root@master svc]# kubectl run testpod --image=nginx --image-pull-policy=IfNotPresent -it --rm --bash
Error: unknown flag: --bash
See 'kubectl run --help' for usage.
[root@master svc]# kubectl run testpod --image=nginx --image-pull-policy=IfNotPresent -it --rm -- bash
If you don't see a command prompt, try pressing enter.
root@testpod:/# 
root@testpod:/# curl pod1
curl: (6) Could not resolve host: pod1
root@testpod:/# curl svc1
11
root@testpod:/# 
root@testpod:/# 

• 在其他命名空间访问这个pod1
  这种访问呢需要在svc名称后面加一个.命名空间名称【这个命名空间是pod1所属的命名空间】

[root@master svc]# kubectl run testpod --image=nginx --image-pull-policy=IfNotPresent -it -n default --rm -- bash
If you don't see a command prompt, try pressing enter.
root@testpod:/# 
root@testpod:/# crul svc1
bash: crul: command not found
root@testpod:/# 
root@testpod:/# curl svc1.svc    
11
root@testpod:/# 
root@testpod:/# cat /etc/resolv.conf 
nameserver 10.96.0.10
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5
root@testpod:/# 

• 为了验证会自动注册dns，我们可以看到容器内部的dns和Kube-dns的ip是一样的

root@testpod:/# cat /etc/resolv.conf 
nameserver 10.96.0.10
search svc.svc.cluster.local svc.cluster.local cluster.local
options ndots:5
root@testpod:/# exit 
exit
Session ended, resume using 'kubectl attach testpod -c testpod -i -t' command when the pod is running
pod "testpod" deleted
[root@master svc]# 
[root@master svc]# 
[root@master svc]# kubectl get svc -o wide -n kube-system 
NAME             TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                  AGE    SELECTOR
kube-dns         ClusterIP   10.96.0.10      <none>        53/UDP,53/TCP,9153/TCP   117d   k8s-app=kube-dns
metrics-server   ClusterIP   10.104.158.11   <none>        443/TCP                  112d   k8s-app=metrics-server
[root@master svc]# 

实验流程

这个实验就比较直观了，我们最开始创建的dbsvc和blogsvc都没有删除的，dbpod我们不动，我们删除blogpod，并编辑配置文件，把发现方式改为dns的方式，内容直接改成dbsvc即可

[root@master svc]# kubectl get pods
NAME      READY   STATUS    RESTARTS   AGE
blogpod   1/1     Running   0          79m
dbpod     1/1     Running   0          79m
pod1      1/1     Running   0          14m
[root@master svc]# kubectl delete pod pod1
pod "pod1" deleted
[root@master svc]# kubectl delete pod blogpod 
pod "blogpod" deleted
[root@master svc]# 
[root@master svc]# vim blogpod.yaml 
[root@master svc]# cat blogpod.yaml
apiVersion: v1
kind: Pod
metadata:creationTimestamp: nulllabels:run: blogpodname: blogpod
spec:terminationGracePeriodSeconds: 0containers:- image: hub.c.163.com/library/wordpressimagePullPolicy: IfNotPresentname: blogpodresources: {}env:- name: WORDPRESS_DB_HOSTvalue: dbsvc # 就修改这一行内容即可- name: WORDPRESS_DB_USERvalue: root- name: WORDPRESS_DB_PASSWORDvalue: haha001- name: wORDPRESS_DB_NAMEvalue: wordpressdnsPolicy: ClusterFirstrestartPolicy: Always
status: {}
[root@master svc]# 
[root@master svc]# kubectl apply -f blogpod.yaml 
pod/blogpod created
[root@master svc]# [root@master svc]# kubectl get pods
NAME      READY   STATUS    RESTARTS   AGE
blogpod   1/1     Running   0          39s
dbpod     1/1     Running   0          81m
[root@master svc]#
[root@master svc]# kubectl get svc | egrep  'blogsvc|dbsvc'
blogsvc   NodePort    10.109.29.73    <none>        80:31085/TCP   19h
dbsvc     ClusterIP   10.105.80.230   <none>        3306/TCP       19h
[root@master svc]# 

• 测试
  和之前的一样，能到达这个界面就算成功的。
  
• 至此，服务发现就完了，我们把上面创建的pod和svc全删了吧

[root@master svc]# kubectl get svc
NAME      TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
blogsvc   NodePort    10.109.29.73    <none>        80:31085/TCP   19h
dbsvc     ClusterIP   10.105.80.230   <none>        3306/TCP       20h
svc1      ClusterIP   10.111.33.222   <none>        80/TCP         26m
svc2      ClusterIP   10.98.141.198   <none>        3306/TCP       99m
[root@master svc]# kubectl delete svc blogsvc 
service "blogsvc" deleted
[root@master svc]# kubectl delete svc dbsvc 
service "dbsvc" deleted
[root@master svc]# kubectl delete svc svc1
service "svc1" deleted
[root@master svc]# kubectl delete svc svc2
service "svc2" deleted
[root@master svc]# 
[root@master svc]# kubectl get pods
NAME      READY   STATUS    RESTARTS   AGE
blogpod   1/1     Running   0          13m
dbpod     1/1     Running   0          93m
[root@master svc]# kubectl delete pod blogpod 
pod "blogpod" deleted
[root@master svc]# kubectl delete pod dbpod 
pod "dbpod" deleted
[root@master svc]# kubectl get pods
No resources found in svc namespace.
[root@master svc]# 

服务的发布

说明

• 对一些应用（如 Frontend）的某些部分，可能希望通过外部（Kubernetes 集群外部）IP 地址暴露 Service。

Kubernetes ServiceTypes 允许指定一个需要的类型的 Service，默认是 ClusterIP 类型。

• Type 的取值以及行为如下【下面的4个类型在我sv概念那篇中也有详细说明】：
  • ClusterIP：通过集群的内部 IP 暴露服务，选择该值，服务只能够在集群内部可以访问，这也是默认的 ServiceType。
  • NodePort：通过每个 Node 上的 IP 和静态端口（NodePort）暴露服务。NodePort 服务会路由到 - ClusterIP 服务，这个 ClusterIP 服务会自动创建。通过请求 :，可以从集群的外部访问一个 NodePort 服务。
  • LoadBalancer：使用云提供商的负载均衡器，可以向外部暴露服务。外部的负载均衡器可以路由到 NodePort 服务和 ClusterIP 服务。
  • ExternalName：通过返回 CNAME 和它的值，可以将服务映射到 externalName 字段的内容（例如， foo.bar.example.com）。 没有任何类型代理被创建，这只有 Kubernetes 1.7 或更高版本的 kube-dns 才支持。

nodeport类型

说明

• 如果设置 type 的值为 “NodePort”，Kubernetes master 将从给定的配置范围内（默认：30000-32767）分配端口，每个 Node 将从该端口（每个 Node 上的同一端口）代理到 Service。该端口将通过 Service 的 spec.ports[*].nodePort 字段被指定。

• 如果需要指定的端口号，可以配置 nodePort 的值，系统将分配这个端口，否则调用 API 将会失败（比如，需要关心端口冲突的可能性）。

• 这可以让开发人员自由地安装他们自己的负载均衡器，并配置 Kubernetes 不能完全支持的环境参数，或者直接暴露一个或多个 Node 的 IP 地址。

• 需要注意的是，Service 将能够通过 :spec.ports[].nodePort 和 spec.clusterIp:spec.ports[].port 而对外可见。

• NodePort的各种关系如下
  

实操

创建pod和svc

顺序一般是先创建pod，再创建svc

[root@master svc]# cat pod1.yaml 
apiVersion: v1
kind: Pod
metadata:labels:test: livenessname: pod1
spec:terminationGracePeriodSeconds: 0containers:- name: livenessimage: nginximagePullPolicy: IfNotPresent
[root@master svc]# kubectl apply -f pod1.yaml
pod/pod1 created
[root@master svc]# 
[root@master svc]# kubectl exec -it pod1 -- sh -c "echo 11 > /usr/share/nginx/html/index.html"
[root@master svc]#
[root@master svc]# kubectl get pods
NAME   READY   STATUS    RESTARTS   AGE
pod1   1/1     Running   0          4s
[root@master svc]# # 注意因为我没有指定 --type=参数，所以默认创建的TYPE类型是 ClusterIp
[root@master svc]# kubectl expose --name=svc1 pod pod1 --port=80
service/svc1 exposed
[root@master svc]# 
[root@master svc]# kubectl get svc
NAME   TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
svc1   ClusterIP   10.110.202.34   <none>        80/TCP    4s
[root@master svc]# 

修改TYPE类型【修改svc内容】

• 修改svc的内容方法也是一样，我只是使用修改type为例。
• 如下，svc1现在的类型是ClusterIp

[root@master svc]# kubectl get svc
NAME   TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
svc1   ClusterIP   10.110.202.34   <none>        80/TCP    4s
[root@master svc]# 

• 现在我们将它修改为NodePort
  修改命令： kubectl edit svc svc名称，回车就会进入到一个文件的样子，修改完毕以后，:wq保存即可
  大概在33行，有一个type: NodePort，type后面就是最终的type类型【记不得不要，填一个错的，保存，文件开头就会提示所有的type类型了】

# 
[root@master svc]# kubectl edit svc svc1C# Please edit the object below. Lines beginning with a '#' will be ignored,2 # and an empty file will abort the edit. If an error occurs while saving this file will         be 3 # reopened with the relevant failures.4 #5 # services "svc1" was not valid:6 # * spec.type: Unsupported value: "Cluste": supported values: "ClusterIP", "ExternalName        ", "LoadBalancer", "NodePort"7 #8 apiVersion: v19 kind: Service10 metadata:11   creationTimestamp: "2021-10-27T04:19:18Z"12   labels:13     test: liveness14   name: svc115   namespace: svc16   resourceVersion: "11457298"17   selfLink: /api/v1/namespaces/svc/services/svc118   uid: 9c2bbd01-5e0e-42f5-b33f-ed8affcddba819 spec:20   clusterIP: 10.110.202.3421   clusterIPs:22   - 10.110.202.3423   ipFamilies:24   - IPv425   ipFamilyPolicy: SingleStack26   ports:27   - port: 8028     protocol: TCP29     targetPort: 8030   selector:31     test: liveness32   sessionAffinity: None33   type: NodePort34 status: 
:wq
[root@master svc]## 保存以后呢，我们再次查看svc，就会看到已经生效了
[root@master svc]# kubectl get svc
NAME   TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
svc1   NodePort   10.110.202.34   <none>        80:31100/TCP   5m3s
[root@master svc]# #这样修改实际效果就和我们创建时候指定type一样了
[root@master svc]# kubectl delete svc svc1 
service "svc1" deleted
[root@master svc]# 
[root@master svc]# kubectl expose --name=svc1 pod pod1 --port=80 --type=NodePort
service/svc1 exposed
[root@master svc]# kubectl get svc
NAME   TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
svc1   NodePort   10.108.94.24   <none>        80:30327/TCP   4s
[root@master svc]# 
[root@master svc]# kubectl delete svc svc1 
service "svc1" deleted
[root@master svc]# 

• 根据NodePort的特性，我们修改以后呢，就可以使用集群内的任意IP，后面跟上这个svc的端口号，就可以看到svc下pod中的内容了【我是nginx，所以是80端口，同理，pod中的任意端口都可以根据实际情况使用或访问的】
  

弊端

• 看懂上面nodeport的说明以后，可以总结有2个风险
  • 1、端口越多，漏洞可能就越大，风险也就越高。
  • 2、端口越多，维护起来也相对更加麻烦

LB【LoadBalancer】 类型

说明

• 使用支持外部负载均衡器的云提供商的服务，设置 type 的值为 “LoadBalancer”，将为 Service 提供负载均衡器。 负载均衡器是异步创建的，关于被提供的负载均衡器的信息将会通过 Service 的 status.loadBalancer 字段被发布出去。

kind: Service
apiVersion: v1
metadata:name: my-service
spec:selector:app: MyAppports:- protocol: TCPport: 80targetPort: 9376nodePort: 30061clusterIP: 10.0.171.239loadBalancerIP: 78.11.24.19type: LoadBalancer
status:loadBalancer:ingress:- ip: 146.148.47.155

• kubernetes并没有提供LB类型的发布方式，所以实现LB都会借用到第三方工具。
• 来自外部负载均衡器的流量将直接打到 backend Pod 上，不过实际它们是如何工作的，这要依赖于云提供商。 在这些情况下，将根据用户设置的 loadBalancerIP 来创建负载均衡器。 某些云提供商允许设置 loadBalancerIP。如果没有设置 loadBalancerIP，将会给负载均衡器指派一个临时 IP。 如果设置了 loadBalancerIP，但云提供商并不支持这种特性，那么设置的 loadBalancerIP 值将会被忽略掉。
• 实际的配置过程呢，我们可以根据官方网址中的流程：METALLB

ingress