8.6. 使用 TLS 证书保护映射的服务
8.6.1. 使用 TLS 证书保护带有自定义域的服务
为 Knative 服务配置了自定义域后,您可以使用 TLS 证书来保护映射的服务。要做到这一点,您必须创建一个 Kubernetes TLS secret,然后更新 DomainMapping
CR 以使用您创建的 TLS secret。
如果您将 net-istio
用于 Ingress,并使用 security.dataPlane.mtls: true
通过 SMCP 启用 mTLS,Service Mesh 为 *.local
主机部署 DestinationRule
,这代表不允许对 OpenShift Serverless 使用 DomainMapping
。
要临时解决这个问题,部署 PeerAuthentication
来启用 mTLS,而不是使用 security.dataPlane.mtls: true
。
先决条件
-
为 Knative 服务配置了自定义域,并有一个正常工作的
DomainMapping
CR。 - 您有来自证书授权机构供应商或自签名证书的 TLS 证书。
-
您已从证书授权中心(CA)提供商或自签名证书获取
cert
和key
文件。 -
安装 OpenShift CLI (
oc
) 。
流程
创建 Kubernetes TLS secret:
$ oc create secret tls <tls_secret_name> --cert=<path_to_certificate_file> --key=<path_to_key_file>
将
networking.internal.knative.dev/certificate-uid: <id>'
标签添加到 Kubernetes TLS secret 中:$ oc label secret <tls_secret_name> networking.internal.knative.dev/certificate-uid="<id>"
如果使用第三方 secret 供应商(如 cert-manager),您可以配置 secret manager 来自动标记 Kubernetes TLS secret。cert-manager 用户可以使用提供的 secret 模板自动生成带有正确标签的 secret。在本例中,secret 过滤仅基于键,但这个值可以存储有用的信息,如 secret 包含的证书 ID。
注意Red Hat OpenShift 的 cert-manager Operator 只是一个技术预览功能。如需更多信息,请参阅 为 Red Hat OpenShift 安装 cert-manager Operator 文档。
更新
DomainMapping
CR,以使用您创建的 TLS secret:apiVersion: serving.knative.dev/v1alpha1 kind: DomainMapping metadata: name: <domain_name> namespace: <namespace> spec: ref: name: <service_name> kind: Service apiVersion: serving.knative.dev/v1 # TLS block specifies the secret to be used tls: secretName: <tls_secret_name>
验证
验证
DomainMapping
CR 状态是否为True
,输出中的URL
列显示了使用 schemehttps
的映射域:$ oc get domainmapping <domain_name>
输出示例
NAME URL READY REASON example.com https://example.com True
可选: 如果服务公开,请运行以下命令验证该服务是否可用:
$ curl https://<domain_name>
如果证书是自签名的,请通过在
curl
命令中添加-k
标志来跳过验证。
8.6.2. 使用 secret 过滤改进 net-kourier 内存用量
默认情况下,Kubernetes client-go
库的 informers 实施会获取特定类型的所有资源。当有很多资源可用时可能会导致大量开销。这可能会导致因为内存泄露的问题导致 Knative net-kourier
ingress 控制器在大型集群中失败。但是,Knative net-kourier
ingress 控制器提供了一个过滤机制,它可让控制器只获取 Knative 相关的 secret。您可以通过将环境变量设置为 KnativeServing
自定义资源 (CR) 来启用此机制。
如果启用 secret 过滤,则所有 secret 都需要使用 networking.internal.knative.dev/certificate-uid: "<id>"
。否则,Knative Serving 不会检测到它们,这会导致失败。您必须标记新的和现有的 secret。
先决条件
- 在 OpenShift Container Platform 上具有集群管理员权限,或在 Red Hat OpenShift Service on AWS 或 OpenShift Dedicated 上具有集群或专用管理员权限。
- 您创建或具有创建应用程序和其他工作负载的角色和权限的项目。
- 安装 OpenShift Serverless Operator 和 Knative Serving。
-
安装 OpenShift CLI (
oc
) 。
流程
对于
KnativeServing
CR 中的net-kourier-controller
,将ENABLE_SECRET_INFORMER_FILTERING_BY_CERT_UID
变量设置为true
:KnativeServing CR 示例
apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: knative-serving namespace: knative-serving spec: deployments: - env: - container: controller envVars: - name: ENABLE_SECRET_INFORMER_FILTERING_BY_CERT_UID value: 'true' name: net-kourier-controller