目录
一、service微服务
二、Ipvs模式
三、ClusterIP
1.ClusterIP
2.headless
四、NodePort
1.NodePort
2.默认端口
五、LoadBalancer
1.LoadBalancer
2.metallb
六、ExternalName
一、service微服务
Kubernetes Service微服务是一种基于Kubernetes的微服务架构,它通过将服务拆分成多个小服务单元来实现高度可扩展性、弹性和可维护性。每个服务单元都有自己的容器、存储和网络,可以独立部署和升级。同时,Kubernetes Service微服务还可以使用Kubernetes内置的负载均衡器来自动化地分配请求和处理服务故障。总之,Kubernetes Service微服务是一种基于Kubernetes的先进的容器编排和管理技术,它可以提供高效、高可用和高可扩展的微服务体系结构。
二、Ipvs模式
Kubernetes Service的IPVS模式是一种高效的负载均衡方式,它使用Linux内核提供的IPVS(IP Virtual Server)技术来实现。
在IPVS模式下,Kubernetes会在每个节点上创建一个独立的IPVS代理,并将所有服务的虚拟IP地址通过BGP协议广播到物理网络中。这些IP地址随后被路由到相应的节点,并由节点上的IPVS代理进行请求的转发。
IPVS代理可以根据服务的负载均衡策略(如轮询、源IP哈希、最小连接数等)选择合适的后端Pod,并将请求转发到该Pod上。同时,IPVS代理还支持会话保持(Session Affinity)功能,确保来自同一客户端的请求都被转发到同一后端Pod上,以避免数据不一致等问题。
IPVS模式的优势在于它的性能和可扩展性非常好,能够轻松处理大量的网络请求。同时,由于IPVS代理和物理网络之间的解耦,它也具有较好的灵活性和可靠性,能够适应各种不同的网络环境和服务需求。
修改proxy配置:
kubectl -n kube-system edit cm kube-proxy
重启pod
kubectl -n kube-system get pod|grep kube-proxy | awk '{system("kubectl -n kube-system delete pod "$1"")}'
切换ipvs模式后,kube-proxy会在宿主机上添加一个虚拟网卡:kube-ipvs0,并分配service IP
三、ClusterIP
1.ClusterIP
Kubernetes中的Service对象可以用来定义一组Pod的逻辑访问方式,其中ClusterIP是Service的默认类型。ClusterIP会为Pod提供一个虚拟IP地址,这个地址只在Kubernetes集群内部可用,其他外部网络无法访问该地址。
创建测试示例:
vim myapp.ymlapiVersion: apps/v1
kind: Deployment
metadata:labels:app: myappname: myapp
spec:replicas: 6selector:matchLabels:app: myapptemplate:metadata:labels:app: myappspec:containers:- image: myapp:v1name: myapp---apiVersion: v1
kind: Service
metadata:labels:app: myappname: myapp
spec:ports:- port: 80protocol: TCPtargetPort: 80selector:app: myapptype: ClusterIP//ClusterIP是Kubernetes Service的一种类型。它为同一个Kubernetes集群中的其他Pod提供了访问Service的IP地址。这个IP地址和Service是虚拟的, 不对外暴露,只能在集群内部使用。
kubectl apply -f myapp.yml
kubectl get svc
dig -t A myapp.default.svc.cluster.local. @10.96.0.10
service创建后集群DNS提供解析
ClusterIP Service类型默认使用iptables调度。iptables负责将Service的ClusterIP地址映射到后端Pod的IP地址和端口上,处理请求的负载均衡和高可用性
2.headless
Kubernetes Service 的 headless 模式是指 Service 不会自动创建 ClusterIP 代理。在headless 模式下,当 Service 对应的 Pod 通过 DNS 查询时,将返回所有 Pod 的 IP 地址列表,而不是一个单独的 IP 地址。
headless Service 可以用于以下场景:
- 有状态应用程序(StatefulSet):每个 Pod 都需要一个唯一的标识符,例如数据库的名称。
- 多副本应用程序:需要将每个副本的 IP 地址列表返回给客户端来进行负载均衡。
- 集群内部通信:例如,一个应用程序需要直接与另一个应用程序的 Pod 进行通信,而不是 Service 的负载均衡代理。
使用 headless Service 的方法是,在 Service 的 YAML 文件中将 clusterIP
设置为 None
,例如:
vim myapp.ymlapiVersion: v1
kind: Service
metadata:labels:app: myappname: myapp
spec:ports:- port: 80protocol: TCPtargetPort: 80selector:app: myapptype: ClusterIPclusterIP: None
kubectl delete svc myapp
kubectl apply -f myapp.yml
kubectl get svc
headless模式不分配vip
headless通过svc名称访问,由集群内dns提供解析
dig -t A myapp.default.svc.cluster.local. @10.96.0.10
集群内直接使用service名称访问
kubectl run demo --image busyboxplus -it --rmnslookup myapp
四、NodePort
1.NodePort
NodePort类型的Service会在每个Node上打开一个端口,用于将请求转发到Pod。
nodePort是Service类型的一个字段,用于指定转发请求的端口范围。默认情况下,该值是随机分配的。
以下是创建一个NodePort类型的Service的yaml示例:
vim myapp.ymlapiVersion: v1
kind: Service
metadata:labels:app: myappname: myapp
spec:ports:- port: 80protocol: TCPtargetPort: 80selector:app: myapptype: NodePort
nodeport在集群节点上绑定端口,一个端口对应一个服务
2.默认端口
NodePort 的默认端口是 30000 到 32767 之间的任意一个端口。可以通过 kubectl get svc
命令查看 NodePort 所绑定的端口。
vim myapp.ymlapiVersion: v1
kind: Service
metadata:labels:app: myappname: myapp
spec:ports:- port: 80protocol: TCPtargetPort: 80nodePort: 33333selector:app: myapptype: NodePort
nodeport默认端口是30000-32767,超出会报错:
添加如下参数,端口范围可以自定义
- --service-node-port-range=30000-50000
修改后api-server会自动重启,等apiserver正常启动后才能操作集群
五、LoadBalancer
1.LoadBalancer
Kubernetes中的LoadBalancer是一种服务类型,它允许在云环境中创建外部可访问的负载均衡器。在使用LoadBalancer类型的服务时,Kubernetes集群会自动创建云供应商的负载均衡器,并将请求分发到后端Pod中。
LoadBalancer服务类型需要云供应商支持,并且通过自动创建外部负载均衡器来实现。例如,使用AWS的Elastic Load Balancer或GCP的Load Balancer。配置一个LoadBalancer服务需要定义服务的端口和目标端口,以及要使用的负载均衡算法和策略。
使用LoadBalancer服务类型,可以轻松地将Kubernetes中部署的应用程序暴露给外部网络,并在应用程序实例之间分配流量,以便提供高可用性和可扩展性。
vim myapp.ymlapiVersion: v1
kind: Service
metadata:labels:app: myappname: myapp
spec:ports:- port: 80protocol: TCPtargetPort: 80selector:app: myapptype: LoadBalancer
LoadBalancer模式适用云平台,裸金属环境需要安装metallb提供支持
2.metallb
Metallb是一个用于处理Load Balancing的开源软件。在Kubernetes集群中,Service是一个抽象的概念,它为Pod提供了一个统一的入口,使得Pod可以被其他Pod或外部网络访问到。Metallb为Kubernetes Service提供了一个软件定义的Load Balancer,它可以自动分配IP地址,并将流量路由到正确的Pod。
Metallb的核心组件是speaker和controller。controller负责监控Kubernetes Service和Pod的状态,并为每个Service分配一个IP地址。而speaker则会在每个节点上运行,将Service的IP地址配置到节点上的网络接口。
使用Metallb,Kubernetes集群中的Service可以获得一个固定的IP地址,而无需依赖于云厂商的Load Balancer。这样可以提高集群的稳定性和可靠性,并且可以在任何环境下部署Kubernetes集群。
kubectl edit configmap -n kube-system kube-proxy
kubectl -n kube-system get pod|grep kube-proxy | awk '{system("kubectl -n kube-system delete pod "$1"")}'
strictARP: true //启用 Kubernetes Service 的 strictARP 选项可以防止 ARP 欺骗攻击,提高网络安全性
下载部署文件
wget https://raw.githubusercontent.com/metallb/metallb/v0.13.11/config/manifests/metallb-native.yaml
修改文件中镜像地址,与harbor仓库路径保持一致
上传harbor仓库:
部署服务
kubectl apply -f metallb-native.yaml
kubectl -n metallb-system get pod
配置分配地址段
vim config.yamlapiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:name: first-poolnamespace: metallb-system
spec:addresses:- 192.168.67.120-192.168.67.200 #修改为自己本地地址段---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:name: examplenamespace: metallb-system
spec:ipAddressPools:- first-pool
通过分配地址从集群外访问服务
六、ExternalName
Kubernetes Service 的 ExternalName 类型是一种非常简单的服务类型,它允许 Kubernetes 集群中的服务通过一个 DNS CNAME 来引用一个外部的服务。这个服务可以是集群外的任何服务,比如一个第三方的数据库或者缓存服务器等。
使用 ExternalName 类型的服务,可以方便地将 Kubernetes 集群中的应用程序连接到集群外的服务,同时还可以使用 Kubernetes 的负载均衡和服务发现功能。这样就可以实现将多个服务整合到一个统一的 DNS 域名下管理的目的。
ExternalName 类型的服务定义非常简单,只需要指定服务名称和外部服务的 DNS 名称即可。例如:
vim externalname.yamlapiVersion: v1
kind: Service
metadata:name: my-service
spec:type: ExternalNameexternalName: www.westos.org‘kubectl apply -f externalname.yaml
dig -t A my-service.default.svc.cluster.local. @10.96.0.10