coredns用途

1.1 为什么需要服务发现
在K8S集群中，POD有以下特性：

服务动态性强
容器在k8s中迁移会导致POD的IP地址变化
更新发布频繁
版本迭代快，新旧POD的IP地址会不同
支持自动伸缩
大促或流量高峰需要动态伸缩，IP地址会动态增减

service资源解决POD服务发现：
为了解决pod地址变化的问题，需要部署service资源，用service资源代理后端pod，通过暴露service资源的固定地址(集群IP)，来解决以上POD资源变化产生的IP变动问题

那service资源的服务发现呢？

service资源提供了一个不变的集群IP供外部访问，但

IP地址毕竟难以记忆
service资源可能也会被销毁和创建
能不能将service资源名称和service暴露的集群网络IP对于
类似域名与IP关系，则只需记服务名就能自动匹配服务IP
岂不就达到了service服务的自动发现

在k8s中，coredns就是为了解决以上问题。
通过coredns在k8s集群内部做了serviceNAME和serviceIP之间的自动映射,使得不需要记录service的IP地址,只需要通过serviceNAME就能访问POD

kube-proxy

在k8s中，提供相同服务的一组pod可以抽象成一个service，通过service提供的统一入口对外提供服务，每个service都有一个虚拟IP地址（VIP）和端口号供客户端访问。kube-proxy存在于各个node节点上，主要用于Service功能的实现，具体来说，就是实现集群内的客户端pod访问service，或者是集群外的主机通过NodePort等方式访问service。

在当前版本的k8s中，kube-proxy默认使用的是iptables模式，通过各个node节点上的iptables规则来实现service的负载均衡，但是随着service数量的增大，iptables模式由于线性查找匹配、全量更新等特点，其性能会显著下降。从k8s的1.8版本开始，kube-proxy引入了IPVS模式，IPVS模式与iptables同样基于Netfilter，但是采用的hash表，因此当service数量达到一定规模时，hash查表的速度优势就会显现出来，从而提高service的服务性能。

kube-proxy负责为Service提供cluster内部的服务发现和负载均衡，它运行在每个Node计算节点上，负责Pod网络代理, 它会定时从etcd服务获取到service信息来做相应的策略，维护网络规则和四层负载均衡工作。在K8s集群中微服务的负载均衡是由Kube-proxy实现的，它是K8s集群内部的负载均衡器，也是一个分布式代理服务器，在K8s的每个节点上都有一个，这一设计体现了它的伸缩性优势，需要访问服务的节点越多，提供负载均衡能力的Kube-proxy就越多，高可用节点也随之增多。

service是一组pod的服务抽象，相当于一组pod的LB，负责将请求分发给对应的pod。service会为这个LB提供一个IP，一般称为cluster IP。kube-proxy的作用主要是负责service的实现，具体来说，就是实现了内部从pod到service和外部的从node port向service的访问。

————————————————————————区别—————————————————————————————

一、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的过程。