ingress | 伪架构师

Kubernetes 1.18 中 Ingress 的增强

Sun, 05 Apr 2020 17:41:31 +0800

作者：Rob Scott (Google) Christopher M Luciano (IBM)

原文：Improvements to the Ingress API in Kubernetes 1.18

Kubernetes 的 Ingress API 是大量 Ingress 控制器的基础，它们通过这一 API，用方便强大的方式为 Kubernetes 提供入站流量的支持。在 Kubernetes 1.18 中，这个 API 有了三个显著的变化：

新的 pathType 字段可以用来匹配 Ingress 路径。
IngressClass 资源能够指定控制器实现 Ingress 的方法。
主机名中可以使用通配符。

使用 Path Type 改进路径匹配

Path Type 的新概念让用户可以指定路径的匹配方式，目前有三种：

ImplementationSpecific（缺省）：这种匹配方式的行为取决于 IngressClass 控制器的实现。
Extract：以区分大小写的方式精确匹配整个 URL 路径。
Prefix：区分大消息，根据以 / 分割的 URL 元素进行前缀匹配。

使用 Ingress Class 扩展配置

Ingress 资源的设计初衷就是易用性，尝试使用简单的字段为所有应用提供支持。随着应用场景的不断增加，为了适应更广泛的需求，越来越多的 Ingress 控制器要靠大量的自定义注解来完成更复杂的配置。IngressClass 资源提供了一种替换部分注解的思路。

每个 IngressClass 中都指明了用于实现 Ingress 的控制器类型，并且可以引用自定义资源来使用更多参数。

apiVersion: networking.k8s.io/v1beta1
kind: IngressClass
metadata:
  name: external-lb
spec:
  controller: example.com/ingress-controller
  parameters:
    apiGroup: k8s.example.com/v1alpha
    kind: IngressParameters
    name: external-lb

指定 Ingess 的 Class

Ingress 规范中加入了 ingressClassName 字段，用来指定实现这个 Ingress 资源的的 IngressClass。

淘汰 Ingress 注解

在 1.18 加入 IngressClass 之前，需要在 Ingess 资源中使用 kubernetes.io/ingress.class 注解来指定 Ingress 控制器。在没有官方定义的情况下，这个注解被大量的 Ingress 控制器所支持。现在是时候淘汰他了。

设置缺省的 IngressClass

可以使用 ingressclass.kubernetes.io/is-default-class 注解，将其设置为 True，就代表所在的 IngressClass 为缺省控制器。没有显示指定 IngressClassName 的新的 Ingress 资源都会使用该控制器。

主机名通配符

很多 Ingress 控制器都支持通配符，例如 *.foo.com 可以匹配 app1.foo.com，但是直到目前为止，规范还是假设使用完全匹配的 FQDN。主机名现在也可以使用通配符了。

Host	Host Header	匹配?
`*.foo.com`	`*.foo.com`	根据后缀匹配
`*.foo.com`	`*.foo.com`	不匹配，通配符只能对应一个 DNS 项
`*.foo.com`	`foo.com`	不匹配，通配符只能对应一个 DNS 项

总结一下

新的 Ingress 功能扩展了配置能力，下面是一个例子，其中用到了上面提到的三个新特性：

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: example-ingress
spec:
  ingressClassName: external-lb
  rules:
  - host: *.example.com
    http:
      paths:
      - path: /example
        pathType: Prefix
        backend:
          serviceName: example-service
          servicePort: 80

Ingress 控制器支持

这个功能是 Kubernetes 1.18 中新增的，因此各种控制器都需要一段时间才能提供支持。请关注相关产品的官方文档。

Ingress 的未来

Ingress API 将在 1.19 进入稳定阶段。它会持续使用简单的方式为 Kubernetes 入站流量提供支持。这个 API 的设计重心就在于轻量和简单，但是更好的配置能力和更广泛的案例支持也是一个持续的努力方向。

目前还在开发一组高配置能力的 API。被称为 Service API 的新 API 会提供一种 Ingress 的替代方案。它的存在目的不是替代 Ingress，而是提供一种更具配置能力的新方案。请查看 Github 上的 Service API 项目。

Istio Helm Chart 详解 - Ingress

Tue, 09 Oct 2018 14:25:42 +0800

这是《Istio Helm Chart 详解》系列的第三篇。开始逐个 Chart 进行阅读。

前言

全局变量之后，接下来就是 Ingress 一节了，这个 Chart 只是个兼容选项，为 Istio 提供了传统 Kubernetes Ingress 的功能。ingress.enabled 变量用于在 requirements.yaml 中控制该 Chart 是否启用。

Chart.yaml

元数据文件，无需赘述。

autoscale.yaml

该文件用于处理该模块的 HPA 对象。引用变量如下：

ingress.autoscaleMin：水平伸缩的 Pod 数量下限，另外该变量被赋值的情况下才会渲染 HPA 对象。
ingress.autoscaleMax：水平伸缩的 Pod 数量上限。
Release.Namespace：HPA 对象所在的命名空间，使用 Istio 同一值。Release 是 Helm 的保留字，用于标识该 Release 所在的命名空间。

代码中我们看到，targetAverageUtilization 设置为固定值 80。

serviceaccount.yaml

这个模板用于为 Pod 生成 Service Account——istio-ingress-service-account。

其中引用变量：

global.imagePullSecrets：全局变量定义的数组，提供给 Service Account，在拉取镜像时使用。
Chart 和 Release 都是 Helm 的内置对象。

clusterrole.yaml 和 clusterrolebinding.yaml

Kubernetes RBAC 系统使用，这是一个集群范围内生效的 ClusterRole，声明了 Ingress 中需要的两组权限，并最终和 Service Account 进行绑定：

对于 extensions.thirdpartyresources 和 extensions.ingresses 对象的读写权限。
对 configmaps、pods、endpoints 和 services 对象的读取权限。

其中引用变量：

istio.name：定义在 istio 的 _helpers.tpl 中，如果没有使用 nameOverride 进行覆盖的话，会使用 Chart 名称。
Chart 和 Release 都是 Helm 的内置对象。

deployment.yaml

这一模板用于生成 Deployment，主体部分和 Ingress Gateway 类似，使用的都是 istio/proxyv2 镜像，参数稍有区别：

istio-proxy：proxy sidecar
ingress：proxy ingress
gateways：proxy router

其中引用变量：

istio.name：定义在 istio 的 _helpers.tpl 中，如果没有使用 nameOverride 进行覆盖的话，会使用 Chart 名称。
使用 Chart 和 Release 数据生成标签。这里可以看到，固定使用 istio: ingress 提供给 Gateway Selector 进行选择。
global.hub 和 global.tag：生成镜像地址。
replicaCount：控制 Pod 数量。
global.imagePullPolicy：拉取策略。
global.priorityClassName：PriorityClass
global.proxy.envoyStatsd.enabled：如果启用，则加入 --statsdUdpAddress 参数。

global.controlPlaneSecurityEnabled：根据这一设置确定 controlPlaneAuthPolicy 设置：

# 如果启用
- --controlPlaneAuthPolicy
- MUTUAL_TLS
- --discoveryAddress
- istio-pilot:15005
# 如果没启用
- --controlPlaneAuthPolicy
- NONE
- --discoveryAddress
- istio-pilot:8080

resources 和 globale.defaultResources：优先使用 Chart 自身的资源定义，如果没有则使用缺省定义。
nodeaffinity：包含节点亲和性定义模板。

另外这里还包含了对两个 secret 的可选加载：

istio.istio-ingress-service-account：用于 RBAC 的 Service Account 证书。
istio-ingress-certs：提供 https 服务时使用这一组证书。

service.yaml

这个模板用来为 Ingress 生成服务。

引用变量包括：

istio.name：定义在 istio 的 _helpers.tpl 中，如果没有使用 nameOverride 进行覆盖的话，会使用 Chart 名称。
使用 Chart 和 Release 数据生成标签。
service.loadBalancerIP：如果指定了 IP，则使用指定 IP。
service.type：如果没有负载均衡支持，可以考虑采用 NodePort 方式。
service.annotations：可以设置一系列的键值对，通过遍历的形式为 Service 对象生成注解。
service.ports：可以定义其它的非标准端口，以数组形式供 Helm 进行遍历，例如：
```
- port: 80
name: http
nodePort: 32000
- port: 443
name: https
```

常用链接

Helm 内置对象：https://docs.helm.sh/chart_template_guide/#built-in-objects

Istio 大入门 - Ingress

Sat, 11 Aug 2018 14:44:26 +0800

本文涉及细节较多，需读者对 Docker、Kubernetes 以及 Istio 有一定了解和实践经验，否则可能难于操作。

Istio 从 v1alpha3 开始，用 Ingress Gateway 组件替代了符合 Kubernetes 规范的 Ingress Controller，因此对入站流量具有了更大的控制能力，但是用法也有了较大不同。

安装：在使用 Helm 进行 Istio 部署的时候，需要使用下面的设置来启用 Ingress Gateway：

gateways:
  enabled: true
  istio-ingressgateway:
    enabled: true

基本概念

VirtualService 是流量控制的核心组件，起着承上（Gateway）启下（DestinationRule）的作用。这三种对象在本文中涉及的主要职责：

Gateway 对象：
- 选择 Gateway Ingress Controller。
- 设置端点开放方式：域名、端口、入站协议等。
DestinationRule：
- 定义负载均衡行为。
- 定义服务版本子集。
VirtualService：
- 根据 Gateway 选择服务版本。

根据 VirtualService 对象文档中的说明，VirtaulService 对象中的 gateways 字段的类型为 string[]，包括一或多个字符串值。如果省略该字段内容，会隐式的赋值为 ["mesh"]，mesh 网关指代所有的网格内通信。如果要对外提供服务，就需要定义 Gateway 对象，并在 gateways 字段中进行赋值。

注意，一旦在 gateways 中填写了非缺省的对象名称，要继续对内部通信进行流量控制，必须显式的将内置的 mesh 对象名称也加入到列表之中。

准备工作

环境准备

安装和部署 Kubernetes 以及 Istio，并启用 Ingress Gateway 支持。
将备用的两个域名（假设为 flask.example2.com 以及 flask.example1.com）指向 istio-ingressgateway 服务的外部 IP。
为测试域名生成 HTTPS 证书。

域名准备

工作负载

首先编写一个基于 Flask 的 Python 脚本，并打入镜像，脚本功能很简单，显示环境变量中的 “VERSION”。
接下来编写 Dockerfile，安装 Python3、Flask，并进行构建和推送。
编写 Kubernetes 工作负载文件，常见的 Deployment + Service 模式。
在 Kubernetes 上运行工作负载。

以上涉及代码可以在页面尾部获取。

目标规则定义

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: flask
spec:
  host: flask
  trafficPolicy:
    loadBalancer:
      simple: RANDOM
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

这里根据工作负载中的标签，将 flask 服务拆分为 v1 和 v2 两个版本。

在外网开放服务

这里我们设计，将所有外网请求经过 flask.example1.com 路由到 v2 版本上。

首先要编写一个 Gateway 定义：

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: flask-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
    - port:
        number: 80
        name: http
        protocol: HTTP
      hosts:
        - flask.example1.com
        - flask.example2.com

这里定义了一个 Gateway，其中要求 80 端口响应两个域名的请求。接下来定义一个 VirtualService：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
    name: flask
spec:
    hosts:
    - "flask.example1.com"
    gateways:
    - flask-gateway
    http:
    - route:
        - destination:
            host: flask
            subset: v2

然后使用 curl 进行访问：curl http://flask.example1.com 会发现返回了字符串 “v2”，证明我们的定义生效了，该域名指向了 v2 服务。

再用 curl 访问第二个域名 curl http://flask.example2.com，会看到返回了 404，这是因为我们的 Gateway 虽然接收了请求，但是并没有服务路由完成这一请求。那么可以再定义一个 VirtualService，让 flask.example2.com 域名指向 v1：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
    name: flask1
spec:
    hosts:
    - "flask.example2.com"
    gateways:
    - flask-gateway
    http:
    - route:
        - destination:
            host: flask
            subset: v1

再次使用 curl http://flask.example2.com，访问，会看到返回结果变成了 v1，证明我们的服务定义生效了。

将一个域名服务升级为 tls

随意修改一个需求，要求开放 flask.example2.com 为 http，而 flask.example1.com 升级为 https，既然涉及 https，就要用到证书，官方文档（中文版哦）陈述如下：

具体说来就是使用 kubectl 命令在命名空间 istio-system 中创建一个 secret 对象，命名为 istio-ingressgateway-certs。Istio 网关会自动载入这个 secret。这里的 secret 必须在 istio-system 命名空间中，并且命名为 istio-ingressgateway-certs，否则就不会被正确载入，也就无法 Istio gateway 中使用了。

接着是使用命令为 flask.example1.com 的证书创建 Secret：

$ kubectl create -n istio-system secret tls \
    istio-ingressgateway-certs \
    --key key.pem --cert cert.pem

最后修改我们的 Gateway 定义：

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: flask-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
    - port:
        number: 80
        name: http
        protocol: HTTP
      hosts:
        - flask.example2.com
    - port:
        number: 443
        name: https-rocks
        protocol: HTTPS
      tls:
        mode: SIMPLE
        serverCertificate: /etc/istio/ingressgateway-certs/tls.crt
        privateKey: /etc/istio/ingressgateway-certs/tls.key
      hosts:
        - flask.example1.com

然后再次使用 curl 分别访问 https://flask.example1.com/version 以及 http://flask.example2.com/version，会发现返回了预期结果，而一旦错用 http 和 https，就会出现异常，这是因为我们的 Gateway 限制了端口。

这里如此操作的原因可以在他的部署中找到：

$ kubectl get deployment istio-ingressgateway \
    -o yaml -n istio-system

返回的 YAML 中会有这么一段

...
- mountPath: /etc/istio/ingressgateway-ca-certs
    name: ingressgateway-ca-certs
    readOnly: true
...
volumes:
- name: ingressgateway-certs
secret:
    defaultMode: 420
    optional: true
    secretName: istio-ingressgateway-certs
...

上方代码可以看到，Ingress Gateway 中用可选方式加载了一个名称为 istio-ingressgateway-certs 的 Secret，并 Mount 到了 /etc/istio/ingressgateway-ca-certs 目录之中，这就是上文中要求我们固定 Secret 名称和命名空间的原因。众所周知，tls 类型的 Secret 加载后会成为 tls.key 和 tls.crt 两个文件，因此在我们的 Gateway 定义中就使用了 /etc/istio/ingressgateway-certs/tls.crt 这样的文件名。

所有域名都升级为 tls

根据上一节的描写，不难发现按照官方文档，一个 Gateway 是无法处理两个域名的 https 的：

tls secret 只能包含一个证书对。
泛域名证书可以完成这一任务，但因为 Envoy 的限制，这里无法同时使用两个泛域名。

讨论到这里就很明显了，关键在于如何加载多个证书对，可以修改前面所说的加载指令为加载多个 Secret，或者干脆换成 Configmap，当然这样会引起服务中断，Configmap 用于存放证书也略显粗糙——好在我们还可以换用 Generic 类型的证书，这里我们可以删除原有 Secret 重新创建：

kubectl delete secret istio-ingressgateway-certs \
    -n istio-system

kubectl create secret generic  \
    istio-ingressgateway-certs \
    -n istio-system \
    --from-file=rocks-crt.pem \
    --from-file=rocks-key.pem \
    --from-file=xyz-crt.pem \
    --from-file=xyz-key.pem

接下来改造我们的 Gateway 定义：

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: flask-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 443
      name: https-rocks
      protocol: HTTPS
    tls:
      mode: SIMPLE
      serverCertificate: /etc/istio/ingressgateway-certs/rocks-crt.pem
      privateKey: /etc/istio/ingressgateway-certs/rocks-key.pem
    hosts:
    - "flask.example1.com"
  - port:
      number: 443
      name: https-xyz
      protocol: HTTPS
    tls:
      mode: SIMPLE
      serverCertificate: /etc/istio/ingressgateway-certs/xyz-crt.pem
      privateKey: /etc/istio/ingressgateway-certs/xyz-key.pem
    hosts:
    - "flask.example2.com"

这样一来，我们开放了两个 HTTPS 端口，各自使用不同的证书，分别都可以通过 curl 命令获得正确结果了。

补充

tls.mode 实际还支持双向和透传两种方式，都可以在流量控制参考中找到相关内容。

涉及链接

Istio 流量控制参考：https://istio.io/docs/reference/config/istio.networking.v1alpha3/
用 HTTPS 加密 Gateway：https://istio.io/zh/docs/tasks/traffic-management/secure-ingress/

代码

Python 脚本

#!/usr/bin/env python3
# -*- coding: UTF-8 -*-

from flask import Flask
import os

app = Flask(__name__)

@app.route("/")
def hello_world():
    return "Hello, World!"

@app.route("/version")
def getversion():
    return os.getenv("VERSION")
if __name__ == "__main__":
    app.run(host="0.0.0.0", port=80, debug=True)

Dockerfile

FROM alpine
RUN  apk add --update --no-cache python3 && \
  mkdir /web && \
  pip3 install Flask
COPY server.py /web
CMD "/web/server.py"

Kubernetes 工作负载

apiVersion: v1
kind: Service
metadata:
  name: flask
  labels:
    app: flask
spec:
  ports:
    - name: http
      port: 80
  selector:
    app: flask
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: flask-v1
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: flask
        version: v1
    spec:
      containers:
        - image: 'abc:25000/python-flask-server:v2'
          imagePullPolicy: IfNotPresent
          name: flask
          env:
            - name: VERSION
              value: v1
          ports:
            - containerPort: 80
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: flask-v2
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: flask
        version: v2
    spec:
      containers:
        - image: 'abc:25000/python-flask-server:v2'
          imagePullPolicy: IfNotPresent
          name: flask
          env:
            - name: VERSION
              value: v2
          ports:
            - containerPort: 80

Kubernetes 1.2 中利用 Ingress 简化复杂网络

Wed, 06 Apr 2016 07:50:05 +0800

原文：Kubernetes 1.2 and simplifying advanced networking with Ingress

在 Kubernetes 中，服务和 Pod 的 IP 地址缺省只能被集群网络路由。所有边缘路由器传来的流量要么被丢弃，要么被转向。在 Kubernetes 中，我们对 Ingress 对象做了改进，用于简化传入连接进入集群服务的过程。对其进行配置，能够给服务外部可达的 URL，负载均衡，Terminate SSL，提供具名虚拟主机等大量功能。

Ingress Controller

如今，受容器或者虚拟机的影响，对 Web 服务器或者负载均衡的配置变得麻烦了。多数的 Web 服务器配置文件很像。虽说有些应用有些古怪，但是总的说来还是可以通过一些逻辑来达到目的的。在 Kuberntes 1.2 中，Ingress 实现了这些想法，Ingress 控制器就是用于处理这些特别的 Ingress “类” （可能是负载均衡的一个实例，或者复杂一些的提供 GSLB、CDN、DDoS 保护等功能的前端）中的这些个性的东西。Ingress Controller 是一个守护进程，以 Kuberntes Pod 的形式进行部署，他会监控 API 服务的 /ingress 终结点来获取对 Ingress 资源的更新。他的任务就是实现 Ingress 请求。

为了运行下面的例子，你的 Kubternetes 集群必须仅有一个支持 TLS 的 Ingress 控制器。如果你的集群运行在云提供商环境中，首先查找一下 “kube-system” 命名空间，查找 Ingress 控制器的 RC。如果没有的话，需要部署一个 nginx 控制器或者用不到 100 行代码自行实现。

务必花费少许时间来了解一下现存控制器的限制（ GCE, nginx ）。

TLS termination 和 HTTP 负载均衡

Ingress 用于承接服务，所以很适合做负载均衡以及中心化的安全配置。如果你熟悉 Go 语言，Ingress 在集群中扮演了 net/http’s “Server” 的角色。下面的例子示范了如何配置 TLS termination。负载均衡是 Ingress 的必选项目，所以只要创建了这一对象，就有了负载均衡能力。

首先创建一个测试服务。我们会运行一个简单的 Echo 服务器，用来告知我们正在运行的内容（源代码）：

$ kubectl run echoheaders 
--image=gcr.io/google_containers/echoserver:1.3 --port=8080
$ kubectl expose deployment echoheaders --target-port=8080 
--type=NodePort

如果你是在云服务提供商提供的集群上运行，确认你可以由外网通过 Nodeport 访问到这一服务。

$ NODE_IP=$(kubectl get node `kubectl get po -l run=echoheaders 
--template '{{range .items}}{{.spec.nodeName}}{{end}}'` --template
'{{range $i, $n := .status.addresses}}{{if eq $n.type 
"ExternalIP"}}{{$n.address}}{{end}}{{end}}')
$ NODE_PORT=$(kubectl get svc echoheaders --template '{{range $i, $e 
:= .spec.ports}}{{$e.nodePort}}{{end}}')
$ curl $NODE_IP:$NODE_PORT

这是一个简单的检查，如果最后一步失败了，可能需要设置一下防火墙规则。

接下来创建我们的 TLS secret：

$ openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout 
/tmp/tls.key -out /tmp/tls.crt -subj "/CN=echoheaders/O=echoheaders"
$ echo "
apiVersion: v1
kind: Secret
metadata:
name: tls
data:
tls.crt: `base64 -w 0 /tmp/tls.crt`
tls.key: `base64 -w 0 /tmp/tls.key`
" | kubectl create -f

配置 Ingress：

$ echo "
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: test
spec:
tls:
- secretName: tls
backend:
    serviceName: echoheaders
    servicePort: 8080
" | kubectl create -f -

这样就得到了一个负载均衡 IP：

$ kubectl get ing 
NAME      RULE      BACKEND            ADDRESS         AGE
test      -         echoheaders:8080   130.X.X.X      4m

如果等到 Ingress 控制器把你的后端设置为健康，会看到访问该 IP 80 端口的请求会被重定向到 443 端口，并会使用指定的 TLS 进行验证。

未来

可以在 Ingress API 获得更多的信息。Ingress 还在 Beta 阶段，我们期待你的反馈。你也可以贡献控制器或者 API 代码。所有跟 “Ingress” 的内容都可以，包含 DNS、不同的 TLS 模式、SNI、4 层负载均衡、内容缓存、更多的算法和健康检查等。