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