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

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

微服务A部署以nodePort的形式部署在slave2中，副本为3个，端口是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: v1kind: Podmetadata:  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-fa163e777424spec:  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-lockstatus:  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的过程。

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