用Backyards进行Istio配置验证的具体流程

迪鲁宾
109 阅读7分钟

如果你是一个活跃的Istio用户，那么很有可能Istio的配置参考在你的浏览器中被添加了书签，你已经反复阅读了VirtualServices ，和ServiceEntries 的页面，但仍然要努力在你的网状结构中设置甚至简单的配置。

Istio的自定义资源配置是非常强大和灵活的，但因过于复杂而臭名昭著。在最好的情况下，其YAML由列表、交叉引用、冲突字段和通配符组成。

尽管Istio的维护者意识到了这种过度的复杂性，并且--至少在过去的几个版本中--试图将用户友好性作为重点，Istio仍然经常将我们困在细枝末节和不确定性的泥潭中。我们的自定义资源从一年前的50个减少到了25个，有些现在有了有用的CLI功能，如istioctl analyze ，但我们觉得还有更多的工作要做。

这就是为什么我们在我们的服务网状平台Backyards上增加了我们自己的验证子系统。Backyards服务网状平台与上游Istio保持完全兼容，但也扩展了其功能集，同时通过新的抽象层避免了锁定。这方面的一个很好的例子是其验证子系统，它将Istio的验证系统提升到一个全新的水平。它通过考虑集群状态，作为一个整体，而不仅仅是Istio的配置来做到这一点。

Backyards是Banzai Cloud的多云和混合云服务网格平台，用于构建和观察现代基础设施。它是一个Istio发行版和SRE工具箱，是一个整洁的软件包，可以让你从构建服务网到根据Envoy产生的指标形成SLO。

在Backyards中验证Istio配置 🔗︎

验证结果可以在用户界面的Overview 页面上看到。

image.png

也可以从CLI工具中检查验证情况，如下所示。

❯ backyards analyze
✓ 0 validation errors found

UI对检测到的每个错误都会显示配置的相关部分，只要适用。

image.png

验证示例 ︎ 🔗︎

Backyards对配置的各个方面进行了大量的验证检查，包括语法上和语义上。验证检查是不断策划的，每次发布都会增加新的检查。在这篇文章中，我们将介绍几个例子，以显示这个功能有多么有用。

Sidecar注入模板验证 🔗︎

这个检查可以验证环境中是否有任何pods以过时的sidecar代理图像或配置运行。在这个例子中，sidecar代理图像的全局配置设置从banzaicloud/istio-proxyv2:1.7.3-bzc 改为banzaicloud/istio-proxyv2:1.7.3-bzc.1 。

❯ backyards analyze --namespace backyards-demo
pod backyards-demo/frontpage-v1-8f9d69c97-phv4k:
    Cluster: master
    Error: sidecar injector proxy image mismatch
        Control Plane: cp-v17x.istio-system
        Error ID: pod/sidecar-check/sidecar/proxy-image-mismatch
        Context:
            podImage: banzaicloud/istio-proxyv2:1.7.3-bzc
            configImage: banzaicloud/istio-proxyv2:1.7.3-bzc.1
...
...
✗ 4 validation errors were found

这有助于操作人员获得环境内过时的代理信息。

网关端口协议配置冲突验证 🔗︎

这个例子展示了对在不同的Gateway 资源中设置冲突的端口配置这一常见错误的检查，这不会被Istio的内置验证所拒绝，但会在入口处引起不需要的行为。同一入口网关的9443 端口在一个资源中被设置为TCP ，而在另一个资源中被设置为TLS 。

下面的YAML被应用了。

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: demo-gw-port-conflict-01
  namespace: istio-system
spec:
  selector:
    app: demo-gw
    gateway-name: demo-gw
    gateway-type: ingress
  servers:
  - hosts:
    - demo1.example.com
    port:
      name: tcp
      number: 9443
      protocol: TCP
---
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: demo-gw-port-conflict-02
  namespace: istio-system
spec:
  selector:
    app: demo-gw
    gateway-name: demo-gw
    gateway-type: ingress
  servers:
  - hosts:
    - demo2.example.com
    port:
      name: tls
      number: 9443
      protocol: TLS
    tls:
      serverCertificate: /certs/cert.pem
      privateKey: /certs/key.pem
      mode: SIMPLE

通过运行CLI工具的analyze 命令检查配置的有效性。

❯ build/backyards-cli analyze --namespace istio-system
gateway istio-system/demo-gw-port-conflict-01:
    Cluster: master
    Error: Conflicting gateway port protocols
        Control Plane: cp-v17x.istio-system
        Error ID: gateway/port/gateway/port/protocol-conflict
        Path: servers[0]
        Context:
            port: 9443
            protocol: TCP

gateway istio-system/demo-gw-port-conflict-02:
    Cluster: master
    Error: Conflicting gateway port protocols
        Control Plane: cp-v17x.istio-system
        Error ID: gateway/port/gateway/port/protocol-conflict
        Path: servers[0]
        Context:
            port: 9443
            protocol: TLS

✗ 2 validation errors found

这个结果准确地显示了问题，并为操作员提供了所有必要的信息，以便迅速找出配置中的问题。

配置一个以上的网关，使用相同的TLS证书，将导致利用HTTP/2连接重用的浏览器（即大多数浏览器）在已经建立与另一主机的连接后访问第二个主机时产生404错误。

让我们应用以下资源来演示这个问题是如何运作的。

apiVersion: istio.banzaicloud.io/v1beta1
kind: MeshGateway
metadata:
  labels:
    app: demo-gw
  name: demo-gw
  namespace: istio-system
spec:
  labels:
    app: demo-gw
  maxReplicas: 1
  minReplicas: 1
  ports:
  - name: http2
    port: 80
    protocol: TCP
    targetPort: 8080
  - name: https
    port: 443
    protocol: TCP
    targetPort: 8443
  replicaCount: 1
  runAsRoot: true
  serviceType: LoadBalancer
  type: ingress
---
apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
metadata:
  name: selfsigned-issuer
spec:
  selfSigned: {}
---
apiVersion: cert-manager.io/v1alpha2
kind: Certificate
metadata:
  name: example-wildcard-cert
  namespace: istio-system
spec:
  secretName: example-wildcard-cert
  duration: 2160h # 90d
  renewBefore: 360h # 15d
  commonName: "test wildcard certifcate"
  isCA: false
  keySize: 2048
  keyAlgorithm: rsa
  keyEncoding: pkcs1
  usages:
    - server auth
  dnsNames:
  - "*.example.com"
  issuerRef:
    name: selfsigned-issuer
    kind: ClusterIssuer
    group: cert-manager.io
---
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: demo-gw-tls-conflict-01
  namespace: istio-system
spec:
  selector:
    app: demo-gw
    gateway-name: demo-gw
    gateway-type: ingress
  servers:
  - hosts:
    - demo1.example.com
    port:
      name: https
      number: 443
      protocol: HTTPS
    tls:
      credentialName: example-wildcard-cert
      httpsRedirect: false
      mode: SIMPLE
---
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: demo-gw-tls-conflict-02
  namespace: istio-system
spec:
  selector:
    app: demo-gw
    gateway-name: demo-gw
    gateway-type: ingress
  servers:
  - hosts:
    - demo2.example.com
    port:
      name: https
      number: 443
      protocol: HTTPS
    tls:
      credentialName: example-wildcard-cert
      httpsRedirect: false
      mode: SIMPLE

创建了以下资源。

  • 一个入口网关
  • 一个*.example.com通配符证书
  • 两个Gateway ，这两个资源都指定了同一个通配符证书

通过在CLI工具中运行analyze 命令检查配置的有效性。

❯ backyards analyze --namespace istio-system
gateway istio-system/demo-gw-demo1:
    Cluster: master
    Error: multiple gateways configured with same TLS certificate
        Control Plane: cp-v17x.istio-system
        Error ID: gateway/reused-cert/gateway/reused-cert
        Path: port[443]
        Context:
            reusedCertificateSecret: secret:master:istio-system:example-wildcard-cert

gateway istio-system/demo-gw-demo2:
    Cluster: master
    Error: multiple gateways configured with same TLS certificate
        Control Plane: cp-v17x.istio-system
        Error ID: gateway/reused-cert/gateway/reused-cert
        Path: port[443]
        Context:
            reusedCertificateSecret: secret:master:istio-system:example-wildcard-cert

✗ 2 validation errors were found

analyze 命令也可以产生JSON输出。

❯ backyards analyze --namespace istio-system -o json
{
  "gateway.networking.istio.io:master:istio-system:demo-gw-demo1": [
    {
      "checkID": "gateway/reused-cert",
      "istioRevision": "cp-v17x.istio-system",
      "subjectContextKey": "gateway.networking.istio.io:master:istio-system:demo-gw-demo1",
      "passed": false,
      "error": {},
      "errorMessage": "multiple gateways configured with same TLS certificate"
    }
  ],
  "gateway.networking.istio.io:master:istio-system:demo-gw-demo2": [
    {
      "checkID": "gateway/reused-cert",
      "istioRevision": "cp-v17x.istio-system",
      "subjectContextKey": "gateway.networking.istio.io:master:istio-system:demo-gw-demo2",
      "passed": false,
      "error": {},
      "errorMessage": "multiple gateways configured with same TLS certificate"
    }
  ]
}

未来计划 🔗︎

通过Backyards，你已经可以通过今天的验证来识别众多的配置问题，但我们正计划将这一功能再向前推进一步。如果能在错误配置被应用到集群之前，而不是之后，就能抓住这些错误配置，那就太好了。

无论是从用户界面还是从CLI工具，Backyards都可以通过设置流量管理规则、改变相互TLS设置或限制Envoy代理的出站配置来操纵Istio配置资源。当用户操纵任何这些Istio资源时，即使在集群上实际改变Istio资源之前，也会针对将应用这些操纵的新假设集群状态运行验证。如果在这种状态下，出现了任何验证问题，那么用户就会被通知，并可以取消或修改他/她即将进行的错误修改。

另一个用例是在GitOps工作流程中，Istio资源将通过PR被修改。在这种情况下，在一个自动化的工作中，可以针对新的假设集群状态运行backyards analyze 命令，如果发现任何问题，那么工作就会失败，甚至可以阻止PR的合并。

随着这些功能的实施，将有可能及早发现问题，Backyards用户将进一步得到保护，避免潜在的停机和Istio错误配置。

启示 🔗︎

这只是冰山一角。Backyards的验证子系统提供了许多检查，导致更快的根本原因分析和更稳定的服务网的运行。

在你自己的集群上检查Backyards的运行情况吧!

avatar
文章
阅读
粉丝