【kubernetes系列】Kubernetes之service

本章节将分享一下关于kubernetes中service的相关知识。

一、service

概述

Service也是Kubernetes里的最核心的资源对象之一,正是因为对此概念的支持,Kubernetes在某种角度下可以被看成是一种微服务平台。由于Kubernetes中的pod并不稳定,比如由ReplicaSet、Deployment、DaemonSet等副本控制器创建的pod,其副本数量、pod名称、pod所运行的节点、pod的IP地址等,会随着集群规模、节点状态、用户缩放等因素动态变化。Service是一组逻辑pod的抽象,为一组pod提供统一入口,用户只需与service打交道,service提供DNS解析名称,负责追踪pod动态变化并更新转发表,通过负载均衡算法最终将流量转发到后端的pod。下图显示了Pod、RC与Service的逻辑关系。
【kubernetes系列】Kubernetes之service_第1张图片
从图中我们看到,Kubernetes的Service定义了一个服务的访问入口地址,前端的应用(fronted Pod)通过这个入口地址访问其背后的一组由Pod副本组成的集群实例,Service与其后端Pod副本集群之间则是通过Label Selector来实现“无缝对接”的。而RC的作用实际上是保证Service的服务能力和服务质量始终处于预期的标准。

运行在每个Node上的kube-proxy进程相当于就是一个智能的软件负载均衡器,它负责把对Service的请求转发到后端的某个Pod实例上,并在内部实现服务的负载均衡与会话机制。但Kubernetes发明了一种很巧妙又影响深远的设计:Service不是共用一个负载均衡的IP地址,而是每个Service分配了全局唯一的虚拟IP地址,这个虚拟IP地址被称为Cluster IP。这样一来,每个服务就变成了具备唯一IP地址的“通信节点”,服务调用就变成了最基础的TCP网络通信问题。

并且每个节点上的kube-proxy 这个组件始终监视着apiserver中有关service的变动信息,获取任何一个与service资源相关的变动状态,通过watch监视,一旦有service资源相关的变动和创建,kube-proxy都要转换为当前节点上的能够实现资源调度规则(例如:iptables、ipvs)。我们知道,Pod的Endpoint地址会随着Pod的销毁和重新创建而发生改变,因为新Pod的IP地址与之前旧Pod的不同,相应的变化信息会立即反映到apiserver上,而kube-proxy一定可以watch到etcd中的信息变化,而将它立即转为ipvs或者iptables中的规则,这一切都是动态和实时的,删除一个pod也是同样的原理。而Service一旦被创建,Kubernetes就会自动为它分配一个可用的Cluster IP,而且在Service的整个生命周期内。它的Cluster IP不会发生改变。于是,服务发现这个棘手的问题在Kubernetes的架构里也得到轻松解决:只要用Service的Name与Service的Cluster IP地址做一个DNS域名映射即可完美解决问题。

kube-proxy的工作模式

kube-proxy有以下三种工作模式:
userspace 代理模式,早期使用,效率低,不作比较。
iptables 代理模式
ipvs 代理模式

ipvs vs iptables

我们知道kube-proxy支持 iptables 和 ipvs 两种模式, 在kubernetes v1.8 中引入了 ipvs 模式,在 v1.9 中处于 beta 阶段,在 v1.11 中已经正式可用了。iptables 模式在 v1.1 中就添加支持了,从 v1.2 版本开始 iptables 就是 kube-proxy 默认的操作模式,ipvs 和 iptables 都是基于netfilter的,那么 ipvs 模式和 iptables 模式之间有哪些差异呢?

  • ipvs 为大型集群提供了更好的可扩展性和性能
  • pvs 支持比 iptables 更复杂的负载均衡算法(最小负载、最少连接、加权等等)
  • ipvs 支持服务器健康检查和连接重试等功能

ipvs 依赖 iptables

ipvs 会使用 iptables 进行包过滤、SNAT、masquared(伪装)。具体来说,ipvs 将使用ipset来存储需要DROP或masquared的流量的源或目标地址,以确保 iptables 规则的数量是恒定的,这样我们就不需要关心我们有多少服务了

service示例

下面我们动手创建一个Service,来帮助对它的理解。首先我们创建一个名为nginx-svc.yml 的定义文件,内容如下:

[root@k8s-m1 k8s-total]# cat nginx-svc.yml 
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  ports:
  - port: 80
  selector:
    tier: frontend

##上述内容定义了一个名为“nginx-service”的Service,它的服务端口为80,拥有“tier-frontend”这个Label的所有Pod实例都属于它,运行下面的命令进行创建:

[root@k8s-m1 k8s-total]# kubectl apply    -f nginx-svc.yml 
service/nginx-service created

创建pod

[root@k8s-m1 k8s-total]# cat nginx-deployment.yml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
  labels:
    app: nginx
spec:
  selector:
    matchLabels:
      tier: frontend
  replicas: 1
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
        - name: nginx-gateway
          image: nginx
          resources:
            requests:
              cpu: 100m
              memory: 100Mi
          ports:
            - containerPort: 80
[root@k8s-m1 k8s-total]# kubectl apply    -f nginx-deployment.yml 
deployment.apps/my-nginx created

查看相应的信息

[root@k8s-m1 k8s-total]# kubectl get svc nginx-service 
NAME            TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)   AGE
nginx-service   ClusterIP   10.96.98.35   <none>        80/TCP    3m6s

[root@k8s-m1 k8s-total]# kubectl describe   svc nginx-service 
Name:              nginx-service
Namespace:         default
Labels:            <none>
Annotations:       <none>
Selector:          tier=frontend
Type:              ClusterIP
IP:                10.96.98.35
Port:              <unset>  80/TCP
TargetPort:        80/TCP
Endpoints:         10.244.42.186:80
Session Affinity:  None
Events:            <none>

[root@k8s-m1 k8s-total]# kubectl get pod -o wide
NAME                        READY   STATUS    RESTARTS   AGE     IP              NODE     NOMINATED NODE   READINESS GATES
my-nginx-7ff446c4f4-6ltqm   1/1     Running   0          3m18s   10.244.42.186   k8s-m1   <none>           <none>

[root@k8s-m1 k8s-total]# kubectl get ep
NAME            ENDPOINTS                                                  AGE
nginx-service   10.244.42.186:80                                           6m36s

##通过上面可以看到nginx-service的clusterIP为10.96.98.35,包含的pod的ip为10.244.42.186

注意:
在spec.ports的定义中,targetPort属性用来确定提供该服务的容器所暴露 (EXPOSE–镜像中定义的)的端口号,即具体业务进程在容器内的targetPort上提供TCP/IP接入;而port属性则定义了Service的虚拟端口。前面我们定义nginx服务时,没有指定targetPort,则默认targetPort与port相同。(即serviceport是可以随意定义的,可以不用和targetPort一样,但是不一样的时候,就需要将targetPort指定出来)

工作过程如下 (Endpoint=Pod IP+ContainerPort):

  • 为实例分配集群虚拟IP。如果在声明时明确指定集群虚拟IP,则分配指定IP,如未指定则自动配。
  • 根据实例名称、分配的集群虚拟IP、端口号 创建DNS条目。
  • 根据标签选择器聚合符合条件的节点,并创建相应endpoint,endpoint包含所有符合条件pod的ip地址与端口号。
  • kube-proxy运行在集群中每一个节点上,并持续监控集群中service、endpoint变更,根据监控结果设置转发规则,将一个集群虚拟IP、端口与一个或者多个pod的IP、端口映射起来。
  • 当在集群内部通过服务名称访问创建的service时,首先由内部DNS将服务名称转换成集群虚拟IP与端口号,kube-proxy根据转发规则对service的流量计算负载均衡、转发到位于后端的pod。

在 Service 创建的请求中,可以通过设置 spec.clusterIP 字段来指定自己的集群 IP 地址。比如,希望替换一个已经已存在的 DNS 条目,或者遗留系统已经配置了一个固定的 IP 且很难重新配置。用户选择的 IP 地址必须合法,并且这个 IP 地址在 service-cluster-ip-range CIDR 范围内,这对 API Server 来说是通过一个标识来指定的。如果 IP 地址不合法,API Server 会返回 HTTP 状态码 422,表示值不合法。

无标签选择器service

当需要引入集群外部的服务到集群中使用时,因为集群中没有相关的pod实例,因此这种情况下就不需要标签选择器。有标签选择器时系统自动查询pod并创建相应的endpoint,无标签选择器时需要用户手动创建endpoint。

如引入外部Mysql的服务到集群内部使用:

[root@k8s-m1 k8s-total]# cat endpoint.yml 
kind: Endpoints
apiVersion: v1
metadata:
  name: mysql-production
subsets:
  - addresses:
      - ip: 192.168.2.142
    ports:
      - port: 3306
---
apiVersion: v1
kind: Service
metadata:
  name: mysql-production
spec:
  ports:
    - port: 3306

#创建
[root@k8s-m1 k8s-total]# kubectl apply  -f endpoint.yml 
endpoints/mysql-production created
service/mysql-production created

#查看
[root@k8s-m1 k8s-total]# kubectl get svc mysql-production 
NAME               TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
mysql-production   ClusterIP   10.99.22.164   <none>        3306/TCP   56s

[root@k8s-m1 k8s-total]# kubectl get ep mysql-production 
NAME               ENDPOINTS            AGE
mysql-production   192.168.2.142:3306   58s

[root@k8s-m1 k8s-total]# kubectl describe  svc mysql-production 
Name:              mysql-production
Namespace:         default
Labels:            <none>
Annotations:       <none>
Selector:          <none>
Type:              ClusterIP
IP:                10.99.22.164
Port:              <unset>  3306/TCP
TargetPort:        3306/TCP
Endpoints:         192.168.2.142:3306
Session Affinity:  None
Events:            <none>

通过上面的配置,集群中就可以通过mysql-production这个服务名调用外部mysql。如果mysql地址发生变化,更新相应的endpoint即可。

注意:Endpoint IP 地址不能是 loopback(127.0.0.0/8)、 link-local(169.254.0.0/16)、或者 link-local 多播(224.0.0.0/24)。
注意:除需要手动创建endpoint外,无标签选择器与有标签选择器的servcie工作过程完全相同。请求将被路由到用户定义的 Endpoint(该示例中为 192.168.2.142:3306)

Service多端口问题

很多服务都存在多个端口的问题,通常一个端口提供业务服务,另外一个端口提供管理服务,比如Mycat、Codis等常见中间件。Kubernetes Service支持多个Endpoint,在存在多个Endpoint的情况下,要求每个Endpoint定义一个名字区分。下面是Tomcat多端口的Service定义样例:

apiVersion: v1
kind: Service
metadata:
  name: tomcat-service
spec:
  ports:
  - port: 8080
   name: service-port
  - port: 8005
   name: shutdown-port
  selector:
    tier: frontend

多端口为什么需要給每个端口命名呢?这就涉及Kubernetes的服务发现机制了,我们接下来进行讲解。

Kubernetes的服务发现机制

kubernetes 提供了 service 的概念可以通过 VIP 访问 pod 提供的服务,但是在使用的时候还有一个问题:怎么知道某个应用的 VIP?比如我们有两个应用,一个 app,一个 是 db,每个应用使用RC(控制器)进行管理,并通过 service 暴露出端口提供服务。app 需要连接到 db 应用,我们只知道 db 应用的名称,但是并不知道它的 VIP 地址。

环境变量方式

最早时Kubernetes采用了Linux环境变量的方式解决这个问题,即每个Service生成一些对应的Linux环境变量(ENV),并在每个Pod的容器在启动时,自动注入这些环境变量。
不同服务的环境变量用名称区分,例如:
{SVCNAME}_SERVICE_HOST and {SVCNAME}_SERVICE_PORT
如果服务有多个端口则端口的环境变量名称为 {SVCNAME}SERVICE{PORTNAME}_PORT。
以下是tomcat-service产生的环境变量条目,进入Tomcat的容器,使用env命令可以看到类似下面的变量:
TOMCAT_SERVICE_SERVICE_HOST= 10.96.98.35
TOMCAT_SERVICE_SERVICE_PORT_SERVICE_PORT=8080
TOMCAT_SERVICE_SERVICE_PORT_SHUTDOWN_PORT=8005
TOMCAT_SERVICE_SERVICE_PORT=8080
TOMCAT_SERVICE_PORT=tcp://10.244.56.3:8080
TOMCAT_SERVICE_PORT_8080_TCP_ADDR=10.244.56.3
TOMCAT_SERVICE_PORT_8080_TCP=tcp://10.244.56.3:8080
TOMCAT_SERVICE_PORT_8080_TCP_PROTO=tcp
TOMCAT_SERVICE_PORT_8080_TCP_PORT=8080
TOMCAT_SERVICE_PORT_8005_TCP=tcp://10.244.56.3:8005
TOMCAT_SERVICE_PORT_8005_TCP_ADDR=10.244.56.3
TOMCAT_SERVICE_PORT_8005_TCP_PROTO=tcp
TOMCAT_SERVICE_PORT_8005_TCP_PORT=8005

DNS方式:

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

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

Kubernetes 也支持对端口名称的 DNS SRV(Service)记录。 如果名称为 “nginx-service.default” 的 Service 有一个名为 “http” 的 TCP 端口,可以对 “_http._tcp.nginx-service.default” 执行 DNS SRV 查询,得到 “http” 的端口号。

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

Headless Service(无头服务):

在定义service时,如果.spec.clusterIP被指定为固定值则为服务分配指定的IP,如果.spec.clusterIP字段没有出现在配置中,则自动分配集群虚拟IP。但如果.spect.clusterIP的值被指定为”None”,此时创建的服务就被称为无头服务,其行为与普通服务有很大区别。首先不为服务分配集群虚拟IP,自然也就不能在DNS插件中添加服务相关条目。运行在各节点上的kube-proxy不为其添加转发规则,自然也就无法利用kube-proxy的转发、负载均衡功能。

虽然不向DNS插件添加服务相关条目,但可能添加其它条目,DNS 如何实现自动配置,依赖于 Service 是否定义了 selector。

配置 Selector:
此种情况下,系统仍然根据标签选择器创建endpoint,并根据endpoint向DNS插件中添加条目。比如命名空间为”default”,服务名称为”zk”,endpoing指向的pod名称为zk-1、zk-2,则向DNS插件中添加的条目类似于”zk-1.zk.default”,此时DNS中的条目直接指向pod。在StatefulSet类型资源中,使用无头服务为其中的pod提供名称解析服务,之所以可行,其实是因为StatefulSet能保证其管理的pod有序,名称地址等特征保持不变。

示例如下:

[root@k8s-m1 k8s-total]# cat nginx-svc.yml 
apiVersion: v1
kind: Service
metadata:
  name: nginx-service-headless
spec:
  clusterIP: None
  ports:
  - port: 80
  selector:
    tier: frontend

---
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  ports:
  - port: 80
  selector:
    tier: frontend
    
[root@k8s-m1 k8s-total]# kubectl apply  -f nginx-svc.yml 
service/nginx-service-headless created
service/nginx-service created

不配置 Selector:
对没有定义 selector 的 Headless Service,Endpoint 控制器不会创建 Endpoints 记录。 然而 DNS 系统会查找并配置,无论是:

ExternalName 类型 Service 的 CNAME 记录
记录:与 Service 共享一个名称的任何 Endpoints,以及所有其它类型

[root@k8s-m1 k8s-total]# kubectl get svc
NAME               TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
kubernetes               ClusterIP   10.96.0.1        <none>        443/TCP    410d
nginx-service            ClusterIP   10.111.157.115   <none>        80/TCP     35s
nginx-service-headless   ClusterIP   None             <none>        80/TCP     35s

有ClusterIP Service 的DNS解析如下:

[root@k8s-m1 k8s-total]#  dig -t A nginx-service.default.svc.cluster.local. @10.96.0.10

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.10 <<>> -t A nginx-service.default.svc.cluster.local. @10.96.0.10
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8420
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;nginx-service.default.svc.cluster.local. IN A

;; ANSWER SECTION:
nginx-service.default.svc.cluster.local. 30 IN A 10.111.157.115

;; Query time: 0 msec
;; SERVER: 10.96.0.10#53(10.96.0.10)
;; WHEN: Tue Jun 27 20:46:56 CST 2023
;; MSG SIZE  rcvd: 123

Headless Service的DNS解析如下:

[root@k8s-m1 k8s-total]#  dig -t A nginx-service-headless.default.svc.cluster.local. @10.96.0.10

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.10 <<>> -t A nginx-service-headless.default.svc.cluster.local. @10.96.0.10
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21180
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;nginx-service-headless.default.svc.cluster.local. IN A

;; ANSWER SECTION:
nginx-service-headless.default.svc.cluster.local. 30 IN A 10.244.42.186

;; Query time: 1 msec
;; SERVER: 10.96.0.10#53(10.96.0.10)
;; WHEN: Tue Jun 27 20:47:09 CST 2023
;; MSG SIZE  rcvd: 141

[root@k8s-m1 k8s-total]# kubectl get po -o wide
NAME                        READY   STATUS    RESTARTS   AGE    IP              NODE     NOMINATED NODE   READINESS GATES
my-nginx-7ff446c4f4-6ltqm   1/1     Running   0          5h1m   10.244.42.186   k8s-m1   <none>           <none>

可以发现是ClusterIP Service 的DNS解析在ClusterIP上,而Headless Service 的DNS解析在相应的Pod上,如果有多个Pod,会同时显示出来。

外部系统访问Service的问题

本文以上示例都以默认服务类型为前提,实际上kubernetes暴露服务IP的类型有四种,
service.spec.type允许指定一个需要的类型,默认是 ClusterIP 类型。Type 的取值以及行为如下:

  • ClusterIP:通过集群的内部 IP 暴露服务,选择该值,服务只能够在集群内部可以访问,这也是默认的 ServiceType。
  • NodePort:通过每个 Node 上的 IP 和静态端口(NodePort)暴露服务。NodePort 服务会路由到 ClusterIP 服务,这个 ClusterIP 服务会自动创建。通过请求 :,可以从集群的外部访问一个 NodePort 服务。
  • LoadBalancer:使用云提供商的负载均衡器,可以向外部暴露服务。外部的负载均衡器可以路由到 NodePort 服务和 ClusterIP 服务。(事实上可以通过metalLB 进行模拟LoadBlancer)
  • ExternalName:通过返回 CNAME 和它的值,可以将服务映射到 externalName 字段的内容(例如, foo.bar.example.com)。没有任何类型代理被创建,这只有 Kubernetes 1.7 或更高版本的 kube-dns 才支持。

首先,Node IP是Kubernetes集群中每个节点的物理网卡的IP地址,这是一个真实存在的物理网络,所有属于这个网络的服务器之间都能通过这个网络直接通信,不管它们中是否有部分节点不属于这个Kubernetes集群。这也表明了Kubernetes集群之外的节点访问Kubernetes集群之内的某个节点或者TCP/IP服务时,必须要通过Node IP进行通信。

其次,Pod IP是每个Pod的IP地址,它是Docker Engine根据docker0网桥的IP地址段进行分配的,通常是一个虚拟的二层网络,前面我们说过,Kubernetes里一个Pod里的容器访问另外一个Pod里的容器,就是通过Pod IP所在的虚拟二层网络进行通信的,而真实的TCP/IP流量则是通过Node IP所在的物理网卡流出的。

最后,我们说说Service的Cluster IP,它其实是一个虚拟的IP,原因有以下几点。
Cluster IP仅仅作用于Kubernetes Service这个对象,并由Kubernetes管理和分配IP地址(来源于Cluster IP地址池)。
Cluster IP无法被Ping,因为没有一个“实体网络对象”来响应。(实际使用中使用Flannel网络模式的Cluster IP无法被Ping,而使用calico网络模式的可以被Ping)
Cluster IP只能结合Service Port组成一个具体的通信端口,单独的Cluster IP不具备TCP/IP通信的基础,并且它们属于Kubernetes集群这样一个封闭的空间,集群之外的节点如果要访问这个通信端口,则需要做一些额外的工作。
在Kubernetes集群之内,Node IP网、Pod IP网与Clsuter IP之间的通信,采用的是Kubernetes自己设计的一种编程方式的特殊的路由规则,与我们所熟知的IP路由有很大的不同。
根据上面的分析和总结,我们基本明白了:Service的Cluster IP属于Kubernetes集群内部的地址,无法在集群外部直接使用这个地址。那么矛盾来了:实际上我们开发的业务系统中肯定多少由一部分服务是要提供給Kubernetes集群外部的应用或者用户来使用的,典型的例子就是Web端的服务模块,比如上面的tomcat-service,那么用户怎么访问它?

采用NodePort是解决上述问题的最直接、最常用的做法。具体做法如下,以nginx-service为例,我们在Service的定义里做如下修改,改变了service的类型并固定了nodeport的端口:

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  type: NodePort
  ports:
  - port: 80
    nodePort: 30080
  selector:
    tier: frontend

其中,nodePort:30080这个属性表明我们手动指定nginx-service的NodePort为30080,否则Kubernetes会自动分配一个可用的端口。接下来,我们在浏览器里访问http://nodeIP:30080,就可以看到nginx的欢迎界面了,如图所示。【kubernetes系列】Kubernetes之service_第2张图片

通过NodePort访问Service
NodePort的实现方式是在Kubernetes集群里的每个Node上为需要外部访问的Service开启一个对应的TCP监听端口,外部系统只要用任意一个Node的IP地址+具体的NodePort端口号即可访问此服务,在任意Node上运行netstat命令,我们就可以看到有NodePort端口被监听:

[root@k8s-m1 k8s-total]# netstat -anp|grep 30080
tcp        0      0 0.0.0.0:30080           0.0.0.0:*               LISTEN      30105/kube-proxy

但NodePort还没有完全解决外部访问Service的所有问题,比如负载均衡问题,假如我们的集群中有10个Node,则此时最好有一个负载均衡器,外部的请求只需要访问此负载均衡器的IP地址,由负载均衡负责转发流量到后面某个Node的NodePort上。实际使用中,

externalIPs

注意事项:对于使用了externalIPs的Service,当开启IPVS后,externalIP也会作为VIP被ipvs接管,因此如果在externalIp指定的Kubernetes集群中Node节点的IP,需将externalIp替换成预先规划好的VIP(在同一网段找一个未被使用的IP),否则会出现VIP和Node节点IP冲突的问题。使用命令行将VIP绑定到物理网卡上eth0(ens***)网口,而不是绑定到kube-ipvs0网口

[root@k8s-m1 k8s-total]# ip addr add 192.168.2.250/24 brd 192.168.2.255 dev ens32
[root@k8s-m1 k8s-total]# cat externalip-svc.yml
kind: Service
apiVersion: v1
metadata:
  name: nginx-externalip
spec:
  selector:
    tier: frontend
  ports:
  - name: http
    port: 80
  externalIPs:
    - 192.168.2.250

[root@k8s-m1 k8s-total]# kubectl apply  -f externalip-svc.yml
service/nginx-externalip created

#查看
[root@k8s-m1 k8s-total]# kubectl get svc
NAME                     TYPE        CLUSTER-IP       EXTERNAL-IP     PORT(S)        AGE
kubernetes               ClusterIP   10.96.0.1        <none>          443/TCP        410d
nginx-externalip         ClusterIP   10.97.49.32      192.168.2.250   80/TCP         5s
nginx-service            NodePort    10.111.157.115   <none>          80:30080/TCP   32m
nginx-service-headless   ClusterIP   None             <none>          80/TCP         32m

更多关于kubernetes的知识分享,请前往博客主页。编写过程中,难免出现差错,敬请指出

你可能感兴趣的:(Kubernetes,kubernetes,容器)