标签 Kubernetes 下的文章

HTTPS服务的Kubernetes ingress配置实践

在公有云被广泛接纳的今天,数据传输安全问题日益凸显,因为在公有云提供商的经典网络(二层互通)中,即便是内部网络通信也要考虑网络嗅探等hack手段,这也是公有云主推所谓“专用网络(二层隔离)”的原因之一。从应用的角度,我们应该尽量通过技术手段保证数据通信的安全性。而目前最常用的方式就是基于SSL/TLS的安全通信方式了,在七层,对应的就是https了。

这样,下面的仅在负载均衡/反向代理入口做加密通信的传统模型越来越无法满足数据安全性的需要了(nginx与backend service之间是基于明文的http通信):

传统安全通信模型:

client --- (via https) ---> nginx ---- (via http) ----> upstream backend services

我们需要下面的模型:

更为安全的通信模型:

client --- (via https) ---> nginx ---- (via https) ----> upstream backend services

Kubernetes集群中,这种情况稍好些,首先,业务负载运行在集群的“虚拟网络”中,其次,一些K8s的网络插件实现是支持跨节点网络加密的(有一定的网络性能损耗),比如weave。但永远没有绝对的安全,作为业务应用的设计和实现人员,我们要尽可能的保证数据的通信安全,因此在面向七层的应用中,要尽可能的使用基于HTTPS的通信模型。本篇就来实践一下如何为Kubernetes集群内的HTTPS服务进行ingress的配置。

一. 例子概述与环境准备

《实践kubernetes ingress controller的四个例子》一文中,我讲解了四种基本的kubernetes ingress配置方式。在这些例子中,有些例子的ingress controller(nginx)与backend service之间使用的是https,但client到ingress controller之间的通信却一直是基于http的。在本文中,我们的目标就是上面提到的那个更为安全的通信模型,即client与ingress controller(nginx)、nginx与backend service之间均使用的是https通信。这里在《实践kubernetes ingress controller的四个例子》一文例子的基础上,我们创建一个新的nginx ingress controller: nginx-ingress-controller-ic3,并将后端的svc7~svc9三个不同类型的服务暴露给client,如下图所示:

img{512x368}

  • svc7: 是对传统通信模型的“复现”,即client与ingress controller(nginx)间采用https加密通信,但ingress controller(nginx)与svc7间则是明文的http通信;
  • svc8: 是ssl-termination的安全配置模型,即client与svc8的https通信分为“两段”,client与nginx建立https连接后,nginx将client提交的加密请求解密后,再向svc8发起https请求,并重新加密请求数据。这种client端ssl的过程在反向代理或负载均衡器终结的https通信方式被称为“ssl-termination”。
  • svc9: 是ssl-passthrough的安全配置模型,即nginx不会对client的https request进行解密,而是直接转发给backend的svc9服务,client端的ssl过程不会终结于nginx,而是在svc9对应的pod中终结。这种https通信方式被称为”ssl-passthrough”。这种配置模型尤其适合backend service对client端进行client certificate验证的情况,同时也降低了nginx加解密的性能负担。

本文基于下面环境进行实验:kubernetes 1.10.3、weave networks 2.3.0、nginx-ingress-controller:0.15.0。关于本文涉及的例子的源码、chart包以及ingress controllers的yaml源文件可以在这里下载到。

二. 建立新的ingress-nginx-controller:nginx-ingress-controller-ic3

为了更好地进行例子说明,我们建立一个新的ingress-nginx-controller:nginx-ingress-controller-ic3,svc7~svc9都通过该ingress controller进行服务入口的暴露管理。要创建nginx-ingress-controller-ic3,我们首先需要在ic-common.yaml中为Role: nginx-ingress-role添加一个resourceName: “ingress-controller-leader-ic3″,并apply生效:

// ic-common.yaml
... ...
    resourceNames:
      # Defaults to "<election-id>-<ingress-class>"
      # Here: "<ingress-controller-leader>-<nginx>"
      # This has to be adapted if you change either parameter
      # when launching the nginx-ingress-controller.
      - "ingress-controller-leader-ic1"
      - "ingress-controller-leader-ic2"
      - "ingress-controller-leader-ic3"
... ...

# kubectl apply -f ic-common.yaml

我们为nginx-ingress-controller-ic3创建nodeport service,新nodeport为:30092:

// ic3-service-nodeport.yaml
apiVersion: v1
kind: Service
metadata:
  name: ingress-nginx-ic3
  namespace: ingress-nginx-demo
spec:
  type: NodePort
  ports:
  - name: https
    port: 443
    targetPort: 443
    nodePort: 30092
    protocol: TCP
  selector:
    app: ingress-nginx-ic3

注意:ingress-nginx-ic3 service的nodeport映射到ic3 ingress controller的443端口,也就是支持安全通信的端口,而不是明文的80端口。

最后创建nginx-ingress-controller-ic3 pod,可以复制一份ic2-mandatory.yaml,然后将内容中的ic2全部修改为ic3即可:

# kubectl apply -f ic3-mandatory.yaml

如无意外,nginx-ingress-controller-ic3应该已经正常地运行在你的k8s cluster中了。

三. svc7: 使用ssl termination,但nginx与backend服务之间采用明文传输(http)

加密Web流量有两个主要配置方案:SSL termination和SSL passthrough。

使用SSL termination时,客户端的SSL请求在负载均衡器/反向代理中解密,解密操作将增加负载均衡器的工作负担,较为耗费CPU,但简化了SSL证书的管理。至于负载均衡器和后端之间的流量是否加密,需要nginx另行配置。

SSL Passthrough,意味着client端将直接将SSL连接发送到后端(backend)。与SSL termination不同,请求始终保持加密,并且解密负载分布在后端服务器上。但是,这种情况的SSL证书管理略复杂,证书必须在每台服务器上自行管理。另外,在这种方式下可能无法添加或修改HTTP header,可能会丢失X-forwarded-* header中包含的客户端的IP地址,端口和其他信息。

我们先来看一种并不那么“安全”的“传统模型”:在nginx上暴露https,但nginx到backend service(svc7)采用http

我们先来创建相关的密钥和公钥证书,并以一个Secret:ingress-controller-demo-tls-secret存储密钥和证书数据:

// ingress-controller-demo/manifests下面

# openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ic3.key -out ic3.crt -subj "/CN=*.tonybai.com/O=tonybai.com"
# kubectl create secret tls ingress-controller-demo-tls-secret --key  ic3.key --cert ic3.crt

svc7几乎是和svc1一样的程序(输出的字符串标识不同),但svc7的ingress与svc1大不相同,因为我们需要通过https访问svc7的ingress:

// svc7的values.yaml
... ...
replicaCount: 1

image:
  repository: bigwhite/ingress-controller-demo-svc7
  tag: v0.1
  pullPolicy: Always

service:
  type: ClusterIP
  port: 443

ingress:
  enabled: true
  annotations:
    kubernetes.io/ingress.class: ic3
  path: /
  hosts:
    - svc7.tonybai.com
  tls:
    - secretName: ingress-controller-demo-tls-secret
      hosts:
        - svc7.tonybai.com
... ...

与svc1的values.yaml不同的是,我们使用的ingress controller是ic3,我们开启了tls,secret用的就是我们上面创建的那个secret:ingress-controller-demo-tls-secret。创建ic3-svc7后,我们看到ingress controller内部的nginx.conf中有关svc7的配置输出如下:

# kubectl exec nginx-ingress-controller-ic3-67f7cf7845-2tnc9 -n ingress-nginx-demo -- cat /etc/nginx/nginx.conf

        # map port 442 to 443 for header X-Forwarded-Port
        map $pass_server_port $pass_port {
                442              443;
                default          $pass_server_port;
        }

        upstream default-ic3-svc7-http {
                least_conn;

                keepalive 32;

                server 192.168.28.13:8080 max_fails=0 fail_timeout=0;

        }

## start server svc7.tonybai.com
        server {
                server_name svc7.tonybai.com ;

                listen 80;

                listen [::]:80;

                set $proxy_upstream_name "-";

                listen 442 proxy_protocol   ssl http2;

                listen [::]:442 proxy_protocol  ssl http2;

                # PEM sha: 248951b75535e0824c1a7f74dc382be3447057b7
                ssl_certificate                         /ingress-controller/ssl/default-ingress-controller-demo-tls-secret.pem;
                ssl_certificate_key                     /ingress-controller/ssl/default-ingress-controller-demo-tls-secret.pem;

                ssl_trusted_certificate                 /ingress-controller/ssl/default-ingress-controller-demo-tls-secret-full-chain.pem;
                ssl_stapling                            on;
                ssl_stapling_verify                     on;

                location / {
                        ... ...
                        proxy_pass http://default-ic3-svc7-http;

                        proxy_redirect                          off;

                }
           ... ...
        }
        ## end server svc7.tonybai.com

可以看到30092(nodeport) 映射的ingress controller的443端口在svc7.tonybai.com这个server域名下已经有了ssl标识,并且ssl_certificate和ssl_certificate_key对应的值就是我们之前创建的ingress-controller-demo-tls-secret。

我们通过curl访问以下svc7服务:

# curl -k https://svc7.tonybai.com:30092
Hello, I am svc7 for ingress-controller demo!

此时,如果再用http方式去访问svc7,你会得到下面错误结果:

# curl http://svc7.tonybai.com:30092
<html>
<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<center>The plain HTTP request was sent to HTTPS port</center>
<hr><center>nginx/1.13.12</center>
</body>
</html>

四. svc8: 使用ssl termination,但nginx与backend服务之间采用加密传输(https)

前面说过,SSL termination配置场景中,负载均衡器和后端之间的流量是否加密,需要nginx另行配置。svc7采用了未加密的方式,nginx -> backend service存在安全风险,我们要将其改造为也通过https进行数据加密传输,于是有了svc8这个例子。

svc8对应的程序本身其实是上一篇文章《实践kubernetes ingress controller的四个例子》中的svc2的clone(唯一修改就是输出的log中的标识)。

在svc8对应的chart中,我们将values.yaml改为:

// ingress-controller-demo/charts/svc8/values.yaml

replicaCount: 1

image:
  repository: bigwhite/ingress-controller-demo-svc8
  tag: v0.1
  pullPolicy: Always

service:
  type: ClusterIP
  port: 443

ingress:
  enabled: true
  annotations:
    # kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/secure-backends: "true"
    kubernetes.io/ingress.class: ic3
  path: /
  hosts:
    - svc8.tonybai.com
  tls:
    - secretName: ingress-controller-demo-tls-secret
      hosts:
        - svc8.tonybai.com

... ...

与svc7不同点在于values.yaml中的新annotation: nginx.ingress.kubernetes.io/secure-backends: “true”。这个annotation让nginx以https的方式去访问backend service: svc8。安装svc8 chart后,ingress nginx controller为svc8生成的配置如下:

## start server svc8.tonybai.com
        server {
                server_name svc8.tonybai.com ;

                listen 80;

                listen [::]:80;

                set $proxy_upstream_name "-";

                listen 442 proxy_protocol   ssl http2;

                listen [::]:442 proxy_protocol  ssl http2;

                # PEM sha: 248951b75535e0824c1a7f74dc382be3447057b7
                ssl_certificate                         /ingress-controller/ssl/default-ingress-controller-demo-tls-secret.pem;
                ssl_certificate_key                     /ingress-controller/ssl/default-ingress-controller-demo-tls-secret.pem;

                ssl_trusted_certificate                 /ingress-controller/ssl/default-ingress-controller-demo-tls-secret-full-chain.pem;
                ssl_stapling                            on;
                ssl_stapling_verify                     on;

                location / {
                     ... ...
                        proxy_pass https://default-ic3-svc8-https;

                        proxy_redirect                          off;

                }

        }
        ## end server svc8.tonybai.com

        upstream default-ic3-svc8-https {
                least_conn;

                keepalive 32;

                server 192.168.28.14:8080 max_fails=0 fail_timeout=0;

        }

使用curl访问svc8服务(-k: 忽略对server端证书的校验):

# curl -k https://svc8.tonybai.com:30092
Hello, I am svc8 for ingress-controller demo!

五. svc9: 使用ssl passthrough, termination at pod

某些服务需要通过对client端的证书进行校验的方式,进行身份验证和授权,svc9就是这样一个对client certification进行校验的双向https校验的service。针对这种情况,ssl termination的配置方法无法满足需求,我们需要使用ssl passthrough的方案。

在ingress nginx controller开启ssl passthrough方案需要在ingress controller和ingress中都做一些改动。

首先我们需要为nginx-ingress-controller-ic3添加一个新的命令行参数:–enable-ssl-passthrough,并重新apply生效:

// ic3-mandatory.yaml
... ...
spec:
      serviceAccountName: nginx-ingress-serviceaccount
      containers:
        - name: nginx-ingress-controller-ic3
          image: quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.15.0
          args:
            - /nginx-ingress-controller
            - --default-backend-service=$(POD_NAMESPACE)/default-http-backend
            - --configmap=$(POD_NAMESPACE)/nginx-configuration-ic3
            - --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services-ic3
            - --udp-services-configmap=$(POD_NAMESPACE)/udp-services-ic3
            - --publish-service=$(POD_NAMESPACE)/ingress-nginx-ic3
            - --annotations-prefix=nginx.ingress.kubernetes.io
            - --enable-ssl-passthrough
            - --ingress-class=ic3
... ...

然后在svc9的chart中,为ingress添加新的annotation nginx.ingress.kubernetes.io/ssl-passthrough: “true”

// ingress-controller-demo/charts/svc9/values.yaml

replicaCount: 1

image:
  repository: bigwhite/ingress-controller-demo-svc9
  tag: v0.1
  pullPolicy: Always

service:
  type: ClusterIP
  port: 443

ingress:
  enabled: true
  annotations:
    kubernetes.io/ingress.class: ic3
    nginx.ingress.kubernetes.io/ssl-passthrough: "true"

  path: /
  hosts:
    - svc9.tonybai.com
  tls:
    - secretName: ingress-controller-demo-tls-secret
      hosts:
        - svc9.tonybai.com
... ...

isntall svc9 chart之后,我们用curl来访问以下svc9:

# curl -k  https://svc9.tonybai.com:30092
curl: (35) gnutls_handshake() failed: Certificate is bad

由于svc9程序对client端的certificate进行验证,没有提供client certificate的curl请求被拒绝了!svc9 pod的日志也证实了这一点:

2018/06/25 05:36:29 http: TLS handshake error from 192.168.31.10:38634: tls: client didn't provide a certificate

我们进入到ingress-controller-demo/src/svc9/client路径下,执行:

# curl -k --key ./client.key --cert ./client.crt https://svc9.tonybai.com:30092
Hello, I am svc9 for ingress-controller demo!

带上client.crt后,svc9通过了验证,返回了正确的应答。

client路径下是一个svc9专用的客户端,我们也可以执行该程序去访问svc9:

# go run client.go
Hello, I am svc9 for ingress-controller demo!

我们再看看采用ssl-passthrough方式下ingress-nginx controller的访问日志,当curl请求发出时,ingress-nginx controller并未有日志输出,因为没有在nginx处ssl termnination,从此也可以证实:nginx将client的ssl过程转发到pod中去了,即passthrough了。


51短信平台:企业级短信平台定制开发专家 https://51smspush.com/
smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

我的联系方式:

微博:https://weibo.com/bigwhite20xx
微信公众号:iamtonybai
博客:tonybai.com
github: https://github.com/bigwhite

微信赞赏:
img{512x368}

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

实践kubernetes ingress controller的四个例子

我之前并未使用过标准的Kubernetes ingress,而是自己实现了一个基于nginx的、类似ingress controller的服务入口管理程序nginx-kit。这个程序会部署到Kubernetes集群中,以Pod形式运行。该Pod由两个Container组成,一个Container放置了一个由脚本启动的nginx;另外一个Container中放置的是一个conf generator程序,它监听Kubernetes集群service对象的变更,并根据变更情况动态生成nginx的配置文件。第一个Container中的脚本会监听配置文件目录的变化,并reload配置文件信息实现Kubernetes内部服务对外暴露入口的动态管理。关于这个程序的详情可以参考我之前写的两篇文章:《Kubernetes集群中的Nginx配置热更新方案》和《为Kubernetes集群中服务部署Nginx入口服务》。

近期在使用ingress controller对内部服务入口的暴露进行动态管理,使用后发现我之前实现的nginx kit与ingress controller的实现之一: ingress-nginx简直是异曲同工。只是当时对Kubernetes理解还不够深入,在设计nginx-kit时格局“太小了”,只实现了一个满足内部需求的”ingress controller”,而不是一个通用的、可扩展的ingress controller:(。

好了!言归正传,这篇文章是ingress的入门文章,将通过四个例子来说明一下ingress controller的实现之一: ingress-nginx在不同服务暴露场景下的使用和配置方法。

一. 例子概述与环境准备

我们有四个例子,见下图中的a) ~ d):

img{512x368}

  • 例子a): 单ingress-nginx controller。通过ingress-svc1将内部服务svc1的http服务端口暴露到集群外,通过访问http://svc1.tonybai.com:30090即可访问svc1服务。
  • 例子b):单ingress-nginx controller。通过ingress-svc1将内部服务svc1的http服务端口暴露到集群外,通过访问http://svc1.tonybai.com:30090即可访问svc1服务;通过ingress-svc2将内部服务svc2的https服务端口暴露到集群外,通过访问http://svc2.tonybai.com:30090即可访问svc2服务。
  • 例子c):单ingress-nginx controller。除了暴露svc1和svc2之外,还暴露了集群内部的一个tcp(四层)服务:svc3,通过tcp连接svc3.tonybai.com:30070即可访问svc3服务。
  • 例子d): 多ingress-nginx controllers。其中nginx-ingress-controller-ic1负责暴露svc1、svc2和svc3服务(访问方式如上面所描述的);nginx-ingress-controller-ic2负责暴露svc4、svc5和svc6,其中svc4是一个http服务;svc5是https服务,svc6是一个tcp(四层)服务。

这里我们使用一个Kubernetes 1.10.3的集群来循序渐进地实践一下这四个例子。关于这四个例子的源码、chart包以及ingress controllers的yaml源文件在这里可以下载到:

$tree -L 2 ingress-controller-demo
ingress-controller-demo
├── charts
│   ├── svc1
│   ├── svc2
│   ├── svc3
│   ├── svc4
│   ├── svc5
│   └── svc6
├── manifests
│   ├── ic-common.yaml
│   ├── ic1-mandatory.yaml
│   ├── ic1-service-nodeport.yaml
│   ├── ic2-mandatory.yaml
│   └── ic2-service-nodeport.yaml
└── src
    ├── svc1
    ├── svc2
    ├── svc3
    ├── svc4
    ├── svc5
    └── svc6

其中:

  • src下面存放着svc1~svc6的源码(包括Dockerfile);
  • manifests下面存放的是ingress controllers的yaml源文件;
  • charts下面存放的是svc1~svc6的helm chart安装包源文件。

二. 创建第一个ingress-nginx controller

ingress controller有多种实现,其中应用较广的是kubernetes官方仓库中的ingress-nginx。在bare metal上安装ingress-nginx controller十分方便,只需执行下面命令即可:

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/mandatory.yaml

不过,考虑到我后续在环境中会安装多个ingress-nginx controller,我们需要对mandatory.yaml中的内容做些调整:

  • 首先明确多个ingress-nginx controller及其相关kubernetes object所在的namespace,默认为ingress-nginx,这里统一改为ingress-nginx-demo,yaml描述文件中所有的object的namespace也都改为ingress-nginx-demo,clusterrole、clusterrolebinding对象不归属于任何namespace,因此无需修改;

  • 接下来,将多个ingress-nginx controller能共用的kubernetes object的描述数据从mandatory.yaml中提取出来,放入ic-common.yaml中,包括:namespace: ingress-nginx-demo、deployment: default-http-backend、service: default-http-backend、serviceaccount: nginx-ingress-serviceaccount、clusterrole: nginx-ingress-demo-clusterrole、role: nginx-ingress-role、rolebinding: nginx-ingress-role-nisa-binding以及clusterrolebinding: nginx-ingress-demo-clusterrole-nisa-binding;

  • 将“缩水”后的mandatory.yaml改名为ic1-mandatory.yaml,并将其内容中的kubernetes object的name添加上“-ic1″后缀。

  • 在ic1-mandatory.yaml中nginx-ingress-controller的启动参数列表尾部添加“–ingress-class=ic1”:
// ic1-mandatory.yaml
... ...
    spec:
      serviceAccountName: nginx-ingress-serviceaccount
      containers:
        - name: nginx-ingress-controller-ic1
          image: quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.15.0
          args:
            - /nginx-ingress-controller
            - --default-backend-service=$(POD_NAMESPACE)/default-http-backend
            - --configmap=$(POD_NAMESPACE)/nginx-configuration-ic1
            - --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services-ic1
            - --udp-services-configmap=$(POD_NAMESPACE)/udp-services-ic1
            - --publish-service=$(POD_NAMESPACE)/ingress-nginx-ic1
            - --annotations-prefix=nginx.ingress.kubernetes.io
            - --ingress-class=ic1
... ...

  • ic-common.yaml中的nginx-ingress-role中的resourceNames列表中需添加两项:”ingress-controller-leader-ic1″和”ingress-controller-leader-ic2″:
// ic-common.yaml
... ...
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
  name: nginx-ingress-role
  namespace: ingress-nginx-demo
rules:
  - apiGroups:
      - ""
    resources:
      - configmaps
      - pods
      - secrets
      - namespaces
    verbs:
      - get
  - apiGroups:
      - ""
    resources:
      - configmaps
    resourceNames:
      # Defaults to "<election-id>-<ingress-class>"
      # Here: "<ingress-controller-leader>-<nginx>"
      # This has to be adapted if you change either parameter
      # when launching the nginx-ingress-controller.
      - "ingress-controller-leader-ic1"
      - "ingress-controller-leader-ic2"
... ...

这两个resouceName分别给两个ingress-controller使用,当每个ingress-controller存在多副本(replicas > 1)时,多副本会通过ingress-controller-leader-icX这个configmap资源来进行leader election(选主)。以ingress-controller-ic1为例,当存在多副本时,ingress-controller-ic1的启动日志:

I0621 09:13:20.646426       7 stat_collector.go:34] changing prometheus collector from  to default
I0621 09:13:20.648198       7 status.go:196] new leader elected: nginx-ingress-controller-ic1-7c9bc49cbb-kgjvz
I0621 09:13:20.752485       7 controller.go:177] ingress backend successfully reloaded...

不过,虽然存在leader,但业务流量却是负载分担的。

  • 为ingress-nginx controller pod创建nodeport类型service

如果只是部署了ingress controller,那么外部依然无法连上ingress controller,因为ingress controller自身还没有对应的service将自己暴露到集群外部。官方文档推荐使用NodePort方式,于是我们创建了ic1-service-nodeport.yaml,让流入host:30090的流量进入ingress controller service。

总结一下ingress-controller-ic1这个ingress controller的完整创建步骤:

kubectl apply -f ic-common.yaml
kubectl apply -f ic1-service-nodeport.yaml
kubectl apply -f ic1-mandatory.yaml

三. 创建例子a)

svc1是一个在容器8080端口提供http服务的服务程序。在例子a)中,我们在k8s集群中创建svc1,并创建ic1-svc1 ingress将svc1暴露在集群外面,外部请求通过svc1.tonybai.com:30090可以访问到svc1。而做到这一点,我们仅需要使用helm install一下svc1这个chart:

# helm install --name ic1-svc1 ./svc1
NAME:   ic1-svc1
LAST DEPLOYED: Thu Jun 21 20:39:25 2018
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1/Service
NAME      TYPE       CLUSTER-IP      EXTERNAL-IP  PORT(S)  AGE
ic1-svc1  ClusterIP  10.103.210.182  <none>       80/TCP   0s

==> v1beta2/Deployment
NAME      DESIRED  CURRENT  UP-TO-DATE  AVAILABLE  AGE
ic1-svc1  1        0        0           0          0s

==> v1beta1/Ingress
NAME      HOSTS             ADDRESS  PORTS  AGE
ic1-svc1  svc1.tonybai.com  80       0s

==> v1/Pod(related)
NAME                       READY  STATUS             RESTARTS  AGE
ic1-svc1-5ff84d7bff-5j7tb  0/1    ContainerCreating  0         0s

NOTES:
1. Get the application URL by running these commands:

http://svc1.tonybai.com/

svc1服务以及对应的ic1-svc1 ingress创建后,我们来测试一下:

# curl svc1.tonybai.com:30090
Hello, I am svc1 for ingress-controller demo!

结果符合预期。而这一切实现的关键在于ingress-controller-demo/charts/svc1/values.yaml:

... ...
ingress:
  enabled: true
  annotations:
    # kubernetes.io/ingress.class: nginx
    # kubernetes.io/tls-acme: "true"
    kubernetes.io/ingress.class: ic1
  path: /
  hosts:
    - svc1.tonybai.com
... ...

ingress的enabled改为true,helm才会创建svc1对应的ingress。annotations中的kubernetes.io/ingress.class: ic1很关键,设定ingress的这个annotation,可以使得该ingress归属于我们上面创建的nginx-ingress-controller-ic1 ingress controller,而其他ingress controller会忽略这个ingress。

我们再来看看 ingress-controller-ic1的后台日志,当添加svc1时,日志输出:

I0621 12:39:25.406331       7 event.go:218] Event(v1.ObjectReference{Kind:"Ingress", Namespace:"default", Name:"ic1-svc1", UID:"2176416f-7550-11e8-a0e8-00163e0cd764", APIVersion:"extensions", ResourceVersion:"1877656", FieldPath:""}): type: 'Normal' reason: 'CREATE' Ingress default/ic1-svc1
I0621 12:39:25.517915       7 controller.go:177] ingress backend successfully reloaded...
W0621 12:39:28.739708       7 controller.go:773] service default/ic1-svc1 does not have any active endpoints
I0621 12:39:34.262824       7 controller.go:168] backend reload required
I0621 12:39:34.371479       7 controller.go:177] ingress backend successfully reloaded...

nginx-ingress-controller-ic1会监听到service变化,并reload nginx。

我们可以通过下面命令查看nginx-ingress-controller-ic1内部的nginx的配置文件内容:

# kubectl exec nginx-ingress-controller-ic1-7c9bc49cbb-kgjvz -n ingress-nginx-demo -- cat /etc/nginx/nginx.conf

我们可以看到有关svc1的相关内容如下:

        upstream default-ic1-svc1-http {
                least_conn;

                keepalive 32;

                server 192.168.31.9:8080 max_fails=0 fail_timeout=0;

        }

        ## start server svc1.tonybai.com
        server {
                server_name svc1.tonybai.com ;

                listen 80;

                listen [::]:80;

                set $proxy_upstream_name "-";

                location / {

                       ... ...

                        set $proxy_upstream_name "default-ic1-svc1-http";

                        set $namespace      "default";
                        set $ingress_name   "ic1-svc1";
                        set $service_name   "ic1-svc1";

                       ... ...

                        proxy_pass http://default-ic1-svc1-http;

                        proxy_redirect                          off;

                }

        }
        ## end server svc1.tonybai.com

可一看出外部到svc1.tonybai.com:30090的流量被转到service ingress-nginx-ic1:80上,进而到达nginx pod的targetPort(80)上。

四. 创建例子b)

有了例子a)作为基础,理解接下来的例子就相对简单了。例子b)与a)最大的不同是svc2是一个https服务。外部通过http协议访问:svc2.tonybai.com:30090后,nginx-ingress-controller-ic1内部的nginx需要以https的方式去访问svc2。ingress-nginx ingress controller支持这种情况,仅需要在svcb的ingress annotations加上下面这个annotation:nginx.ingress.kubernetes.io/secure-backends: “true”

// ingress-controller-demo/charts/svc2/values.yaml
... ...
ingress:
  enabled: true
  annotations:
    # kubernetes.io/ingress.class: nginx
    # kubernetes.io/tls-acme: "true"
    nginx.ingress.kubernetes.io/secure-backends: "true"
    kubernetes.io/ingress.class: ic1
  path: /
  hosts:
    - svc2.tonybai.com
 ... ...

和例子a)一样,使用helm安装svc2这个chart后,svc2这个服务就暴露出来了:

# helm install --name ic1-svc2 ./svc2

# curl http://svc2.tonybai.com:30090
Hello, I am svc2 for ingress-controller demo!

五. 创建例子c)

svc3与前面两个服务均不同,因为它直接暴露的是四层的tcp服务。kubernetes ingress无法直接支持四层的服务端口暴露,我们需要在ingress controller上“动手脚”

首先,四层的暴露的端口不能与之前的七层端口30090重叠(因为不是通过ingress来暴露svc3服务的),我们需要一个新端口:30070,我们需要在ic1-service-nodeport.yaml中增加一组nodeport:

//ingress-controller-demo/manifests/ic1-service-nodeport.yaml

apiVersion: v1
kind: Service
metadata:
  name: ingress-nginx-ic1
  namespace: ingress-nginx-demo
spec:
  type: NodePort
  ports:
  - name: http
    port: 80
    targetPort: 80
    nodePort: 30090
    protocol: TCP
  - name: tcp
    port: 30070
    targetPort: 30070
    nodePort: 30070
    protocol: TCP
  selector:
    app: ingress-nginx-ic1

注意这里两组nodeport中的port不能一样,否则kubernetes会用下面的一组覆盖上面的那组。这里我们暴露30070这个nodeport,service的集群内port也是30070,后面的endpoint中的容器(即nginx-ingress-controller-ic1 pod)监听的也是30070。

接下来,要让nginx-ingress-controller-ic1 pod也监听30070,我们没法用ingress实现,但是ingress-nginx ingress controller支持通过一个名为:tcp-services-ic1的configmap来配置:

//ingress-controller-demo/manifests/ic1-mandatory.yaml
.... ...
spec:
      serviceAccountName: nginx-ingress-serviceaccount
      containers:
        - name: nginx-ingress-controller-ic1
          image: quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.15.0
          args:
            - /nginx-ingress-controller
            - --default-backend-service=$(POD_NAMESPACE)/default-http-backend
            - --configmap=$(POD_NAMESPACE)/nginx-configuration-ic1
            - --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services-ic1
            - --udp-services-configmap=$(POD_NAMESPACE)/udp-services-ic1
            - --publish-service=$(POD_NAMESPACE)/ingress-nginx-ic1
            - --annotations-prefix=nginx.ingress.kubernetes.io
... ...

在ic1-mandatory.yaml中,我们这样更新tcp-services-ic1 configmap的配置:

kind: ConfigMap
apiVersion: v1
metadata:
  name: tcp-services-ic1
  namespace: ingress-nginx-demo
data:
  30070: "default/ic1-svc3:8080"

大家可以看到,在configmap的data中,我们用了一个key:value的格式行,其中key就是nginx要暴露的端口:30070,value则为

<namespace/service name>:<service port>

格式的值,这里我们使用default名字空间下的ic1-svc3服务,服务端口8080。

重新apply ic1-mandatory.yaml和ic1-service-nodeport.yaml后,我们测试一下svc3服务:

# telnet svc3.tonybai.com 30070
Trying 127.0.0.1...
Connected to svc3.tonybai.com.
Escape character is '^]'.
hello
hello
world
world

svc3是一个echo服务,我们看到svc3 echo了我们输入的内容。

在nginx内部,30070是这样被暴露的:

stream {
        log_format log_stream [$time_local] $protocol $status $bytes_sent $bytes_received $session_time;

        access_log /var/log/nginx/access.log log_stream;

        error_log  /var/log/nginx/error.log;

        # TCP services

        upstream tcp-30070-default-ic1-svc3-8080 {

                server                  192.168.28.13:8080;

        }
        server {

                listen                  30070;

                listen                  [::]:30070;

                proxy_timeout           600s;
                proxy_pass              tcp-30070-default-ic1-svc3-8080;

        }

        # UDP services
}

六. 创建例子d)

在例子d)对应的图示中,我们建立了另外一个ingress-nginx ingress controller: nginx-ingress-controller-ic2,与nginx-ingress-controller-ic1 不同的是, nginx-ingress-controller-ic2的启动参数中含:

            - --ingress-class=ic2

用以区分ic1。ic2-mandatory.yaml和ic1-mandatory.yaml相比,就是将“rc1”字样整体替换为”ic2″即可。除此之外,有了ic1-service-nodeport.yaml的基础,ic2-service-nodeport.yaml内容也是“雷同”的。建立 nginx-ingress-controller-ic2步骤如下:

# kubectl apply -f ic2-service-nodeport.yaml
# kubectl apply -f ic2-mandatory.yaml

归属于nginx-ingress-controller-ic2的三个服务svc4、svc5和svc6等价于nginx-ingress-controller-ic1的svc1、svc2和svc3,这里就不赘述了。

# curl svc4.tonybai.com:30091
Hello, I am svc4 for ingress-controller demo!
# curl svc5.tonybai.com:30091
Hello, I am svc5 for ingress-controller demo!
# telnet  svc6.tonybai.com 30071
Trying 127.0.0.1...
Connected to svc6.tonybai.com.
Escape character is '^]'.
hello
hello
tony
tony

如果想使得ingress-nginx controller高可用,只需将其pod副本数量调大即可。


51短信平台:企业级短信平台定制开发专家 https://51smspush.com/
smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

我的联系方式:

微博:https://weibo.com/bigwhite20xx
微信公众号:iamtonybai
博客:tonybai.com
github: https://github.com/bigwhite

微信赞赏:
img{512x368}

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats