深入掌握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。
不同的域名（虚拟主机名）被转发到不同的服务上
不使用域名的转发规则。这种配置用于一个网站不使用域名直接提供服务的场景，此时通过 任意一台运行ingress-controller的Node都能访问到后端的服务。
注意，使用无域名的Ingress转发规则时，将默认禁用非安全 HTTP，强制启用HTTPS。可以在Ingress的定义中设置一个annotation“ingress.kubernetes.io/ssl- redirect=false”来关闭强制启用HTTPS的设置：
