kubernetes之service

一、了解service

 

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

 

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

 

• service的类型：

 

• ClusterIP：默认值，k8s系统给service自动分配的虚拟IP，只能在集群内部访问。

• NodePort：将Service通过指定的Node上的端口暴露给外部，访问任意一个

NodeIP:nodePort都将路由到ClusterIP。

• LoadBalancer：在 NodePort 的基础上，借助 cloud provider 创建一个外部的负载均

衡器，并将请求转发到 <NodeIP>:NodePort，此模式只能在云服务器上使用。

• ExternalName：将服务通过 DNS CNAME 记录方式转发到指定的域名（通过

spec.externlName 设定）。

 

 

2. Service的三种工作方式:

第一种: 是Userspace方式
　　如下图描述, Client Pod要访问Server Pod时,它先将请求发给本机内核空间中的service规则，由它再将请求,
　　转给监听在指定套接字上的kube-proxy，kube-proxy处理完请求，并分发请求到指定Server Pod后,再将请求
　　递交给内核空间中的service,由service将请求转给指定的Server Pod。
　　由于其需要来回在用户空间和内核空间交互通信，因此效率很差，接着就有了第二种方式.
　第二种: iptables模型
　　此工作方式是直接由内核中的iptables规则，接受Client Pod的请求，并处理完成后，直接转发给指定ServerPod.
　第三种: ipvs模型
　　它是直接有内核中的ipvs规则来接受Client Pod请求，并处理该请求,再有内核封包后，直接发给指定的Server Pod。
 

以上不论哪种，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.

 

IPVS模式的service（ClusterIP）

 

 

 

master主机上安装

 修改 ipvs模式

 

 

使其生效

 

我们输入ip addr 发现多一个接口

 

 

Headless Service 无头服务（ClusterIP）

 

 

 

 

我们有没有考虑一个问题  一个端口对应一个服务 万一不够分怎么办  以下方法可以解决

nodeport 范围是30000————32767

我们把nodeport修改为33333   我们运行会有什么情况？

我们根据下图发现如果范围超过根本就运行不了

 

 

修改文件把范围变大

 

 

再次启动svc2.yaml  发现启动成功 端口33333

 

 

 

从外部暴露（LoadBalancer）