kubernetes(k8s) ：service实现服务发现和负载均衡

妖狐艹你老母 2023-03-12 07:21 47阅读 0赞

### 文章目录 ###

*  1.service是什么？
 *  2.service的类型
 *   *  2.1VIP和Service代理
     *  2.2没有selector的Service
 *  3. service的三种工作模式
 *   *   *   *  第一种: 是Userspace方式
             *  第二种: iptables模型
             *  第三种: ipvs模型
 *  4. service的四种类型
 *  5.Service如何实现？
 *   *  集群内部访问pod
     *  5.1创建service：（ClusterIP方式）
     *  5.2.Headless Service “无头服务”
     *  5.3将service的工作模式改为lvs(ipvs)
 *  6.Flannel vxlan模式跨主机通信原理
 *  7.NodePort方式
 *  8. ExternalName方式
 *  9.LoadBanalce方式

# 1.service是什么？ #

service是kubernetes中最核心的资源对象之一,service和pod之间是通过Label串起来,相同的Service的pod的Label是一样的. 同一个service下的所有pod是通过`kube-proxy`实现负载均衡.而每个service都会分配一个全局唯一的虚拟ip,也就cluster ip.

在该service整个生命周期内,cluster ip保持不变，而在kubernetes中还有一个dns服务，它会把service的name解析为cluster ip。

Service可以看作是一组提供相同服务的Pod对外的访问接口。借助Service，应用可以方便地实现服务发现和负载均衡。（可以通过Ingress实现）

service默认只支持4层负载均衡能力，没有7层功能。（可以通过Ingress实现）

# 2.service的类型 #

*  `ClusterIP`：默认值，k8s系统给service自动分配的虚拟IP，只能在集群内部访问。
 *  `NodePort`：将Service通过指定的Node上的端口暴露给外部，访问任意NodeIP:nodePort都将路由到ClusterIP。
 *  `LoadBalancer`：在 NodePort 的基础上，借助 cloud provider 创建一个外部的负载均衡器，并将请求转发到:NodePort，此模式只能在云服务器上使用。
 *  `ExternalName`：将服务通过 DNS CNAME 记录方式转发到指定的域名（通过 spec.externlName 设定）。

## 2.1VIP和Service代理 ##

在Kubernetes集群中，每个Node运行一个kube-proxy进程。kube-proxy负责为Service实现了一种VIP（虚拟IP）的形式，而不是ExternalName的形式。在Kubernetes v1.0版本，代理完全在userspace。在Kubernetes v1.1版本，新增了iptables代理，但并不是默认的运行模式。从Kubernetes v1.2起，默认就是iptables代理。

在Kubernetes v1.0版本，Service是“4层”（TCP/UDP over IP）概念。在Kubernetes v1.1版本，新增了 Ingress API（beta版），用来表示“7层”（HTTP）服务。

## 2.2没有selector的Service ##

Service抽象了该如何访问Kubernetes Pod，但也能抽象其他类型的backend，例如：

*  希望在生产环境中使用外部的数据库集群，但测试环境使用自己的数据库。
 *  希望服务指向另一个Namespace中或其他集群中的服务。
 *  正在将工作负载转移到Kubernetes集群，和运行在Kubernetes集群之外的backend。

在任何这些场景中，都能够定义没有selector 的 Service ：

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

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

kind: Endpoints
    apiVersion: v1
    metadata:
      name: my-service
    subsets:
      - addresses:
          - ip: 1.2.3.4
        ports:
          - 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-service
      namespace: prod
    spec:
      type: ExternalName
      externalName: my.database.example.com

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

# 3. service的三种工作模式 #

#### 第一种: 是Userspace方式 ####

这种模式，`kube-proxy`会监视Kubernetes master对service对象和Endpoints对象的添加和移除。对每个Service，它会在本地Node上打开一个端口（随机选择）。任何连接到“代理端口”的请求，都会被代理到Service的backend Pods中的某一个上面。使用哪个backend Pod，是基于Service的SessionAffinity来确定的。最后，它安装iptables规则，捕获到达该Service的clusterIP（是虚拟IP）和Port的请求，并重定向到代理端口，代理端口再代理请求到backend Pod。

网络返回的结果是，任何到达Service的IP：Port的请求，都会被代理到一个合适的backend，不需要客户端知道关于Kubernetes，service或pod的任何信息。

默认的策略是，通过`round-robin算法`来选择backend Pod。实现基于客户端IP的会话亲和性，可以通过设置service.spec.sessionAffinity的值为“ClientIP”（默认值为“None”）；  
　  
　　如下图描述,  
　　![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70]Client Pod要访问Server Pod时,它先将请求发给本机内核空间中的service规则，由它再将请求,  
　　转给监听在指定套接字上的kube-proxy，kube-proxy处理完请求，并分发请求到指定Server Pod后,再将请求  
　　递交给内核空间中的service,由service将请求转给指定的Server Pod。  
　　由于其需要来回在用户空间和内核空间交互通信，因此效率很差，接着就有了第二种方式.

#### 第二种: iptables模型 ####

此工作方式是直接由`内核中的iptables规则`，接受Client Pod的请求，并处理完成后，直接转发给指定ServerPod.

这种模式，kube-proxy会监视Kubernetes master对象和Endpoinnts对象的添加和移除。对每个Service，它会安装iptables规则，从而捕获到达该Service的clusterIP（虚拟IP）和端口的请求，进而将请求重定向到Service的一组backend中某个上面。对于每个Endpoints对象，它也会安装iptables规则，这个规则会选择一个backend Pod。

默认的策略是，随机选择一个backend。实现基于客户端IP的会话亲和性，可以将service.spec.sessionAffinity的值设置为“ClientIP”（默认值为“None”）

和userspace代理类似，网络返回的结果是，任何到达Service的IP：Port的请求，都会被代理到一个合适的backend，不需要客户端知道关于Kubernetes，service或Pod的任何信息。这应该比userspace代理更快，更可靠。然而，不想userspace代理，如果始出选择的Pod没有响应，iptables代理不能自动地重试另一个Pod，所以它需要依赖readiness probes；  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 1]

#### 第三种: ipvs模型 ####

它是直接有内核中的`ipvs规则`来接受Client Pod请求，并处理该请求,再有内核封包后，直接发给指定的Server Pod。

这种模式，kube-proxy会监视Kubernetes service对象和Endpoints，调用netlink接口以相应地创建ipvs规则并定期与Kubernetes service对象和Endpoints对象同步ipvs规则，以确保ipvs状态与期望一致。访问服务时，流量将被重定向到其中一个后端Pod。

与iptables类似，ipvs基于netfilter的hook功能，但使用哈希表作为底层数据结构并在内核空间中工作。这意味着ipvs可以更快地重定向流量，并且在同步代理规则时具有更好的性能。此外，ipvs为负载均衡算法提供了更多的选项，例如：

*  rr：轮询调度
 *  lc：最小连接数
 *  dh：目标哈希
 *  sh：源哈希
 *  sed：最短期望延迟
 *  nq： 不排队调度

注意： ipvs模式假定在运行kube-proxy之前在节点上都已经安装了`IPVS内核模块`。当kube-proxy以ipvs代理模式启动时，kube-proxy将验证节点上是否安装了IPVS模块，如果未安装，则kube-proxy将回退到iptables代理模式。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 2]![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 3]注:  
　　`以上不论哪种，kube-proxy都通过watch的方式监控着kube-APIServer写入etcd中关于Pod的最新状态信息,`  
　　`它一旦检查到一个Pod资源被删除了 或 新建，它将立即将这些变化，反应在iptables 或 ipvs规则中，以便iptables和ipvs在调度Clinet Pod请求到Server Pod时，不会出现Server Pod不存在的情况。`

自k8s1.1以后,service默认使用ipvs规则，若ipvs没有被激活，则降级使用iptables规则. 但在1.1以前，service  
　使用的模式默认为userspace.

Service 是由 kube-proxy 组件，加上 iptables 来共同实现的.

kube-proxy 通过 iptables 处理 Service 的过程，需要在宿主机上设置相当多的 iptables 规则，如果宿主机有大量的Pod，不断刷新iptables规则，会消耗大量的CPU资源。

# 4. service的四种类型 #

**1. ExternalName:**  
　  
　用于将集群外部的服务引入到集群内部，在集群内部可直接访问来获取服务。它的值必须是 `FQDN`, 此`FQDN`为集群内部的`FQDN`, 即: ServiceName.Namespace.Domain.LTD.然后CoreDNS接受到该FQDN后，能解析出一个CNAME记录, 该别名记录为真正互联网上的域名.如: www.test.com, 接着CoreDNS在向互联网上的根域DNS解析该域名，获得其真实互联网IP.

**2. ClusterIP：**

用于为集群内Pod访问时,提供的固定访问地址,默认是自动分配地址,可使用ClusterIP关键字指定固定IP.

**3. NodePort:**

用于为集群外部访问Service后面Pod提供访问接入端口.  
这种类型的service工作流程为:

Client----->NodeIP:NodePort----->ClusterIP:ServicePort----->PodIP:ContainerPort

**4. LoadBalancer**

用于当K8s运行在一个云环境内时,若该云环境支持LBaaS,则此类型可自动触发创建一个`软件负载均衡器` ,`用于对Service做负载均衡调度`.  
因为外部所有Client都访问一个NodeIP,该节点的压力将会很大, 而LoadBalancer则可解决这个问题。而且它还直接动态监测后端Node是否被移除或新增了，然后动态更新调度的节点数。

# 5.Service如何实现？ #

Service 是由 kube-proxy 组件，加上 iptables 来共同实现的.

IPVS模式的service，可以使K8s集群支持更多量级的Pod。

实验环境：

<table> 
 <thead> 
  <tr> 
   <th>主机名（IP）</th> 
   <th>服务</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>ser1(172.25.2.4)</td> 
   <td>harbor仓库</td> 
  </tr> 
  <tr> 
   <td>ser2(172.25.2.1)</td> 
   <td>master</td> 
  </tr> 
  <tr> 
   <td>ser3(172.25.2.2)</td> 
   <td>node1</td> 
  </tr> 
  <tr> 
   <td>ser4(172.25.2.3)</td> 
   <td>node2</td> 
  </tr> 
 </tbody> 
</table>

关闭上述主机的防火墙，selinux，设置每台主机可以上网

## 集群内部访问pod ##

vim deployment.yaml 
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: nginx-deployment
      labels:
        app: nginx
    spec:
      replicas: 2
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
          - name: nginx
            image: myapp:v1
            ports:
            - containerPort: 80
    
    kubectl apply -f deployment.yaml 
    
    kubectl get pod -o wide
    kubectl get svc 
    kubectl describe svc myservice

运行一个容器，访问后端的两个pod：

kubectl run test -it --image=busyboxplus
    curl 10.244.3.12
    curl 10.244.1.15

可以访问，这是因为在创建集群时就创建了一个覆盖型的网络  
那么如果我们想要外部主机来访问pod呢？此时我们就可以通过创建service使外部主机访问

## 5.1创建service：（ClusterIP方式） ##

apiVersion: v1
    kind: Service
    metadata:
      name: web-service
    spec:
      ports:
        - name: http
          port: 80
          targetPort: 80
      selector:
          app: nginx
      type: ClusterIP

![在这里插入图片描述][20200516084733175.png]![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 4]目前该web-service还没有后端 Endpoints

创建两个后端的pod

标签必须和web-service的保持一致 app: nginx

apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: deployment-nginx
    spec:
      replicas: 2
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
          - name: nginx
            image: reg.westos.org/k8s/myapp:v1
            ports:
            - containerPort: 80

[kubeadm@server1 manifest]$ vim de.yaml 
    [kubeadm@server1 manifest]$ kubectl apply -f de.yaml 
    deployment.apps/deployment-nginx created
    [kubeadm@server1 manifest]$ kubectl get pod
    NAME                                READY   STATUS    RESTARTS   AGE
    deployment-nginx-84f7d65dcf-5bf9q   1/1     Running   0          6s
    deployment-nginx-84f7d65dcf-qjknh   1/1     Running   0          6s
    test                                1/1     Running   1          3m42s
    [kubeadm@server1 manifest]$

此时，我们的web-service有了两个后端  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 5]![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 6]pod间内部通过访问ClusterIP分配的虚拟VIP负载到了后端的两个pod容器

ClusterIP：通过集群的内部 IP 暴露服务，选择该值，服务**只能够在集群内部**可以访问，这也是默认的 ServiceType

## 5.2.Headless Service “无头服务” ##

Headless Service不需要分配一个VIP，而是直接以DNS记录的方式解析出被代理Pod的IP地址。

域名格式：$(servicename).$(namespace).svc.cluster.local

无头服务，不分配ip地址，使用域名

apiVersion: v1
    kind: Service
    metadata:
      name: nginx-svc
    spec:
      ports:
        - name: http
          port: 80
          targetPort: 80
      selector:
          app: nginx
      clusterIP: None

以DNS记录的方式解析出被代理Pod的IP地址：  
使用域名访问：

kubectl apply -f headless.yaml
    kubectl get svc
    kubectl describe svc nginx-svc 
    kubectl attch test -it
    nslookup nginx-svc

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 7]![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 8]以DNS记录的方式解析出被代理Pod的IP地址。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 9]通过这种方式实现访问，即使在后端pod滚动更新之后依然可以通过DNS进行解 析

Kubernetes 提供了一个 DNS 插件 Service。

kubectl get services kube-dns --namespace=kube-system

![在这里插入图片描述][20200516085511915.png]使用dig解析：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 10]Pod滚动更新后，依然可以解析：

kubectl delete pod --all
    pod "deployment-nginx-58f549b56d-4qswl" deleted
    pod "deployment-nginx-58f549b56d-7sz7c" deleted
    pod "deployment-nginx-58f549b56d-gwswr" deleted
    
    $ dig -t A nginx-svc.default.svc.cluster.local @10.96.0.10
    ...
    ;; QUESTION SECTION:
    ;nginx-svc.default.svc.cluster.local. IN	A
    
    ;; ANSWER SECTION:
    nginx-svc.default.svc.cluster.local. 30	IN A	10.244.2.111
    nginx-svc.default.svc.cluster.local. 30	IN A	10.244.1.120
    nginx-svc.default.svc.cluster.local. 30	IN A	10.244.0.61

## 5.3将service的工作模式改为lvs(ipvs) ##

iptables -t nat -nL | grep 10.224.2.26

我们可以看到这些策略，是在service创建时增加的

当pod创建的越来越多时，iptables的刷新频率就会越来越大，刷新策略会对cpu造成一定的压力，我们可以使用lvs来实现pod的负载均衡，直接使用linux内核

在所有节点安装ipvsadm(master+node)：  
当前没有任何策略  
![在这里插入图片描述][20200516090509547.png]

yum install -y ipvsadm
    ipvsadm -l	#没有任何策略

将模式改为ipvs模式：

kubectl -n kube-system get cm
    kubectl -n kube-system edit cm kube-proxy

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 11]  
删除原来的 kube-system pod，更新kube-proxy pod：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 12]发现又重新新建了三个kube-system 的pod  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 13]  
除了手动删除更新，也可以使用命令：

kubectl get pod -n kube-system |grep kube-proxy | awk '{system("kubectl delete pod "$1" -n kube-system")}'
    ipvsadm -ln

在每个节点上发现,lvs的策略自动出现  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 14]![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 15]创建一个pod，内部访问web-service的虚拟VIP实现了对pod的负载  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 16]

# 6.Flannel vxlan模式跨主机通信原理 #

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 17]在每个node节点上发现kube-ipvs0的接口，只要创建一个service，就会加一个，10.100.84.9就是server2上创建的service的VIP地址

且三个节点相同  
![在这里插入图片描述][20200516091244654.png]  
2个container需要跨主机通信  
那么，server2和server3两个node是如何实现跨主机通信的呢？

![在这里插入图片描述][20200516091348527.png]**cni0容器网络接口（k8s）和docker0差不多**

**vxlan模式跨主机通信过程：**

*  通过ip addr命令查看到容器在物理机上的veth卡。
 *  因为这里使用了cni接口标准，这个veth卡会桥接在cni0的网桥上。这个我们可以通过brctl show进行查看
 *  数据包走到了cni0的网桥后，根据已知的目标ip，10.244.2.6，可以查找路由表，根据路由和掩码，选择对应的iface，也就是flannel.1。且下一跳，也就是10.244.2.0。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 18]进入到flannel.1如何知道应该发向哪个物理机呢。这个时候，其实是通过`arp`来获取。可以通过arp命令查看到对应的mac地址。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 19]这个mac地址在vxlan中，可以通过bridge fdb show来进行查看。可以看到，如果是发向ae:39:2b:5e:b1:d0 的地址，则目标机器在172.25.254.3机器上。则数据就会流转到172.25.254.3上了。经过vxlan封包后的数据包就会经过eth0设备发向到172.25.254.3上。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 20]在172.25.254.3上，首先经过了iptables链，而后在flannel.1的Iface上则接收到该数据包。这里我们可以看到，flannel.1的mac地址就是ae:39:2b:5e:b1:d0。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 21]到达flannel.1后，根据路由表，查看10.244.2.6的路由应送到server3的cni0的网桥上。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 22]这里我们查看cni0的网桥信息。  
    ![在这里插入图片描述][20200516092022727.png]到达网桥后，就可以根据地址将数据送到10.244.2.26的对应的veth上，进而在容器中收到对应的数据包了。

以上就是两个处于不同物理机上的容器间发送数据包的流程。相比较来说，从容器到物理机的ping就简单多了。这个流程就是`veth->cni0->eth0->对端物理机ip`。这里就不详细叙述了。

同一台物理机上不同容器的ping只需要经过cni0的网桥就可以了。

# 7.NodePort方式 #

[kubeadm@server1 manifest]$ kubectl edit svc web-service 
    service/web-service edited
    [kubeadm@server1 manifest]$

![在这里插入图片描述][2020051609353031.png]  
![在这里插入图片描述][2020051609354859.png]通过主机ip+端口访问：  
![在这里插入图片描述][20200516093557843.png]外部主机访问：  
![在这里插入图片描述][20200516093632317.png]

# 8. ExternalName方式 #

从外部访问的第三种方式叫做ExternalName。

ExternalName的模式，从外部访问的方式，用于让pod去访问集群外部的资源，它本身没有绑定任何的资源。

apiVersion: v1
    kind: Service
    metadata:
      name: my-service
    spec:
      type:  ExternalName
      externalName: www.baidu.com

用于让pod去访问集群外部的资源  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 23]并没有分配ip，只是通过CNAME的方式，添加了一条记录。  
pod内部可以正常访问  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 24]![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 25]此时，集群内部访问到了外部域名：www.baidu.com

当更改外部资源为www.westos.org时，可以检测到，但集群内部不做任何的修改。  
service允许为其分配一个公有IP。

vim ex-service.yaml 
    apiVersion: v1
    kind: Service
    metadata:
      name: ex-service
    spec:
      selector:
        app: nginx
      ports:
      - name: http
        protocol: TCP
        port: 80
        targetPort: 80
      externalIPs:
      - 172.25.0.100
    
    $ kubectl get svc ex-service 
    NAME         TYPE        CLUSTER-IP     EXTERNAL-IP    PORT(S)   AGE
    ex-service   ClusterIP   10.111.60.13   172.25.0.100   80/TCP    6s

访问公有ip可以访问到集群内部的pod

# 9.LoadBanalce方式 #

从外部访问 Service 的第二种方式，适用于公有云上的 Kubernetes 服务。这时候，你可以指定一个 LoadBalancer 类型的 Service。

vim lb-service.yaml
    apiVersion: v1
    kind: Service
    metadata:
      name: lb-nginx
    spec:
      ports:
        - name: http
          port: 80
          targetPort: 80
      selector:
          app: nginx
      type: LoadBalancer

在service提交后，Kubernetes就会调用 CloudProvider 在公有云上为你创建一个负载均衡服务，并且把被代理的 Pod 的 IP地址配置给负载均衡服务做后端。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70]: /images/20230312/6865fae090e3489683f21d7e2f185f60.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 1]: /images/20230312/faff70c273c840b694169156eff7d790.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20200515115621526.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 3]: /images/20230312/5ee761f502664c14a380477ee5f7b1c8.png
[20200516084733175.png]: https://img-blog.csdnimg.cn/20200516084733175.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 4]: /images/20230312/fb84a836ec564bc594ef60134e305f45.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 5]: https://img-blog.csdnimg.cn/20200516084920373.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 6]: /images/20230312/fcaa668ffc3b4c2a86411158c80b48fe.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 7]: https://img-blog.csdnimg.cn/20200516085308274.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 8]: /images/20230312/f2894720d38f44c2b7fdfe2e9cd1d0f3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 9]: /images/20230312/b3162fddee10487cb22a3d13b0174697.png
[20200516085511915.png]: /images/20230312/e0af4aa7090f4237b26750b028d159c7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 10]: /images/20230312/7b550060b22c49b4a246d4c771d2fcde.png
[20200516090509547.png]: /images/20230312/7b2a1d6b4bf042ee962df952fa9419ed.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 11]: /images/20230312/575f680204864b85be204b5807148d76.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 12]: /images/20230312/f8ea1cdfbdb0473a992a2655a5f20634.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 13]: /images/20230312/fe9fbd7e1f67480d87993d65d599ac67.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 14]: https://img-blog.csdnimg.cn/20200516090755577.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 15]: /images/20230312/f654a95582ad475fb1ab01a5622eff42.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 16]: /images/20230312/f143276199e740feabd845de37e04085.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 17]: /images/20230312/44e9cc2e07c64055be9e897135fc87ee.png
[20200516091244654.png]: /images/20230312/7a24ff4274c84c06ac69493a4cc4d63f.png
[20200516091348527.png]: /images/20230312/15e9a10f65154883ac6e6ef555ce1e48.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 18]: /images/20230312/5f556a7da48141ad976212a8ccfedf4d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 19]: /images/20230312/07d32eebc9664b9a97b0167eb1239614.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 20]: /images/20230312/256d86be9c064734a366d9e92a56e30b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 21]: /images/20230312/b6fdba01e08c4cc794c5c6bbed1f4943.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 22]: /images/20230312/f70f6c63d7744ae6b9bacc17327f2735.png
[20200516092022727.png]: /images/20230312/0d4e07c8c10b4a63867249d7b2356cb8.png
[2020051609353031.png]: /images/20230312/ad2a7db3a0d44a18820777e1e9c0bb03.png
[2020051609354859.png]: /images/20230312/c08d182d6fa14b84a9071fd4ba150f6c.png
[20200516093557843.png]: /images/20230312/43343204d63540e6922ef3b8259f7cf0.png
[20200516093632317.png]: /images/20230312/ec5891a3ab5d48119ca1d8fb9b876709.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 23]: /images/20230312/886cd05a2b28404f9c1dca73eb057328.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 24]: https://img-blog.csdnimg.cn/20200516095153970.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNjk2OQ_size_16_color_FFFFFF_t_70 25]: /images/20230312/fae95b056a194e2f903542ae5b1d306f.png