kubernetes学习总结-8客户端与pod的通信机制

连接集群外部服务

svc负责监测它所匹配的pod的状态信息，根据标签把它加到svc队列里来，后面pod的信息有变化的话，变化信息回同步更新到svc中，目标主机通过反向代理svc时， svc会自动更新掉相关的变化信息，不需要去做手动的修改。

• svc限制：

默认只提供4层负载均衡的能力，而没有7层的功能，但有时可能需要更多的匹配规则来转发请求，这点上4层负载均衡是不支持的。可使用increas功能实现7层负载均衡

• 4层是TCP层，使用IP+端口的方式。类似路由器，只是修改下IP地址，然后转发给后端服务器，TCP三次握手是直接和后端连接的。只不过在后端机器上看到的都是与代理机的IP的established而已。
• 7层代理则必须要先和代理机三次握手后，才能得到7层（HTTP层）的具体内容，然后再转发。意思就是代理机必须要与client和后端的机器都要建立连接。显然性能不行了，但胜在于七层，能写更多的转发规则

解释一下上图：kube-proxy去监控pod的相关信息，把信息写入到IP tables里面的规则里去，当客户端访问svc时，实际上访问的就是iptables里面的规则，即客户端访问节点node是通过iptables实现的，iptables规则是kube-proxy写入的，apiservice通过监控kube-proxy实现服务和端点信息的发现或者监控，kube-proxy通过pod标签判断端点信息是否写入到svc的endpoints端点信息中去

为什么不适用轮询DNS：DNS会在很多的客户端里进行缓存，很多服务进行访问域名解析的时候都不会对DNS进行清除缓存的操作，即访问几次以后还是这个地址信息，那么这里的负载均衡就没办法实现负载均衡了

代理模式的分类

• userspace

kube-proxy压力比较大

• iptables代理模式

访问由防护墙完成，访问速度增加，kube-proxy稳定性提高，压力减小，但是防火墙的性能可能没有那么高

• ipvs代理模式

• 这种模式kube-proxy会监视kubernetes service对象和endpoint，调用netlink接口以相应的创建ipvs规则，并定期与kubernetes service和endpoints对象同步ipvs规则，以确保ipvs状态与期望一致，访问服务时，流量将会被重新定向到其中一个后端pod
• 与iptables类似，ipvs与netfilter的hook功能，但使用hash表作为底层数据结构并在内核空间中工作，这意味着ipvs可以更快的重定向流量，并且在同步代理规则时具有更好的性能，此外ipvs为负载均衡提供了更多的额选项：
  rr：轮询调度；
  lc：最小连接数；
  dn：目标哈希；
  sh：源哈希；
  sed：最短期望延迟；
  nq：不排队调度
  
  注意：ipvs模式假定在运行kube-proxy之前的节点上都安装了IPVS模块。当kube-proxy以ipvs代理模式启动时，kube-proxy将烟证节点上是否安装了IPVS模块，如果未安装，kube-proxy将回退到iptables代理模式

cluserIP

• 通过yaml文件创建deployment

apiVersion: v1
kind: Deployment
metadata:
  name: myapp-deploy
  namespace: default
spec:
  replicas: 3
  selector:
    matchlabeis:
     app: myapp #设置两个标签
     release: stable
  template:
    metadata:
      labels:
        app: myapp
        release: stable
    spec:
      containers:
      - name: myapp
        image: centos
        imagePullPolicy: IfNotPresent

• 通过yaml文件创建svc

apiVersion: v1
kind: Service
metadata:
  name: myapp
  namespace: default
spec:
  type: ClusterIP #不指定类型的话默认也是ClusterIP
  selector:
    app: myapp #指定要匹配的pod的标签
  ports:
  - name: http
    port: 80 #通过端口的转发来进行访问
    targetport: 80
   

创建svc以后，可以使用ipvsadm -Ln查看创建成功的ip地址下有么有对应的pod的IP地址。或者直接使用curl IP来看看IP能否被访问

• 常用指令

#查看svc
kubectl get svc 
#删除svc，通过指定删除的文件去删除相对应的资源
kubectl delete -f yourYamlName.yaml 

#通过exec远程命令在一个已经存在的pod上执行任何命令
kubectl exec yourPodName -- curl -s http:123.206.14.23

双横杠--解释：代表着kubectl的命令的结束，横杠后的指令表示在pod内部需要执行的命令。

无头服务Headless Service

虽然没有CluserIP，但是可以通过地址加域名的格式进行访问

Nodeport

LoadBalancer

ExternalName

Ingress

Ingress-Nginx github官网
Ingress-Nginx 官网

有很多版本，比如Ingress-Hubproxy等解决方案，类似于提供一个api接口或者暴露方式

• Ingress安装

访问官网，首先将需要下载的镜像下载到本地，然后通过提供的yaml文件就可以部署Ingress

• Ingress实验HTTP代理访问，使用到deployment、Service、Ingress yaml文件

通过Ingress暴露多个服务

pod就绪检测

• 在yaml文件中添加就绪探针

kubectl edit rc yourRCname #修改rc的yaml文件

排除服务故障