用控制器来完成集群的工作负载，那么应用如何暴漏出去？需要通过微服务暴漏出去后才能被访问

Service是一组提供相同服务的Pod对外开放的接口。

借助Service，应用可以实现服务发现和负载均衡。

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

#生成控制器文件并建立控制器
[root@k8s-master ~]# kubectl create deployment timinglee --image myapp:v1  --replicas 2 --dry-run=client -o yaml > timinglee.yaml
#生成微服务yaml追加到已有yaml中
[root@k8s-master ~]# kubectl expose deployment timinglee --port 80 --target-port 80 --dry-run=client -o yaml >> timinglee.yaml

然后编辑文件，用---分隔开

微服务默认使用iptables调度

三 ipvs模式

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

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

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

所以我们一般使用ipvs模式，在各个节点上都下载一下ipvs，然后

kubectl -n kube-system edit cm kube-proxy

修改master节点的代理配置

重启pod，在pod运行时配置文件中采用默认配置，当改变配置文件后已经运行的pod状态不会变化，所以要重启pod

切换ipvs模式后，kube-proxy会在宿主机上添加一个虚拟网卡：kube-ipvs0，并分配所有service IP

四 微服务类型详解

4.1 clusterip

特点：

clusterip模式只能在集群内访问，并对集群内的pod提供健康检测和自动发现功能

4.2 ClusterIP中的特殊模式headless

headless（无头服务）

对于无头 Services 并不会分配 Cluster IP，kube-proxy不会处理它们， 而且平台也不会为它们进行负载均衡和路由，集群访问通过dns解析直接指向到业务pod上的IP，所有的调度有dns单独完成

4.3 nodeport

通过ipvs暴漏端口从而使外部主机通过master节点的对外ip:<port>来访问pod业务

[!NOTE]

nodeport默认端口

nodeport默认端口是30000-32767，超出会报错

4.4 loadbalancer

云平台会为我们分配vip并实现访问，如果是裸金属主机那么需要metallb来实现ip的分配

4.5 metalLB

metalLB功能

为LoadBalancer分配vip

4.6 externalname

• 开启services后，不会被分配IP，而是用dns解析CNAME固定域名来解决ip变化问题

• 一般应用于外部业务和pod沟通或外部业务迁移到pod内时

• 在应用向集群迁移过程中，externalname在过度阶段就可以起作用了。

• 集群外的资源迁移到集群时，在迁移的过程中ip可能会变化，但是域名+dns解析能完美解决此问题