kubernetes权威指南第4版第四章节读书笔记

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　深入掌握Service

1.　　外部服务Service 在某些环境中，应用系统需要将一个外部数据库作为后端服务进行连接，或将另一个集群或Namespace中的服务作为服务的后端，这时可以通过创建一个无Label Selector的Service来实现

apiVersion: v1
kind: v1
metadata:
  name: mysql
  namespace: proxy
spec:
  type: NodePort
  ports:
  - protocol: TCP
    port: 3306
    targetPort: 3306
    nodePort: 32306
---
apiVersion: v1
kind: Endpoints
metadata:
  name: mysql
  namespace: proxy
subsets:
  - addresses:
      - ip: xxx.xxx.xxx.xxx
    ports:
      - port: 3306

KubeDNS

2.　　从Kubernetes 1.4版本开始，SkyDNS组件便被KubeDNS替换，主要考虑是SkyDNS组件之间通信较多，整体性能不高。KubeDNS由3个容器组成：kubedns、dnsmasq和sidecar，去掉了SkyDNS中的etcd存储，将 DNS记录直接保存在内存中，以提高查询性能。kubedns容器监控 Kubernetes中Service资源的变化，根据Service的名称和IP地址生成DNS 记录，并将DNS记录保存在内存中；dnsmasq容器从kubedns中获取DNS 记录，提供DNS缓存，为客户端容器应用提供DNS查询服务；sidecar提供对kubedns和dnsmasq服务的健康检查功能

3.　　从Kubernetes 1.11版本开始，Kubernetes集群的DNS服务由CoreDNS 提供。CoreDNS是CNCF基金会的一个项目，是用Go语言实现的高性能、插件式、易扩展的DNS服务端。CoreDNS解决了KubeDNS的一些问题，例如dnsmasq的安全漏洞、externalName不能使用stubDomains设置，等等.CoreDNS支持自定义DNS记录及配置upstream DNS Server，可以统一管理Kubernetes基于服务的内部DNS和数据中心的物理DNS。CoreDNS没有使用多个容器的架构，只用一个容器便实现了 KubeDNS内3个容器的全部功能

4.　　CoreDNS的主要功能是通过插件系统实现的。CoreDNS实现了一种链式插件结构，将DNS的逻辑抽象成了一个个插件，能够灵活组合使用.CoreDNS的主要功能是通过插件系统实现的。CoreDNS实现了一种链式插件结构，将DNS的逻辑抽象成了一个个插件，能够灵活组合使用。

　　常用的插件如下。◎ loadbalance：提供基于DNS的负载均衡功能。 ◎ loop：检测在DNS解析过程中出现的简单循环问题。 ◎ cache：提供前端缓存功能。 ◎ health：对Endpoint进行健康检查。 ◎ kubernetes：从Kubernetes中读取zone数据。 ◎ etcd：从etcd读取zone数据，可以用于自定义域名记录。 ◎ file：从RFC1035格式文件中读取zone数据。 ◎ hosts：使用/etc/hosts文件或者其他文件读取zone数据，可以用于自定义域名记录。 ◎ auto：从磁盘中自动加载区域文件。 ◎ reload：定时自动重新加载Corefile配置文件的内容。 ◎ forward：转发域名查询到上游DNS服务器。 ◎ proxy：转发特定的域名查询到多个其他DNS服务器，同时提供到多个DNS服务器的负载均衡功能。 ◎ prometheus：为Prometheus系统提供采集性能指标数据的 URL。◎ pprof：在URL路径/debug/pprof下提供运行时的性能数据。 ◎ log：对DNS查询进行日志记录。 ◎ errors：对错误信息进行日志记录。在下面的示例中为域名“cluster.local”设置了一系列插件，包括 errors、health、kubernetes、prometheus、forward、cache、loop、reload 和loadbalance，在进行域名解析时，这些插件将以从上到下的顺序依次执行

另外，etcd和hosts插件都可以用于用户自定义域名记录。下面是使用etcd插件的配置示例，将以“.com”结尾的域名记录配置为从etcd中获取，并将域名记录保存在/skydns路径下：

如果用户在etcd中插入一条“10.1.1.1 mycompany.com”DNS记录：

客户端应用就能访问域名“mycompany.com”了：

forward和proxy插件都可以用于配置上游DNS服务器或其他DNS服务器，当在CoreDNS中查询不到域名时，会到其他DNS服务器上进行查询。在实际环境中，可以将Kubernetes集群外部的DNS纳入CoreDNS，进行统一的DNS管理

除了使用集群范围的DNS服务（如CoreDNS），在Pod级别也能设置DNS的相关策略和配置.在Pod的YAML配置文件中通过spec.dnsPolicy字段设置DNS策略，例如：

　　◎ Default：继承Pod所在宿主机的DNS设置。 ◎ ClusterFirst：优先使用Kubernetes环境的DNS服务（如 CoreDNS提供的域名解析服务），将无法解析的域名转发到从宿主机继承的DNS服务器。 ◎ ClusterFirstWithHostNet：与ClusterFirst相同，对于以 hostNetwork模式运行的Pod，应明确指定使用该策略。 ◎ None：忽略Kubernetes环境的DNS配置，通过spec.dnsConfig自定义DNS配置。这个选项从Kubernetes 1.9版本开始引入，到Kubernetes 1.10版本升级为Beta版，到Kubernetes 1.14版本升级为稳定版。自定义DNS配置可以通过spec.dnsConfig字段进行设置，可以设置下列信息。◎ nameservers：一组DNS服务器的列表，最多可以设置3个。 ◎ searches：一组用于域名搜索的DNS域名后缀，最多可以设置6 个。◎ options：配置其他可选DNS参数，例如ndots、timeout等，以 name或name/value对的形式表示。

　　以下面的dnsConfig为例：

该Pod被成功创建之后，容器内的DNS配置文件/etc/resolv.conf的内容将被系统设置为：

表示该Pod完全使用自定义的DNS配置，不再使用Kubernetes环境的 DNS服务

Ingress

使用Ingress进行负载分发时，Ingress Controller基于Ingress规则将客户端请求直接转发到Service对应的后端Endpoint（Pod）上，这样会跳过kube-proxy的转发功能，kube-proxy不再起作用。如果Ingress Controller提供的是对外服务，则实际上实现的是边缘路由器的功能

　　为了实现灵活的负载分发策略，Ingress策略可以按多种方式进行配置，下面对几种常见的Ingress转发策略进行说明。1.转发到单个后端服务上基于这种设置，客户端到Ingress Controller的访问请求都将被转发到后端的唯一Service上，在这种情况下Ingress无须定义任何rule。