Kubernetes kube-proxy 详解

前言

在kubernets集群的每个节点上都运行着kube-proxy进程，负责实现Kubernetes中service组件的虚拟IP服务。目前kube-proxy有如下三种工作模式：

  • User space 模式
  • iptables 模式
  • IPVS 模式
  1. User space模式

    在这种模式下，kube-proxy通过观察Kubernetes中service和endpoint对象的变化，当有新的service创建时，所有节点的kube-proxy在node节点上随机选择一个端口，在iptables中追加一条把访问service的请求重定向到这个端口的记录，并开始监听这个端口的连接请求。

    比如说创建一个service,对应的IP：1.2.3.4,port:8888，kube-proxy随机选择的端口是32890，则会在iptables中追加

    -A PREROUTING -j KUBE-PORTALS-CONTAINER

-A KUBE-PORTALS-CONTAINER -d 1.2.3.4/32 -p tcp --dport 8888 -j REDIRECT --to-ports 32890

    KUBE-PORTALS-CONTAINER 是kube-proxy在iptable中创建的规则链，在PREROUTING阶段执行

    执行过程：

    • 当有请求访问service时，在PREROUTING阶段，将请求jumpKUBE-PORTALS-CONTAINER
    • KUBE-PORTALS-CONTAINER中的这条记录起作用,把请求重定向到kube-proxy刚监听的端口32890上，数据包进入kube-proxy进程内，
    • 然后kube-proxy会从这个service对应的endpoint中根据SessionAffinity来选择一个作为真实服务响应请求。

    这种模式的缺点就是，请求数据需要到kube-proxy中，就是用户空间中，才能决定真正要转发的实际服务地址，性能会有损耗。并且在应用执行过程中，kube-proxy的可用性也会影响系统的稳定

  2. iptables 模式（目前kube-proxy默认的工作模式）

    在这种模式下，kube-proxy通过观察Kubernetes中service和endpoint对象的变化，当有servcie创建时，kube-proxy在iptables中追加新的规则。对于service的每一个endpoint，会在iptables中追加一条规则，设定动作为DNAT，将目的地址设置成真正提供服务的pod地址；再为servcie追加规则，设定动作为跳转到对应的endpoint的规则上，

    默认情况下，kube-proxy随机选择一个后端的服务，可以通过iptables中的 -m recent 模块实现session affinity功能，通过 -m statistic 模块实现负载均衡时的权重功能

    比如说创建了一个service，对应的IP：1.2.3.4,port:8888，对应一个后端地址：10.1.0.8:8080，则会在iptables中追加（主要规则）：

     -A PREROUTING -j KUBE-SERVICES

-A KUBE-SERVICES -d 1.2.3.4/32 -p tcp –dport 8888 -j KUBE-SVC-XXXXXXXXXXXXXXXX

-A KUBE-SVC-XXXXXXXXXXXXXXXX -j KUBE-SEP-XXXXXXXXXXXXXXXX

-A KUBE-SEP-XXXXXXXXXXXXXXXX -p tcp -j DNAT –to-destination 10.1.0.8:8080

    KUBE-SERVICES 是kube-proxy在iptable中创建的规则链，在PREROUTING阶段执行

    执行过程：

    • 当请求访问service时，iptables在prerouting阶段，将讲求jump到KUBE-SERVICES，
    • 在KUBE-SERVICES 中匹配到上面的第一条准则，继续jump到KUBE-SVC-XXXXXXXXXXXXXXXX，
    • 根据这条准则jump到KUBE-SEP-XXXXXXXXXXXXXXXX，
    • 在KUBE-SEP-XXXXXXXXXXXXXXXX规则中经过DNAT动做，访问真正的pod地址10.1.0.8:8080。

    在这种逻辑下，数据转发都在系统内核层面做，提升了性能，并且即便kube-proxy不工作了，已经创建好的服务还能正常工作 。但是在这种模式下，如果选中的第一个pod不能响应，请求就会失败，不能像userspace模式，请求失败后kube-proxy还能对其他endpoint进行重试。

    这就要求我们的应用(pod)要提供readiness probes功能，来验证后端服务是否能正常提供服务，kube-proxy只会将readiness probes测试通过的pod写入到iptables规则中，以此来避免将请求转发到不正常的后端服务中。

  3. IPVS 模式
    1. 介绍
      由于在iptables模式中，kube-proxy需要为每一个服务，每一个endpoint都生成相应的iptables规则，当服务规模很大时，性能也将显著下降，因此kubernetes在1.8引入了IPVS模式，1.9版本中变成beta，在1.11版本中成为GA。

      在IPVS模式下，kube-proxy观察Kubernetes中service和endpoint对象的变化，通过调用netlink接口创建相应的IPVS规则，并周期性的对Kubernetes的service、endpoint和IPVS规则进行同步，当访问一个service时，IPVS负责选择一个真实的后端提供服务。

      IPVS模式也是基于netfilter的hook功能(INPUT阶段)，这点和iptables模式是一样的，但是用的是内核工作空间的hash表作为存储的数据结构，在这种模式下，iptables可通过ipset来验证具体请求是否满足某条规则。在service变成时，只用更新ipset中的记录，不用改变iptables的规则链，因此可以保证iptables中的规则不会随着服务的增加变多，在超大规模服务集群的情况下提供一致的性能效果。

      在对规则进行同步时的性能也要高于iptables（只用对特定的一个hash表进行更新，而不是像iptables模式下对整个规则表进行操作），所以能提供更高的网络流量。

      IPVS在对后端服务的选择上也提供了更多灵活的算法：

      • rr: round-robin
      • lc: least connection (最少连接数算法)
      • dh: destination hashing（目的hash算法）
      • sh: source hashing（原地址hash算法）
      • sed: shortest expected delay（最短延迟算法）
      • nq: never queue

kube-proxy启用IPVS

由于IPVS的优势，所以尽可能的采用IPVS作为kube-proxy的工作模式，通过以下步骤在创建集群时启用IPVS

  1. 安装依赖工具包

    apt install -y ipvsadm ipset
    • ipset是IPVS工作时会用刀的工具包
    • ipvsadm 是一个客户端工具，可以让我们和ipvs表的数据进行交互
  2. kube-proxy启用IPVS时依赖模块： 
    ip_vs
ip_vs_rr
ip_vs_wrr
ip_vs_sh
nf_conntrack

    可通过如下命令检查系统是否启用了这些模块

    $ lsmod | grep -e ip_vs -e nf_conntrack

    如果没有启用，通过如下命令启用

    $ modprobe -- ip_vs
$ modprobe -- ip_vs_rr
$ modprobe -- ip_vs_wrr
$ modprobe -- ip_vs_sh
$ modprobe -- nf_conntrack
  3. kube-proxy配置文件中追加IPVS相关配置 
    proxy-mode: "ipvs"
ipvs-min-sync-period: ipvs 规则刷新的最小时间间隔
ipvs-scheduler: ipvs的负载算法（rr、lc等）
ipvs-sync-period:  ipvs规则刷新的最大时间间隔（30s）

    采用用IPVS模式时，在启动kube-proxy前必须要确保IPVS模块在服务上存在，如果kube-proxy启动时，经过验证发现IPVS模块不可用，kube-proxy自动采用iptables模式工作，参考代码：server_others.go

在介绍kube-proxy如何使用IPVS实现对service的请求前，先看下IPVS的简单介绍及工作原理

IPVS

  1. 介绍
    IPVS是Linux服务器中用来实现LVS（Linux virtual service）的一个模块，工作在内核空间是一种基于虚拟IP的负载均衡技术，通过用户空间的ipvsadm来执行规则制定，常见术语

    名称 解释
    RS Real Server 后端请求处理服务器
    CIP Client IP,客户端IP
    VIP Director Virtual IP,负载均衡器虚拟IP
    DIP Director IP,负载均衡器IP
    RIP Real Server IP,后端处理请求的真实服务器IP
  2. 工作原理
    1. 因为IPVS是hook到netfilter的input链中执行的，所以需要先了解下数据在netfilter中的流转过程

      正常流程：

      • 数据进入内核空间，到达PreRouting
      • 进行路由决策
      • 请求是发往本机的进入input
      • 进入用户空间处理
      • 处理完进入output
      • 进入postrouting
      • 发送出去
      • 请求不是本机的，进入forward
      • 进入postrouting
      • 发送出去
    2. 加入IPVS后的简化逻辑图

      • 请求到达负载均衡器的内核空间时，到达PREROUTING链
      • 当内核根据路由决策发现地址是本机时，将数据包送往INPUT链
      • 数据包到达INPUT链时，首先会被IPVS检查，如果请求的目的地址、端口信息不在自己的hash表中时，数据正常发往用户空间处理
      • 如果hash表中的规则匹配到请求记录，依据IPVS的工作模式，对请求头中的信息进行修改，之后直接交由POSTROUTING链执行
      • POSTROUTING根据IPVS修改后的请求头信息（此时目的地址是真实的服务地址），通过路由表，用正确的设备将请求转发出去

      可以看到，当IPVS模块工作后，在input链上会再次对请求做匹配，匹配到的直接做postrouting，不再进入用户空间处理，而是把请求发送到IPVS选中的提供真实服务的服务器

    3. IPVS有三种工作模式NAT（Masq）、DR、TUN，因为kube-proxy采用的是NAT模式，所以下面只对NAT模式进行分析

      NAT：Network Address Transition（网络地址转换），工作在此模式下的IPVS，首先根据scheduler策略选择一个真实的后端服务，接着将请求头中的目的地址IP、端口转换成真实服务的IP和端口，之后进入POSTROUTING，向真实的服务器发起请求。当响应数据返回时，再通过masqreade，将返回数据的源地址修改成虚拟服务器的地址，具有有如下特性：

      • Real Server应该使用私有ip地址，和client IP不在一个网段中(如果在一个网段中，real Server可以将数据直接返回客户端，不会再经过Director Server返回）
      • 一般Real Server的网关应该指向DIP，不然的话无法保证响应报文经过Director Server（IP 协议，数据发送给不在同一个网段的服务器时，会把数据发送给网关）
      • RIP要和DIP应该在同一网段内
      • 进出的报文，无论请求还是响应都要经过Directory server（满足上面三点，这个是自然而然的）
      • 支持端口映射
      • Real Server可以使用任意系统，只要端口对应即可

      其流程如下:

      • 当用户请求到达DirectorServer，此时请求的数据报文会先到内核空间的PREROUTING链。 此时报文的源IP为CIP，目标IP为VIP 。
      • PREROUTING检查发现数据包的目标IP是本机，将数据包送至INPUT链。
      • IPVS比对数据包请求的服务是否为集群服务，若是，修改数据包的目标IP地址为后端服务器IP，然后将数据包发至POSTROUTING链。 此时报文的源IP为CIP，目标IP为RIP ，在这个过程完成了目标IP的转换。
      • POSTROUTING链通过选路，将数据包发送给Real Server。
      • Real Server比对发现目标为自己的IP，开始构建响应报文。 此时报文的源IP为RIP，目标IP为CIP 。
      • 因为Real Server的网关指向DIP，并且通常情况下CIP和RIP不在同一个网段内，在这种情况下，Real Server会先将数据发送给Director Server（网关），这样数据就可以沿原路返回。
      • Director Server在响应客户端前，此时会将源IP地址修改为自己的VIP地址，然后响应给客户端。 此时报文的源IP为VIP，目标IP为CIP。
      • 在此过程中CIP一直是不发生变化的

kube-proxy如何使用IPVS

  1. 从IPVS的工作原理上可以知道，kube-proxy想使用IPVS，需要完成以下几个工作

    • 需要路由决策判断要访问的service的VIP属于本机，否则，数据不经过input，直接forward出去，IPVS就没有机会工作了
    • iptables中的规则需要允许对service请求通过，否则数据被过滤掉也不会经过IPVS
    • IPVS要能够判断出访问的service服务是属于集群服务
    • IPVS要能够根据service服务对应的VIP，找到真实的服务，之后修改请求头，向真实的服务发送请求
    • 由于在kubernetes下工作的IPVS，不一定满足经典的NAT模式的特性，所以数据返回路径不一定和请求路径一致,会出现Real Server直接返回数据给客户端的情况
  2. 为了让node节点识别对应的VIP，kube-proxy启动时创建了一个虚拟网络设备kube-ipvs0,类型是dummy,并把service的VIP都设置到这个设备下面。创建这个设备，以及向设备中追加VIP的逻辑都在代码proxier.go中 
    $ ip addr 

27: kube-ipvs0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default
link/ether ba:6b:cb:b9:61:89 brd ff:ff:ff:ff:ff:ff
inet 10.254.0.1/32 brd 10.254.0.1 scope global kube-ipvs0
   valid_lft forever preferred_lft forever
inet 10.254.0.2/32 brd 10.254.0.2 scope global kube-ipvs0
   valid_lft forever preferred_lft forever
inet 10.254.199.160/32 brd 10.254.199.160 scope global kube-ipvs0
   valid_lft forever preferred_lft forever

    对应的service

    $ kubectl get svc -A
NAMESPACE     NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                  AGE
default       clientip     ClusterIP   10.254.199.160   <none>        8080/TCP                 23h
default       kubernetes   ClusterIP   10.254.0.1       <none>        443/TCP                  25d
kube-system   kube-dns     ClusterIP   10.254.0.2       <none>        53/UDP,53/TCP,9153/TCP   23d
kube-system   kubelet      ClusterIP   None             <none>        10250/TCP                18d

    可以看到所有的VIP都在kube-ipvs0这个设备下面

  3. 为了让iptables中的规则允许对Servcie的请求通过，kube-proxy在iptables中追加了如下几条主要规则（iptables.masqueradeAll=false;clusterCIDR=172.30.0.0/16，clusterCIDR就是集群中的pod能分配的IP地址段)：
    1. NAT表中：

      $ iptables -t nat -nL

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
KUBE-SERVICES  all  --  0.0.0.0/0            0.0.0.0/0            /* kubernetes service portals */

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
KUBE-SERVICES  all  --  0.0.0.0/0            0.0.0.0/0            /* kubernetes service portals */

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
KUBE-POSTROUTING  all  --  0.0.0.0/0            0.0.0.0/0            /* kubernetes postrouting rules */

Chain KUBE-MARK-MASQ (3 references)
target     prot opt source               destination
MARK       all  --  0.0.0.0/0            0.0.0.0/0            MARK or 0x4000

Chain KUBE-POSTROUTING (1 references)
target     prot opt source               destination
MASQUERADE  all  --  0.0.0.0/0            0.0.0.0/0            /* kubernetes service traffic requiring SNAT */ mark match 0x4000/0x4000
MASQUERADE  all  --  0.0.0.0/0            0.0.0.0/0            match-set KUBE-LOOP-BACK dst,dst,src

Chain KUBE-SERVICES (2 references)
target     prot opt source               destination
KUBE-MARK-MASQ  all  -- !172.30.0.0/16       0.0.0.0/0            match-set KUBE-CLUSTER-IP dst,dst
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            match-set KUBE-CLUSTER-IP dst,dst

      有两点需要解释下

      1. 关于规则

        KUBE-MARK-MASQ  all  -- !172.30.0.0/16       0.0.0.0/0            match-set KUBE-CLUSTER-IP dst,dst

        意思是对于非集群内的pod访问集群的cluster IP时会执行masquerade，这是因为在kube-proxy的启动条件设置成了iptables.masqueradeAll=false;clusterCIDR=172.30.0.0/16才这样

        如果设置成iptables.masqueradeAll=false;clusterCIDR=，即不设置CIDR规则会变成

        KUBE-MARK-MASQ  all  --  0.0.0.0/0            0.0.0.0/0           match-set KUBE-CLUSTER-IP src,dst

        效果应该是对自己访问自己的请求做masquerade，其他请求都不做

        如果iptables.masqueradeAll=true，规则变成

        KUBE-MARK-MASQ  all  --  0.0.0.0/0            0.0.0.0/0            match-set KUBE-CLUSTER-IP dst,dst

        效果对所有请求都做masquerade

      2. 关于匹配语法 -m set --match-set 。。。 代表用set模块的对请求进行匹配

        语法如下：

         -m set --match-set name flags

        具体传入的flags要依据 name指定的set的类型来传入，具体ipset的用法可通过如下命令查看

        ipset --help

        这里以KUBE-CLUSTER-IP为例

        
$ ipset --list KUBE-CLUSTER-IP
Name: KUBE-CLUSTER-IP
Type: hash:ip,port
Revision: 5
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 408
References: 2
Number of entries: 5
Members:
10.254.0.2,udp:53
10.254.0.1,tcp:443
10.254.0.2,tcp:9153
10.254.199.160,tcp:8080
10.254.0.2,tcp:53
        • 对应的类型信息：Type: hash:ip,port
        • 结合前面的规则 
          ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            match-set KUBE-CLUSTER-IP dst,dst

          表述的意思是请求的目的地址IP、目的端口和KUBE-CLUSTER-IP中的Members有匹配时，就接收请求

    2. filter表中 
      $ iptables -nL -t filter
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
KUBE-FORWARD  all  --  0.0.0.0/0            0.0.0.0/0            /* kubernetes forwarding rules */

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
KUBE-FIREWALL  all  --  0.0.0.0/0            0.0.0.0/0

Chain KUBE-FIREWALL (2 references)
target     prot opt source               destination
DROP       all  --  0.0.0.0/0            0.0.0.0/0            /* kubernetes firewall for dropping marked packets */ mark match 0x8000/0x8000

Chain KUBE-FORWARD (1 references)
target     prot opt source               destination
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            /* kubernetes forwarding rules */ mark match 0x4000/0x4000
ACCEPT     all  --  172.30.0.0/16        0.0.0.0/0            /* kubernetes forwarding conntrack pod source rule */ ctstate RELATED,ESTABLISHED
ACCEPT     all  --  0.0.0.0/0            172.30.0.0/16        /* kubernetes forwarding conntrack pod destination rule */ ctstate RELATED,ESTABLISHED

    通过分析kube-proxy追加的这些规则，可以看到访问service提供的服务时，iptables中的规则最终都会允许请求通过，并且通过 -m set --match-set 的规则匹配机制，kube-proxy不用随着servcie的创建和销毁来修改iptables中的规则，只用修改对应的ipset中相应的Members就能够达到效果，保证iptables的规则表固定大小，实现大规模服务集群中保持性能的稳定

  4. 请求通过了iptables中的规则后，在INPUT阶段，需要IPVS来对请求进行判断，看请求的服务是否属于集群服务，是的话还要能找出正确的真实服务地址，这个kube-proxy如何实现呢

    kube-proxy通过监听API server，当有service创建时，通过调用系统的netlink 接口，将service和对应的endpoint插入到IPVS对应的hash表中，对应代码在proxier.go中，用户可以通过ipvsadm工具查看ipvs hash表中的数据

    $ ipvsadm --list
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  promote.cache-dns.local:http rr
  -> master:6443                  Masq    1      1          0
TCP  promote.cache-dns.local:doma rr
  -> 172.30.78.2:domain           Masq    1      0          0
TCP  promote.cache-dns.local:9153 rr
  -> 172.30.78.2:9153             Masq    1      0          0
TCP  promote.cache-dns.local:http rr
  -> 172.30.22.4:http-alt         Masq    1      0          0
  -> 172.30.78.4:http-alt         Masq    1      0          0
UDP  promote.cache-dns.local:doma rr
  -> 172.30.78.2:domain           Masq    1      0          0

    因为启用了DNS的cache功能，所以这个地方看到的service信息是DNS缓存信息

通过上述几个步骤后，kube-proxy就把需要使用IPVS的依赖条件都实现，就可以在请求到来时利用IPVS机制对请求进行转发了。

原文地址：https://www.cnblogs.com/gaofeng-henu/p/12428057.html

时间： 2024-10-08 21:17:50

Kubernetes kube-proxy 详解的相关文章

Java中InvocationHandler接口中第一个参数proxy详解

java动态代理机制中有两个重要的类和接口InvocationHandler(接口)和Proxy(类),这一个类Proxy和接口InvocationHandler是我们实现动态代理的核心: 1.InvocationHandler接口是proxy代理实例的调用处理程序实现的一个接口,每一个proxy代理实例都有一个关联的调用处理程序:在代理实例调用方法时,方法调用被编码分派到调用处理程序的invoke方法. 看下官方文档对InvocationHandler接口的描述: {@code Invocat

kubernetes资源创建详解【持续完善中】

目录 资源创建详解 一:Pod及常用参数 1.简介 2.模板 3.删除pod 4.设置Pod主机名 5.镜像拉取策略(ImagePullPolicy) 二:RC 1.简介 2.模板 三:Deployment 1.简介 2.模板 四:HPA 1.简介 2.模板 五:StatefulSet 1.简介 2.模板 六:PV和PVC 八:扩展 8.1.Pod调度到指定的Node 资源创建详解 一:Pod及常用参数 1.简介 2.模板 3.删除pod 示例流程如下: 用户发送删除pod的命令,默认宽限期是3

jQuery.proxy() 详解

jQuery.proxy(),接受一个函数,然后返回一个新函数,并且这个新函数始终保持了特定的上下文(context )语境. jQuery.proxy( function, context ) function将要改变上下文语境的函数. context函数的上下文语境(`this`)会被设置成这个 object 对象. jQuery.proxy( context, name ) context函数的上下文语境会被设置成这个 object 对象. name将要改变上下文语境的函数名(这个函数必须

资深实践篇 | 基于Kubernetes 1.61的Kubernetes Scheduler 调度详解

欢迎大家前往腾讯云技术社区,获取更多腾讯海量技术实践干货哦~ 作者:腾讯云容器服务团队 源码为 k8s v1.6.1 版本,github 上对应的 commit id 为 b0b7a323cc5a4a2019b2e9520c21c7830b7f708e 本文将对 Scheduler 的调度算法原理和执行过程进行分析,重点介绍 Scheduler 算法中预选和优选的相关内容. Kubernetes Scheduler的基本功能 Kubernetes Scheduler 的作用是根据特定的调度算法将

kubernetes之StatefulSet详解

概述 RC.Deployment.DaemonSetStatefulSet都是面向无状态的服务,它们所管理的Pod的IP.名字,启停顺序等都是随机的,而StatefulSet是什么?顾名思义,有状态的集合,管理所有有状态的服务,比如MySQL.MongoDB集群等.StatefulSet本质上是Deployment的一种变体,它是t是为了解决有状态服务的问题,它所管理的Pod拥有固定的Pod名称,启停顺序,在StatefulSet中,Pod名字称为网络标识,还必须要用到共享存储,在v1.9版本中

Proxy详解

一.Proxy基础 1. 什么是Proxy? Proxy是一个构造函数,可以通过它生成一个Proxy实例. const proxy = new Proxy(target, handler); // target: 目标对象,待操作对象(可以是普通对象,数组,函数,proxy实例对象) // handler: 一个对象,最多可包含13个操作方法,也可以是空对象 2. Proxy的作用 1. Proxy是一个ES6语法,它的作用主要是通过handler对象中的拦截方法拦截目标对象target的 某些

kubernetes configMap详解

Kubernetes的ConfigMap说明 这篇博文,我们来说一说,关于在kubernetes的pod中自定义配置的问题. 我们知道,在几乎所有的应用开发中,都会涉及到配置文件的变更,比如说在web的程序中,需要连接数据库,缓存甚至是队列等等.而我们的一个应用程序从写第一行代码开始,要经历开发环境.测试环境.预发布环境只到最终的线上环境.而每一个环境都要定义其独立的各种配置.如果我们不能很好的管理这些配置文件,你的运维工作将顿时变的无比的繁琐.为此业内的一些大公司专门开发了自己的一套配置管理中

【Kubernetes】kubectl命令详解 &#646984;

目录 用法概述 子命令详解 参数列表 输出格式 操作示例 原文: http://blog.gqylpy.com/gqy/385 @ 用法概述 kubectl 命令行的语法如下: kubectl [command] [TYPE] [NAME] [flags] command:子命令,用于操作 Kubernetes 集群资源对象的命令,例如 create.delete.describe.get.apply 等. TYPE:资源对象类型,区分大小写,能以单数.复数形式或者简写形式表达. NAME:资源

设计模式 - 代理模式(proxy pattern) 未使用代理模式 详解

代理模式(proxy pattern) 未使用代理模式 详解 本文地址: http://blog.csdn.net/caroline_wendy 部分代码参考: http://blog.csdn.net/caroline_wendy/article/details/37698747 如果需要监控(monitor)类的某些状态, 则需要编写一个监控类, 并同过监控类进行监控. 但仅仅局限于本地, 如果需要远程监控, 则需要使用代理模式(proxy pattern). 具体方法: 1. 类中需要提供

Docker Kubernetes Service 网络服务代理模式详解

Docker Kubernetes  Service 网络服务代理模式详解 Service service是实现kubernetes网络通信的一个服务 主要功能:负载均衡.网络规则分布到具体pod 注:kubernetes deployment服务分配服务器负载均衡VIP只能NODE节点单独访问,这里需要外网用户可以放问到容器内,这里就需要用到service. 网络代理模式 kube-proxy v1.0中只支持userspace模式,在v1.1中,添加了iptables代理,在v1.2开始ip