Service

Service将内部的pod暴露到外面，让用户可以访问

负载均衡策略：

Service 的类型：

案例：Service服务发布案例

扩展：我们在案例再加入一个探针的使用

更改后的my_nginx.yaml文件：

创建Pod：

创建Service服务，暴露我们的nginx容器服务

创建Service服务

查看服务Service是否启动

测试访问nginx：

kube-proxy

kube-proxy的主要作用：

kube-proxy存在的3种模式：iptables、ipvs mode、userspace mode

kube-proxy制作了一个负载均衡器，使用iptables实现的（v1.2后）

kube-proxy同样可以使用ipvs mode（v1.8后）

参考文档：基于 IPVS 的集群内部负载均衡 | Kubernetes

基于 IPVS 的集群内部负载均衡：

什么是 IPVS ?

为什么为 Kubernetes 选择 IPVS ?（为什么IPVS 比 iptables更好用）

基于 IPVS 的 Kube-proxy

ipvs的调度算法

IPVS 中有三种代理模式：NAT（masq），IPIP 和 DR。

只有 NAT 模式支持端口映射。 Kube-proxy 利用 NAT 模式进行端口映射。

kube-proxy同样可以使用userspace mode（v1.1，版本比较落后）

Service

Kubernetes 中 Service 是 将运行在一个或一组 Pod 上的网络应用程序公开为网络服务的方法。

Service API 是 Kubernetes 的组成部分，它是一种抽象，帮助你通过网络暴露 Pod 组合。每个 Service 对象定义一个逻辑组的端点（通常这些端点是 Pod）以及如何才能访问这些 Pod 的策略。

Service 在 Kubernetes 中是一个对象（与 Pod 或 ConfigMap 类似的对象）。你可以使用 Kubernetes API 创建、查看或修改 Service 定义。通常你使用 kubectl 这类工具来进行这些 API 调用。

图中的六边形代表着Pod，圆圈代表着容器

Service将内部的pod暴露到外面，让用户可以访问

负载均衡策略：

RoundRobin：轮询模式，即轮询将请求转发到后端的各个pod上（默认模式）；

SessionAffinity：基于客户端IP地址进行会话保持的模式，第一次客户端访问后端某个pod，之后的请求都转发到这个pod上。（跟nginx上的ip-hash算法差不多）

删除service不会删除pod

Service 的类型：

service再暴露服务的时候，有几种类型：

我们主要使用 ClusterIP和NodePort这两种类型

我们也可以通过 kubectl get service来查看其中涉及到的类型

[root@master pod]# kubectl get service
NAME         TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)          AGE
kubernetes   ClusterIP   10.0.0.1      <none>        443/TCP          26h
my-nginx     NodePort    10.6.55.120   <none>        8080:32465/TCP   7h32m
[root@master pod]#

案例：Service服务发布案例

Service服务发布案例：(84条消息) Kubernetes 启动Pod的方法-Pod的调度算法-Pod间的通信-k8s的控制器-Pod资源控制-发布Service服务_Claylpf的博客-CSDN博客

创建完成后，查看是否启动了

[root@master pod]# kubectl get deploy
NAME       READY   UP-TO-DATE   AVAILABLE   AGE
my-nginx   3/3     3            3           8h
[root@master pod]#

扩展：我们在案例再加入一个探针的使用

探针：(84条消息) Kubernatas Pod卷 - Pod镜像的升级和回滚 - 探针_Claylpf的博客-CSDN博客

更改后的my_nginx.yaml文件：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  selector:
    matchLabels:
      run: my-nginx
  replicas: 3
  template:
    metadata:
      labels:
        run: my-nginx
    spec:
      containers:
      - name: my-nginx
        image: nginx
        ports:
        - containerPort: 80
        livenessProbe:
          tcpSocket:
            port: 80
          initialDelaySeconds: 15
          periodSeconds: 20

创建Pod：

[root@master pod]# kubectl apply -f my_nginx.yaml 
deployment.apps/my-nginx configured
[root@master pod]#

创建Service服务，暴露我们的nginx容器服务

apiVersion: v1
kind: Service
metadata:
  name: my-nginx
  labels:
    run: my-nginx
spec:
  type: NodePort
  ports:
    # 默认情况下，为了方便起见，`targetPort` 被设置为与 `port` 字段相同的值。
  - port: 8090
    targetPort: 80
    protocol: TCP
    name: http
  selector:
    run: my-nginx

创建Service服务

[root@master pod]# kubectl apply -f my_service.yaml 
service/my-nginx configured
[root@master pod]#

查看服务Service是否启动

[root@master pod]# kubectl get service
NAME         TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)          AGE
kubernetes   ClusterIP   10.0.0.1      <none>        443/TCP          27h
my-nginx     NodePort    10.6.55.120   <none>        8090:32465/TCP   7h59m
[root@master pod]#

测试访问nginx：

[root@master pod]# kubectl get service -o wide
NAME         TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)          AGE   SELECTOR
kubernetes   ClusterIP   10.0.0.1      <none>        443/TCP          27h   <none>
my-nginx     NodePort    10.6.55.120   <none>        8090:32465/TCP   8h    run=my-nginx
[root@master pod]#

kube-proxy

负责在集群内部的各个节点上实现服务代理和负载均衡。（在service服务里做负载均衡的）

kube-proxy的主要作用：

kube-proxy的主要作用包括以下几个方面：

服务发现：kube-proxy会监视Kubernetes集群中的Service对象的变化，并根据Service的定义创建相应的iptables或IPVS规则来实现服务发现。当有新的Service创建时，kube-proxy会自动更新规则，使得所有访问该Service的流量被正确地路由到后端的Pod实例。

负载均衡：通过为每个Service创建负载均衡规则，kube-proxy能够将请求分发到后端的多个Pod实例上，实现负载均衡。它可以使用轮询（Round Robin）算法或最小连接数（Least Connections）等策略来平衡负载。

代理转发：kube-proxy还负责将来自集群内部和集群外部的请求转发到对应的Service或Pod。当请求需要访问Service时，kube-proxy会将请求转发到Service的Cluster IP；当请求需要访问外部服务时，kube-proxy会将请求转发到外部负载均衡器或代理服务器。

高可用性：kube-proxy支持运行模式为“用户空间模式”和“IPVS模式”。在用户空间模式下，kube-proxy使用自己的实现来处理流量代理和负载均衡，具有广泛的兼容性。而在IPVS模式下，kube-proxy使用Linux内核的IPVS功能来提供更高性能和更灵活的负载均衡选项。

总结来说，kube-proxy是Kubernetes集群中的一个网络代理组件，它为Service对象提供了服务发现、负载均衡和代理转发的功能。它的存在使得Kubernetes集群中的服务可以通过统一的入口进行访问，并能够自动实现负载均衡和故障转移，提高应用程序的可靠性和可伸缩性。

kube-proxy存在的3种模式：iptables、ipvs mode、userspace mode

kube-proxy制作了一个负载均衡器，使用iptables实现的（v1.2后）

查看：

[root@node1 ~]# curl localhost:10249/proxyMode
iptables[root@node1 ~]#

kube-proxy同样可以使用ipvs mode（v1.8后）

参考文档：基于 IPVS 的集群内部负载均衡 | Kubernetes

基于 IPVS 的集群内部负载均衡：

什么是 IPVS ?

IPVS (IP Virtual Server)是在 Netfilter 上层构建的，并作为 Linux 内核的一部分，实现传输层负载均衡。

IPVS 集成在 LVS（Linux Virtual Server，Linux 虚拟服务器）中，它在主机上运行，并在物理服务器集群前作为负载均衡器。IPVS 可以将基于 TCP 和 UDP 服务的请求定向到真实服务器，并使真实服务器的服务在单个IP地址上显示为虚拟服务。因此，IPVS 自然支持 Kubernetes 服务。

为什么为 Kubernetes 选择 IPVS ?（为什么IPVS 比 iptables更好用）

Kube-proxy 是服务路由的构建块，它依赖于经过强化攻击的 iptables 来实现支持核心的服务类型，如 ClusterIP 和 NodePort。 但是，iptables 难以扩展到成千上万的服务，因为它纯粹是为防火墙而设计的，并且基于内核规则列表。

尽管 Kubernetes 在版本v1.6中已经支持5000个节点，但使用 iptables 的 kube-proxy 实际上是将集群扩展到5000个节点的瓶颈。 一个例子是，在5000节点集群中使用 NodePort 服务，如果我们有2000个服务并且每个服务有10个 pod，这将在每个工作节点上至少产生20000个 iptable 记录，这可能使内核非常繁忙。

另一方面，使用基于 IPVS 的集群内服务负载均衡可以为这种情况提供很多帮助。 IPVS 专门用于负载均衡，并使用更高效的数据结构（哈希表），允许几乎无限的规模扩张。

基于 IPVS 的 Kube-proxy

参数更改

参数: --proxy-mode 除了现有的用户空间和 iptables 模式，IPVS 模式通过--proxy-mode = ipvs 进行配置。

ipvs的调度算法

参数: --ipvs-scheduler

添加了一个新的 kube-proxy 参数来指定 IPVS 负载均衡算法，参数为 --ipvs-scheduler。如果未配置，则默认为 round-robin（轮询）算法（rr）。

rr: round-robin（轮询算法）
lc: least connection（最小连接数）
dh: destination hashing（基于目的地址的哈希算法）
sh: source hashing（基于源IP的哈希算法 ip-hash）
sed: shortest expected delay（最短时间数）
nq: never queue（无须队列等待算法）