【k8s记录】k8s核心组件kube-dns和kube-proxy的区别

 

一、kube-proxy功能主要是外部服务nodePort访问集群时转发到目标服务，即clusterIP到nodeIP的转换。

举个例子：集群中有三个节点，node1（node1-ip），node2（node2-ip）。

微服务A部署以nodePort的形式部署在slave2中，副本为3个，端口是9002。

外部客户端通过访问访问http://node1-ip:9002即可访问到微服务A。

kube-proxy在node1节点上也起了一个端口9002，在iptables的规则中，目标端口9002被指向指向目标POD的三个IP（中间还会有细节，这里就不展开了）。因此，当外部访问9002端口时，根据iptables的规则会将该消息分发给三个POD的IP:9002这三个个地址（概率33.33%）。

同理：多个节点的情况下，都可以通过访问node1的ip加上service的Port访问到任一节点的服务。

这也就是说，内网环境的k8s集群，只需要任一个节点挂载公网IP，所有以nodePort部署的服务都可以访问到。

下面是实际环境中的kube-proxy截图，daemonset方式部署的，确保每个节点都会运行kube-proxy服务。

打开看一下详细内容(重要信息已做修改)

apiVersion: v1
kind: Pod
metadata:
  annotations:
    kubernetes.io/config.hash: 1d8d265ec77f0324b542c3bbde5b2902
    kubernetes.io/config.mirror: 1d8d265ec77f0324b542c3bbde5b2902
    kubernetes.io/config.seen: "2021-01-21T14:12:28.203781042+08:00"
    kubernetes.io/config.source: file
    kubespray.kube-proxy-cert/serial: 4B2222A427E807CDA6F1D2247475B1EFD5694188
  creationTimestamp: "2021-01-21T06:12:37Z"
  labels:
    k8s-app: kube-proxy
  name: kube-proxy-slave1
  namespace: kube-system
  resourceVersion: "52059622"
  selfLink: /api/v1/namespaces/kube-system/pods/kube-proxy-slave1
  uid: a8bd59b4-5baf-11eb-a4d0-fa163e777424
spec:
  containers:
  - command:
    - /hyperkube
    - proxy
    - --v=2
    - --kubeconfig=/etc/kubernetes/kube-proxy-kubeconfig.yaml
    - --bind-address=192.168.100.6
    - --cluster-cidr=10.151.0.0/16
    - --proxy-mode=iptables
    - --oom-score-adj=-998
    - --healthz-bind-address=192.168.100.6
    image: *****/library/iop/gcr.io/google-containers/hyperkube:v1.14.3.5
    imagePullPolicy: IfNotPresent
    livenessProbe:
      failureThreshold: 8
      httpGet:
        path: /healthz
        port: 10256
        scheme: HTTP
      initialDelaySeconds: 15
      periodSeconds: 10
      successThreshold: 1
      timeoutSeconds: 15
    name: kube-proxy
    resources:
      limits:
        cpu: 500m
        memory: 2G
      requests:
        cpu: 150m
        memory: 64M
    securityContext:
      privileged: true
      procMount: Default
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /etc/ssl/certs
      name: ssl-certs-host
      readOnly: true
    - mountPath: /etc/kubernetes/ssl
      name: etc-kube-ssl
      readOnly: true
    - mountPath: /etc/kubernetes/kube-proxy-kubeconfig.yaml
      name: kubeconfig
      readOnly: true
    - mountPath: /var/run/dbus
      name: var-run-dbus
    - mountPath: /lib/modules
      name: lib-modules
      readOnly: true
    - mountPath: /run/xtables.lock
      name: xtables-lock
  dnsPolicy: ClusterFirst
  enableServiceLinks: true
  hostNetwork: true
  nodeName: slave1
  nodeSelector:
    beta.kubernetes.io/os: linux
  priority: 2000001000
  priorityClassName: system-node-critical
  restartPolicy: Always
  schedulerName: default-scheduler
  securityContext: {}
  terminationGracePeriodSeconds: 30
  tolerations:
  - effect: NoExecute
    operator: Exists
  volumes:
  - hostPath:
      path: /usr/share/ca-certificates
      type: ""
    name: ssl-certs-host
  - hostPath:
      path: /etc/kubernetes/ssl
      type: ""
    name: etc-kube-ssl
  - hostPath:
      path: /etc/kubernetes/kube-proxy-kubeconfig.yaml
      type: ""
    name: kubeconfig
  - hostPath:
      path: /var/run/dbus
      type: ""
    name: var-run-dbus
  - hostPath:
      path: /lib/modules
      type: ""
    name: lib-modules
  - hostPath:
      path: /run/xtables.lock
      type: FileOrCreate
    name: xtables-lock
status:
  hostIP: 192.168.100.6
  phase: Running
  podIP: 192.168.100.6
  qosClass: Burstable
  startTime: "2021-01-21T06:12:35Z"

简单分析一下，启动读取了kube-proxy-kubeconfig.yaml文件，iptables运行模式。

kube-proxy一共有三种运行模式、

1.用户空间代理模式---基本废除了。

2.iptables模式---中小规模的k8s集群。

3.ipyablesIPVS模式--大规模k8s集群。

二、kube-dns功能主要是处理Pod通过servicename访问服务，即服务名称(servicename)到clusterIP的解析。

名词解释：DNS：我们非常熟悉且最简单的一种方式，跟域名和IP映射的原理类似，我们可以将服务域名名称和一到多个机器IP进行关联或者是一个负载均衡器（指向服负载均衡好处是可以避免失效DNS条目问题）。DNS的服务发现方式最大的优点就是它是一种大家熟知的标准形式，技术支持性好。缺点就是当服务节点的启动和销毁变得更加动态时DNS更新条目很难做到高可用和实时性。

下面举个例子：微服务app-service中访问mysql数据库，在代码里写的mysql地址是：mysql-service.default.svc，是如何通过这个名字找到mysql数据库呢？

首先查询本机节点的/etc/resolve.conf，一般都是指向kube-dns的clusterIP，然后去访问kube-dns，kube-dns返回mysql-service的clusterIP。

如果kube-dns也查不到，会继续向上转发，比如master节点的/etc/resolve.conf等。

这样的好处就是，微服务只填写mysql-service.default.svc就可以，如果有mysql的ip更换，kube-dns自动会同步，对服务来说是不需要改动的。

每一个POD中指向到DNS解析服务都是kube-dns的cluster-IP地址

另外，DNS运行策略有：

• “Default“: Pod继承所在宿主机的设置，也就是直接将宿主机的/etc/resolv.conf内容挂载到容器中。
• “ClusterFirst“: 默认的配置，所有请求会优先在集群所在域查询，也就是kube-dns，如果没有才会转发到上游DNS。
• “ClusterFirstWithHostNet“: 和ClusterFirst一样，不过是Pod运行在hostNetwork:true的情况下强制指定的。
• “None“: 1.9版本引入的一个新值，这个配置忽略所有配置，以Pod的dnsConfig字段为准。

总结：

1.kube-proxy主要是处理集群外部通过nodePort访问集群内服务，通过iptables规则，解析cluterIP到PodIp的过程，并提供服务的负载均衡能力。

2.kube-proxy还可以提供集群内部服务间通过clusterIP访问，也会经过kube-proxy负责转发。

3.kube-dns主要处Pod内通过serviceName访问其他服务，找到服务对应的clusterIP的关系，和一些基本的域名解析功能。

4.kube-dns是和kube-proxy协同工作的，前者通过servicename找到指定clusterIP，后者完成通过clusterIP到PodIP的过程。

有问题欢迎留言讨论，不定时回复，感谢。

支持开源，拥抱开源，为开发者赋能。