关于k8s:几张图解释明白-Kubernetes-Ingress

起源：K8s 技术圈

作者：阳明

Kubernetes Ingress 只是 Kubernetes 中的一个一般资源对象，须要一个对应的 Ingress 控制器来解析 Ingress 的规定，裸露服务到内部，比方 ingress-nginx，实质上来说它只是一个 Nginx Pod，而后将申请重定向到其余外部（ClusterIP）服务去，这个 Pod 自身也是通过 Kubernetes 服务裸露进来，最常见的形式是通过 LoadBalancer 来实现的。同样本文咱们心愿用一个简略清晰的概述，让你来理解 Kubernetes Ingress 背地的货色，让你更容易了解应用的 Ingress。

咱们能够应用 Ingress 来使外部服务裸露到集群内部去，它为你节俭了贵重的动态 IP，因为你不须要申明多个 LoadBalancer 服务了，此次，它还能够进行更多的额定配置。上面咱们通过一个简略的示例来对 Ingress 进行一些阐明吧。

01 简略 HTTP server

首先，咱们先回到容器、Kubernetes 之前的时代。

之前咱们更多会应用一个（Nginx）HTTP server 来托管咱们的服务，它能够通过 HTTP 协定接管到一个特定文件门路的申请，而后在文件系统中查看这个文件门路，如果存在则就返回即可。

例如，在 Nginx 中，咱们能够通过上面的配置来实现这个性能。

location /folder {
 root /var/www/;
 index index.html;
}

除了下面提到的性能之外，咱们能够当 HTTP server 接管到申请后，将该申请重定向到另一个服务器（意味着它作为代理）去，而后将该服务器的响应重定向到客户端去。对于客户端来说，什么都没有扭转，接管到的后果依然还是申请的文件（如果存在的话）。

同样如果在 Nginx 中，重定向能够配置成上面的样子：

location /folder {proxy_pass http://second-nginx-server:8000;}

这意味着 Nginx 能够从文件系统中提供文件，或者通过代理将响应重定向到其余服务器并返回它们的响应。

02 简略的 Kubernetes 示例

应用 ClusterIP 服务

在 Kubernetes 中部署利用后，咱们应该先去理解 Kubernetes Service 服务（前文中解说的）。比方咱们有两个 worker 节点，有两个服务 service-nginx 和 service-python，它们指向不同的 pods。这两个服务没有被调度到任何特定的节点上，也就是在任何节点上都有可能，如下图所示：

在集群外部咱们能够通过他们的 Service 服务来申请到 Nginx pods 和 Python pods 下来，当初咱们想让这些服务也能从集群内部进行拜访，依照前文提到的咱们就须要将这些服务转换为 LoadBalancer 服务。

应用 LoadBalancer 服务

当然应用 LoadBalancer 服务的前提是咱们的 Kubernetes 集群的托管服务商要能反对才行，如果反对咱们能够将下面的 ClusterIP 服务转换为 LoadBalancer 服务，能够创立两个内部负载均衡器，将申请重定向到咱们的节点 IP，而后重定向到外部的 ClusterIP 服务。

咱们能够看到两个 LoadBalancers 都有本人的 IP，如果咱们向 LoadBalancer 22.33.44.55 发送申请，它请被重定向到咱们的外部的 service-nginx 服务去。如果发送申请到 77.66.55.44，它将被重定向到咱们的外部的 service-python 服务。

这个的确很不便，然而要晓得 IP 地址是比拟罕见的，而且价格可不便宜。设想下咱们 Kubernetes 集群中不只是两个服务，有很多的话，咱们为这些服务创立 LoadBalancers 老本是不是就成倍增加了。

那么是否有另一种解决方案能够让咱们只应用一个 LoadBalancer 就能够把申请转发给咱们的外部服务呢？咱们先通过手动（非 Kubernetes）的形式来探讨下这个问题。

手动配置 Nginx 代理服务

咱们晓得 Nginx 能够作为一个代理应用，所以咱们能够很容易想到运行一个 Nginx 来代理咱们的服务。如下图所示，咱们新增了一个名为 service-nginx-proxy 的新服务，它实际上是咱们惟一的一个 LoadBalancer 服务。service-nginx-proxy 依然会指向一个或多个 Nginx-pod-endpoints（为了简略没有在图上标识），之前的另外两个服务转换为简略的 ClusterIP 服务了。

能够看到咱们只调配了一个 IP 地址为 11.22.33.44 的负载均衡器，对于不同的 http 申请门路咱们用黄色来进行标记，他们的指标是统一的，只是蕴含的不同的申请 URL。

service-nginx-proxy 服务会依据申请的 URL 来决定他们应该将申请重定向到哪个服务去。

在上图中咱们有两个背地的服务，别离用红色和蓝色进行了标记，红色会重定向到 service-nginx 服务，蓝色重定向到 service-python 服务。对应的 Nginx 代理配置如下所示：

location /folder {proxy_pass http://service-nginx:3001;}
location /other {proxy_pass http://service-python:3002;}

只是目前咱们须要去手动配置 service-nginx-proxy 服务，比方新增了一个申请门路须要路由到其余服务去，咱们就须要去重新配置 Nginx 的配置让其失效，然而这个的确是一个可行的解决方案，只是有点麻烦而已。

而 Kubernetes Ingress 就是为了让咱们的配置更加容易、更加智能、更容易治理呈现的，所以在 Kubernetes 集群中咱们会用 Ingress 来代替下面的手动配置的形式将服务裸露到集群外去。

03 应用 Kubernetes Ingress

当初咱们将下面手动配置代理的形式转换为 Kubernetes Ingress 的形式，如下图所示，咱们只是应用了一个事后配置好的 Nginx（Ingress），它曾经为咱们做了所有的代理重定向工作，这为咱们节俭了大量的手动配置工作了。

这其实就曾经阐明了 Kubernetes Ingress 是什么，上面让咱们来看看一些配置实例吧。

装置 Ingress 控制器

Ingress 只是 Kubernetes 的一种资源对象而已，在这个资源中咱们能够去配置咱们的服务路由规定，然而要真正去实现辨认这个 Ingress 并提供代理路由性能，还须要装置一个对应的控制器能力实现。

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.24.1/deploy/mandatory.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.24.1/deploy/provider/cloud-generic.yaml

应用上面的命令，能够看到装置在命名空间 ingress-nginx 中的 k8s 资源。

咱们能够看到一个失常的 LoadBalancer 服务，有一个内部 IP 和一个所属的 pod，咱们能够应用命令 kubectl exec 进入该 pod，外面蕴含一个预配置的 Nginx 服务器。

其中的 nginx.conf 文件就蕴含各种代理重定向设置和其余相干配置。

Ingress 配置示例

咱们所应用的 Ingress yaml 例子能够是这样的。

# just example, not tested
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
 annotations:
 kubernetes.io/ingress.class: nginx
 namespace: default
 name: test-ingress
spec:
 rules:
 - http:
 paths:
 - path: /folder
 backend:
 serviceName: service-nginx
 servicePort: 3001
 - http:
 paths:
 - path: /other
 backend:
 serviceName: service-python
 servicePort: 3002

和其余资源对象一样，通过 kubectl create -f ingress.yaml 来创立这个资源对象即可，创立实现后这个 Ingress 对象会被下面装置的 Ingress 控制器转换为对应的 Nginx 配置。

如果你的一个外部服务，即 Ingress 应该重定向到的服务，是在不同的命名空间里，怎么办？因为咱们定义的 Ingress 资源是命名空间级别的。在 Ingress 配置中，只能重定向到同一命名空间的服务。

如果你定义了多个 Ingress yaml 配置，那么这些配置会被一个繁多的 Ingress 控制器合并成一个 Nginx 配置。也就是说所有的人都在应用同一个 LoadBalancer IP。

配置 Ingress Nginx

有时候咱们须要对 Ingress Nginx 进行一些微调配置，咱们能够通过 Ingress 资源对象中的 annotations 注解来实现，比方咱们能够配置各种平时间接在 Nginx 中的配置选项。

kind: Ingress
metadata:
 name: ingress
 annotations:
 kubernetes.io/ingress.class: nginx
 nginx.ingress.kubernetes.io/proxy-connect-timeout: '30'
 nginx.ingress.kubernetes.io/proxy-send-timeout: '500'
 nginx.ingress.kubernetes.io/proxy-read-timeout: '500'
 nginx.ingress.kubernetes.io/send-timeout: "500"
 nginx.ingress.kubernetes.io/enable-cors: "true"
 nginx.ingress.kubernetes.io/cors-allow-methods: "*"
 nginx.ingress.kubernetes.io/cors-allow-origin: "*"
...

此外也能够做更细粒度的规定配置，如下所示：

nginx.ingress.kubernetes.io/configuration-snippet: |
 if ($host = 'www.qikqiak.com') {rewrite ^ https://qikqiak.com$request_uri permanent;}

这些正文都将被转换成 Nginx 配置，你能够通过手动连贯 (kubectl exec) 到 nginx pod 中查看这些配置。

对于 ingress-nginx 更多的配置应用能够参考官网文档相干阐明：

• https://github.com/kubernetes…
• https://github.com/kubernetes…

查看 ingress-nginx 日志

要排查问题，通过查看 Ingress 控制器的日志十分有帮忙。

应用 Curl 测试

如果咱们想测试 Ingress 重定向规定，最好应用 curl -v yourhost.com 来代替浏览器，能够防止缓存等带来的问题。

重定向规定

在本文的示例中咱们应用 /folder 和 /other/directory 等门路来重定向到不同的服务，此外咱们也能够通过主机名来辨别申请，比方将 api.myurl.com 和 site.myurl.com 重定向到不同的外部 ClusterIP 服务去。

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
 name: simple-fanout-example
spec:
 rules:
 - host: api.myurl.com
 http:
 paths:
 - path: /foo
 backend:
 serviceName: service1
 servicePort: 4200
 - path: /bar
 backend:
 serviceName: service2
 servicePort: 8080
 - host: website.myurl.com
 http:
 paths:
 - path: /
 backend:
 serviceName: service3
 servicePort: 3333

SSL/HTTPS

可能咱们想让网站应用平安的 HTTPS 服务，Kubernetes Ingress 也提供了简略的 TLS 校验，这意味着它会解决所有的 SSL 通信、解密 / 校验 SSL 申请，而后将这些解密后的申请发送到外部服务去。

如果你的多个外部服务应用雷同（可能是通配符）的 SSL 证书，这样咱们就只须要在 Ingress 上配置一次，而不须要在外部服务下来配置，Ingress 能够应用配置的 TLS Kubernetes Secret 来配置 SSL 证书。

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
 name: tls-example-ingress
spec:
 tls:
 - hosts:
 - sslexample.foo.com
 secretName: testsecret-tls
 rules:
 - host: sslexample.foo.com
 http:
 paths:
 - path: /
 backend:
 serviceName: service1
 servicePort: 80

不过须要留神的是如果你在不同的命名空间有多个 Ingress 资源，那么你的 TLS secret 也须要在你应用的 Ingress 资源的所有命名空间中可用。

04 总结

这里咱们简略介绍了 Kubernetes Ingress 的原理，简略来说：它不过是一种轻松配置 Nginx 服务器的办法，它能够将申请重定向到其余外部服务去。这为咱们节俭了贵重的动态 IP 和 LoadBalancers 资源。

另外须要留神的是还有其余的 Kubernetes Ingress 类型，它们外部没有设置 Nginx 服务，但可能应用其余代理技术，一样也能够实现下面的所有性能。

原文链接：https://codeburst.io/kubernet…