kubernetes-service微服务

目录

一、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