目录
一、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.yml
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: myapp
name: myapp
spec:
replicas: 6
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
containers:
- image: myapp:v1
name: myapp
---
apiVersion: v1
kind: Service
metadata:
labels:
app: myapp
name: myapp
spec:
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
app: myapp
type: 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.yml
apiVersion: v1
kind: Service
metadata:
labels:
app: myapp
name: myapp
spec:
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
app: myapp
type: ClusterIP
clusterIP: 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 --rm
nslookup myapp
**四、**NodePort
1.NodePort
NodePort类型的Service会在每个Node上打开一个端口，用于将请求转发到Pod。
nodePort是Service类型的一个字段，用于指定转发请求的端口范围。默认情况下，该值是随机分配的。
以下是创建一个NodePort类型的Service的yaml示例：
vim myapp.yml
apiVersion: v1
kind: Service
metadata:
labels:
app: myapp
name: myapp
spec:
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
app: myapp
type: NodePort
nodeport在集群节点上绑定端口，一个端口对应一个服务
2.默认端口
NodePort 的默认端口是 30000 到 32767 之间的任意一个端口。可以通过 kubectl get svc 命令查看 NodePort 所绑定的端口。
vim myapp.yml
apiVersion: v1
kind: Service
metadata:
labels:
app: myapp
name: myapp
spec:
ports:
- port: 80
protocol: TCP
targetPort: 80
nodePort: 33333
selector:
app: myapp
type: 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.yml
apiVersion: v1
kind: Service
metadata:
labels:
app: myapp
name: myapp
spec:
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
app: myapp
type: 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.yaml
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
name: first-pool
namespace: metallb-system
spec:
addresses:
- 192.168.67.120-192.168.67.200 #修改为自己本地地址段
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
name: example
namespace: metallb-system
spec:
ipAddressPools:
- first-pool
通过分配地址从集群外访问服务
六、ExternalName
Kubernetes Service 的 ExternalName 类型是一种非常简单的服务类型，它允许 Kubernetes 集群中的服务通过一个 DNS CNAME 来引用一个外部的服务。这个服务可以是集群外的任何服务，比如一个第三方的数据库或者缓存服务器等。
使用 ExternalName 类型的服务，可以方便地将 Kubernetes 集群中的应用程序连接到集群外的服务，同时还可以使用 Kubernetes 的负载均衡和服务发现功能。这样就可以实现将多个服务整合到一个统一的 DNS 域名下管理的目的。
ExternalName 类型的服务定义非常简单，只需要指定服务名称和外部服务的 DNS 名称即可。例如：
vim externalname.yaml
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
type: ExternalName
externalName: www.westos.org'
kubectl apply -f externalname.yaml
dig -t A my-service.default.svc.cluster.local. @10.96.0.10
