深入学习 Kubernetes Service

1 Service定义

2 Service基本用法

3 Headless Service

4 集群外部访问Pod或Service

5 DNS服务搭建和配置指南

首先，作为服务发现机制的基本功能，在集群内需要能够通过服务名对服务进行访问，这就需要一个集群范围内的DNS服务完成从服务名到ClusterIP解析

Kubernetes DNS解析经历了三个阶段

5.1 DNS解析三阶段

1 SkyDns 1.2版本时

 

      主要由四个容器组件

      a  kube2sky

      获取Kubernetes中Service资源变化，将Service ip地址和名称生成DNS记录，并保存到etcd中

      b  skydns

      skydns容器从etcd中读取DNS记录，并为客户端容器应用提供DNS查询服务

      c  healthz

      healthz容器提供对skydns服务的健康检查功能

      d  etcd

    数据库存储

2 KubeDNS   1.4版本时

      a  kubedns

 功能类比kuber2sky 负责监控Service资源变化，但是不存储在etcd中，存储在内存中

       b  dnsmasq

从kubedns容器获取DNS记录，提供dns缓存，为客户端容器应用提供DNS查询服务

      c   sidecar

提供对kubedns和dnsmasq服务的健康检查

3  CoreDNS服务  1.11版本开始

coreDNS是CNCF基金会的一个项目，由Go语言实现的高性能、插件式、易扩展的DNS服务端。解决了KuberDNS一些问题，如dnsmasq的安全漏洞，externalName 不能用stubDomains设置，等

coreDNS支持自定义DNS记录及配置upstream DNS Server，可以统一管理Kubernetes基于服务的内部DNS和数据中心的物理DNS

coreDNS只使用了一个容器便实现了kuberDns三个容器的全部功能

5.2  设置Node启动参数

-cluserter-dns=*.*.*.*: 为DNS服务的ClusterIP地址
-clusert-domain=cluster.local:为DNS服务中设置的域名
重启kubelet服务

5.3 创建CodeDNS应用

1 ConfigMap

configMap coreDNS  主要设置coreDNS的主要配置文件CoreFile的内容，其中可以定义各种域名的解析方式和使用的插件

2 Deployment

Deployment coreDNS 主要设置CoreDNS容器应用的内容，

其中注意因为DNS服务是Kubernetes集群的核心关键服务，所以建议为其Deployment设置自动扩缩容控制器，自动管理其副本数量，另外对资源限制部分（CPU和内存限制）的设置也应根据实际环境进行调整

3 Service

是 DNS服务的配置   这个服务需要设置固定的ClusterIP，也需要将所有的Node上的Kubelet启动参数 --clusterj-dns设置为这个ClusterIP

6 Ingress:HTTP7层路由机制

6.1 基本定义

根据对Service上述的那么多解释，我们知道Service的表现形式为IP:PORT形式，即工作在TCP/IP层。对于HTTP服务来说，不同的URL地址经常对应到不同的后端服务或者虚拟服务器（Virtual Host），应用层的转发机制如果仅仅靠Service机制是无法完成的。kubernetes从1.1新增Ingress资源对象，用于将不同的URL访问请求转发到后端不同的Service，以实现HTTP层的业务路由机制。

Kubernetes使用了一个Ingress策略定义和一个具体的Ingress Controller两者结合并实现了一个完整的Ingress 复杂均衡器

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

6.2 创建Ingress Controller和默认的backend服务

在定义Ingress策略之前，需要先部署Ingress Controller，实现为所有后端的Service都提供一个统一的入口。Ingress Controller需要实现基于不同HTTP URL向后转发的负载分发规则，并可以灵活设置7层分发策略。如果公有云服务商能提供该类型的HTTP路由Balancer，则也可设置其为Ingress Controller

在Kubernetes中，Ingress Controller 以Pod的形式运行，监控API Server的/ingress 接口后端的backend services 如果Services发生变化，则Ingress Controller应自动将其更新转发规则。

6.3 定义Ingress策略

对一个地址(mywebsite.com)的访问，设置Ingress策略，定义对其路径(/demo)访问转发到后端服务规则

简单demo

appVersion:extensions/v1betal
kind:Ingress
metadata:
    name:mywebsite-ingress
spec:
    rules:
    -host：mywebsite-ingress
    http:
        paths
            -paths:/demo
            backend:
                serviceName:webapp
                servicePort:8080

上述Ingress定义，说明对目标地址http://mywebsite.com/demo的访问将被转发到集群中的Service webapp即webapp:8080/demo上

在Ingress生效之前，需要先将webapp服务部署完成。同时需要注意Ingress中的path的定义，需要与后端真实Service提供的path一致，否则将转发到一个不存在的path上，引发错误。

创建上述Ingress

#kubectl create -f ingress.yaml

        日志提示  ingress "mywebsite-ingress" created
#kubectl get ingress -o wide 

 

6.4 Ingress的策略配置技巧

1 转发到单个后端服务上

这种配置，客户端到Ingress Controller的访问请求都被转发到后端的唯一Service上，这种情况下Ingress 无须定义任何rule

spec:
    backend:
        serviceName:myweb
        servciePort:8080

2 同一域名下，不同的URL路径被转发到不同的服务商

用于同一个网站通过不同的路径提供不同服务场景

3 不同的域名（虚拟主机名）被转发到不同的服务上

4 不使用域名的转发规则

6.5 Ingress的TLS安全设置