apiVersion: config.openshift.io/v1
kind: Ingress
metadata:
name: cluster
spec:
domain: apps.openshiftdemos.com
Ingress Operator 实现 IngressController API,是启用对 OpenShift 专用集群服务的外部访问的组件。
创建 OpenShift 专用集群时,在集群上运行的 Pod 和服务都会分配自己的 IP 地址。这些 IP 地址可被附近运行的其他 Pod 和服务访问,但外部客户端无法访问。
Ingress Operator 通过部署和管理一个或多个基于 HAProxy 的 Ingress Controller 来处理路由,从而使外部客户端能够访问您的服务。Red Hat 站点可靠性工程师 (SRE) 管理 OpenShift 专用集群的 Ingress Operator。虽然您无法更改 Ingress Operator 的设置,但您可以查看默认 Ingress Controller 的配置、状态和日志,以及 Ingress Operator 的状态。
安装程序生成一个包含 config.openshift.io API 组中 Ingress 资源的资源文件 cluster-ingress-02-config.yml。
Ingress 资源的 YAML 定义apiVersion: config.openshift.io/v1
kind: Ingress
metadata:
name: cluster
spec:
domain: apps.openshiftdemos.com
安装程序将此资源文件存储在 manifests/ 目录中的 cluster-ingress-02-config.yml 文件中。此 Ingress 资源定义了集群范围的 Ingress 配置。此 Ingress 配置的使用方式如下:
Ingress Operator 使用集群 Ingress 配置中的域名作为默认 Ingress Controller 的域名。
OpenShift API Server 操作符使用集群 Ingress 配置中的域名。此域名也用于为未指定显式主机的 Route 资源生成默认主机。
IngressController 自定义资源 (CR) 包含可选的配置参数,您可以配置这些参数以满足组织的特定需求。
| 参数 | 描述 | ||||
|---|---|---|---|---|---|
|
如果为空,则默认值为 |
||||
|
|
||||
|
对于云环境,请使用 您可以配置以下
如果未设置,则默认值基于
对于大多数平台,可以更新
如果需要在集群部署后更新
|
||||
|
密钥必须包含以下键和数据:* 如果未设置,则会自动生成并使用通配符证书。证书对 Ingress Controller 的 正在使用的证书(无论是生成的还是用户指定的)都会自动与 OpenShift Dedicated 内置 OAuth 服务器集成。 |
||||
|
|
||||
|
|
||||
|
如果未设置,则使用默认值。
|
||||
|
如果未设置,则默认值基于 使用 Ingress Controller 的最小 TLS 版本为
|
||||
|
|
||||
|
|
||||
|
|
||||
|
通过设置 默认情况下,策略设置为
通过设置 这些调整仅应用于明文、边缘终止和重新加密路由,并且仅在使用 HTTP/1 时应用。 对于请求头,这些调整仅应用于具有
|
||||
|
|
||||
|
|
||||
|
对于要捕获的任何 Cookie,以下参数必须位于您的
例如
|
||||
|
|
||||
|
|
||||
|
|
||||
|
这些连接来自负载均衡器健康探测或 Web 浏览器推测性连接(预连接),可以安全地忽略。但是,这些请求可能是由网络错误引起的,因此将此字段设置为 |
TLS 安全配置文件为服务器提供了一种方法,可以用来规范连接客户端在连接到服务器时可以使用哪些密码。
您可以使用 TLS(传输层安全)安全配置文件来定义各种 OpenShift Dedicated 组件所需的 TLS 密码。OpenShift Dedicated TLS 安全配置文件基于 Mozilla 推荐的配置。
您可以为每个组件指定以下 TLS 安全配置文件之一
| 配置文件 | 描述 | ||
|---|---|---|---|
|
此配置文件适用于旧版客户端或库。该配置文件基于 旧版向后兼容性 推荐的配置。
|
||
|
此配置文件是大多数客户端的推荐配置。它是 Ingress Controller、kubelet 和控制平面的默认 TLS 安全配置文件。该配置文件基于 中间版兼容性 推荐的配置。
|
||
|
此配置文件适用于不需要向后兼容性的现代客户端。该配置文件基于 现代兼容性 推荐的配置。
|
||
|
此配置文件允许您定义要使用的 TLS 版本和密码。
|
|
使用预定义的配置文件类型时,有效的配置文件配置可能会在版本之间发生更改。例如,给定在 X.Y.Z 版本上部署的要使用中间版配置文件的规范,升级到 X.Y.Z+1 版本可能会导致应用新的配置文件配置,从而导致重新部署。 |
要为 Ingress 控制器配置 TLS 安全配置文件,请编辑IngressController自定义资源 (CR) 以指定预定义或自定义 TLS 安全配置文件。如果未配置 TLS 安全配置文件,则默认值基于为 API 服务器设置的 TLS 安全配置文件。
Old TLS 安全配置文件的IngressController CR 示例apiVersion: operator.openshift.io/v1
kind: IngressController
...
spec:
tlsSecurityProfile:
old: {}
type: Old
...
TLS 安全配置文件定义 Ingress 控制器的 TLS 连接的最低 TLS 版本和 TLS 密码。
您可以在IngressController自定义资源 (CR) 的Status.Tls Profile下查看已配置的 TLS 安全配置文件的密码和最低 TLS 版本,并在Spec.Tls Security Profile下查看已配置的 TLS 安全配置文件。对于Custom TLS 安全配置文件,特定密码和最低 TLS 版本都列在两个参数下。
|
HAProxy Ingress 控制器镜像支持 TLS Ingress 运算符还会将 |
您具有作为具有cluster-admin角色的用户访问集群的权限。
编辑openshift-ingress-operator项目中的IngressController CR 以配置 TLS 安全配置文件
$ oc edit IngressController default -n openshift-ingress-operator
添加spec.tlsSecurityProfile字段
Custom配置文件的IngressController CR 示例apiVersion: operator.openshift.io/v1
kind: IngressController
...
spec:
tlsSecurityProfile:
type: Custom (1)
custom: (2)
ciphers: (3)
- ECDHE-ECDSA-CHACHA20-POLY1305
- ECDHE-RSA-CHACHA20-POLY1305
- ECDHE-RSA-AES128-GCM-SHA256
- ECDHE-ECDSA-AES128-GCM-SHA256
minTLSVersion: VersionTLS11
...
| 1 | 指定 TLS 安全配置文件类型 (Old、Intermediate或Custom)。默认为Intermediate。 |
| 2 | 为所选类型指定相应的字段
|
| 3 | 对于custom类型,请指定 TLS 密码列表和最低可接受的 TLS 版本。 |
保存文件以应用更改。
验证配置文件是否已在IngressController CR 中设置
$ oc describe IngressController default -n openshift-ingress-operator
Name: default
Namespace: openshift-ingress-operator
Labels: <none>
Annotations: <none>
API Version: operator.openshift.io/v1
Kind: IngressController
...
Spec:
...
Tls Security Profile:
Custom:
Ciphers:
ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-RSA-CHACHA20-POLY1305
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES128-GCM-SHA256
Min TLS Version: VersionTLS11
Type: Custom
...
您可以通过设置spec.clientTLS值来配置 Ingress 控制器以启用双向 TLS (mTLS) 身份验证。clientTLS值将 Ingress 控制器配置为验证客户端证书。此配置包括设置clientCA值,这是一个对配置映射的引用。配置映射包含用于验证客户端证书的 PEM 编码的 CA 证书捆绑包。此外,您还可以选择配置证书主题筛选器列表。
如果clientCA值指定 X509v3 证书吊销列表 (CRL) 分发点,则 Ingress 运算符将根据每个提供的证书中指定的 HTTP URI X509v3 CRL Distribution Point下载并管理 CRL 配置映射。Ingress 控制器在 mTLS/TLS 协商期间使用此配置映射。不提供有效证书的请求将被拒绝。
您具有作为具有cluster-admin角色的用户访问集群的权限。
您拥有 PEM 编码的 CA 证书捆绑包。
如果您的 CA 捆绑包引用 CRL 分发点,则您还必须将最终实体或叶证书包含到客户端 CA 捆绑包中。此证书必须在CRL Distribution Points下包含 HTTP URI,如 RFC 5280 中所述。例如
Issuer: C=US, O=Example Inc, CN=Example Global G2 TLS RSA SHA256 2020 CA1
Subject: SOME SIGNED CERT X509v3 CRL Distribution Points:
Full Name:
URI:http://crl.example.com/example.crl
在openshift-config命名空间中,从您的 CA 捆绑包创建配置映射
$ oc create configmap \
router-ca-certs-default \
--from-file=ca-bundle.pem=client-ca.crt \(1)
-n openshift-config
| 1 | 配置映射数据键必须为ca-bundle.pem,数据值必须为 PEM 格式的 CA 证书。 |
编辑openshift-ingress-operator项目中的IngressController资源
$ oc edit IngressController default -n openshift-ingress-operator
添加spec.clientTLS字段和子字段以配置双向 TLS
clientTLS配置文件的IngressController CR 示例 apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
name: default
namespace: openshift-ingress-operator
spec:
clientTLS:
clientCertificatePolicy: Required
clientCA:
name: router-ca-certs-default
allowedSubjectPatterns:
- "^/CN=example.com/ST=NC/C=US/O=Security/OU=OpenShift$"
可选,通过输入以下命令获取allowedSubjectPatterns的区分名称 (DN)。
$ openssl x509 -in custom-cert.pem -noout -subject subject= /CN=example.com/ST=NC/C=US/O=Security/OU=OpenShift
Ingress 运算符是 OpenShift Dedicated 的核心功能,并且开箱即用。
每个新的 OpenShift Dedicated 安装都具有名为 default 的ingresscontroller。可以使用其他 Ingress 控制器对其进行补充。如果删除默认ingresscontroller,Ingress 运算符将在 1 分钟内自动重新创建它。
查看默认 Ingress Controller
$ oc describe --namespace=openshift-ingress-operator ingresscontroller/default
您可以查看和检查 Ingress 运算符的状态。
查看您的 Ingress 运算符状态
$ oc describe clusteroperators/ingress
您可以查看您的 Ingress 控制器日志。
查看您的 Ingress 控制器日志
$ oc logs --namespace=openshift-ingress-operator deployments/ingress-operator -c <container_name>
您可以查看特定 Ingress 控制器的状态。
查看 Ingress 控制器的状态
$ oc describe --namespace=openshift-ingress-operator ingresscontroller/<name>
作为集群管理员,您可以创建新的自定义 Ingress 控制器。由于默认 Ingress 控制器可能会在 OpenShift Dedicated 更新期间发生更改,因此在维护跨集群更新持续存在的配置时,创建自定义 Ingress 控制器会很有帮助。
此示例提供了自定义 Ingress 控制器的最小规范。要进一步自定义您的自定义 Ingress 控制器,请参阅“配置 Ingress 控制器”。
安装 OpenShift CLI (oc)。
以具有cluster-admin权限的用户身份登录。
创建一个定义自定义IngressController对象的 YAML 文件
custom-ingress-controller.yaml文件示例apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
name: <custom_name> (1)
namespace: openshift-ingress-operator
spec:
defaultCertificate:
name: <custom-ingress-custom-certs> (2)
replicas: 1 (3)
domain: <custom_domain> (4)
| 1 | 为IngressController对象指定自定义name。 |
| 2 | 指定包含自定义通配符证书的密钥的名称。 |
| 3 | 最小副本数必须为 1。 |
| 4 | 将域指定为您的域名。IngressController 对象上指定的域和用于证书的域必须匹配。例如,如果域值为“custom_domain.mycompany.com”,则证书必须具有 SAN *.custom_domain.mycompany.com(在域中添加了*.)。 |
通过运行以下命令创建对象
$ oc create -f custom-ingress-controller.yaml
作为管理员,您可以通过创建 Secret 资源和编辑IngressController自定义资源 (CR) 来配置 Ingress 控制器以使用自定义证书。
您必须拥有 PEM 编码文件中的一对证书/密钥,其中证书由受信任的证书颁发机构或您在自定义 PKI 中配置的私有受信任证书颁发机构签名。
您的证书满足以下要求
证书对于入口域有效。
证书使用subjectAltName扩展名来指定通配符域,例如*.apps.ocp4.example.com。
您必须拥有IngressController CR。您可以使用默认的。
$ oc --namespace openshift-ingress-operator get ingresscontrollers
NAME AGE
default 10m
|
如果您有中间证书,则必须将其包含在包含自定义默认证书的密钥的 |
以下内容假设自定义证书和密钥对位于当前工作目录下的tls.crt和tls.key文件中。请将tls.crt和tls.key替换为实际路径名。在创建Secret资源和在IngressController CR中引用它时,您也可以使用其他名称替换custom-certs-default。
|
此操作将导致Ingress Controller使用滚动部署策略重新部署。 |
使用tls.crt和tls.key文件,在openshift-ingress命名空间中创建一个包含自定义证书的Secret资源。
$ oc --namespace openshift-ingress create secret tls custom-certs-default --cert=tls.crt --key=tls.key
更新IngressController CR以引用新的证书密钥。
$ oc patch --type=merge --namespace openshift-ingress-operator ingresscontrollers/default \
--patch '{"spec":{"defaultCertificate":{"name":"custom-certs-default"}}}'
验证更新是否有效。
$ echo Q |\
openssl s_client -connect console-openshift-console.apps.<domain>:443 -showcerts 2>/dev/null |\
openssl x509 -noout -subject -issuer -enddate
其中
<domain>指定集群的基本域名。
subject=C = US, ST = NC, L = Raleigh, O = RH, OU = OCP4, CN = *.apps.example.com
issuer=C = US, ST = NC, L = Raleigh, O = RH, OU = OCP4, CN = example.com
notAfter=May 10 08:32:45 2022 GM
|
您可以选择应用以下YAML来设置自定义默认证书。
|
证书密钥名称应与用于更新CR的值匹配。
修改IngressController CR后,Ingress Operator会更新Ingress Controller的部署以使用自定义证书。
作为管理员,您可以移除您已配置Ingress Controller使用的自定义证书。
您具有作为具有cluster-admin角色的用户访问集群的权限。
您已安装OpenShift CLI (oc)。
您之前已为Ingress Controller配置了自定义默认证书。
要移除自定义证书并恢复OpenShift Dedicated附带的证书,请输入以下命令:
$ oc patch -n openshift-ingress-operator ingresscontrollers/default \
--type json -p $'- op: remove\n path: /spec/defaultCertificate'
集群协调新的证书配置可能需要一些时间。
要确认已恢复原始集群证书,请输入以下命令:
$ echo Q | \
openssl s_client -connect console-openshift-console.apps.<domain>:443 -showcerts 2>/dev/null | \
openssl x509 -noout -subject -issuer -enddate
其中
<domain>指定集群的基本域名。
subject=CN = *.apps.<domain>
issuer=CN = ingress-operator@1620633373
notAfter=May 10 10:44:36 2023 GMT
您可以自动缩放Ingress Controller以动态满足路由性能或可用性要求,例如提高吞吐量的要求。
以下步骤提供了一个用于扩展默认Ingress Controller的示例。
您已安装OpenShift CLI (oc)。
您可以作为具有cluster-admin角色的用户访问OpenShift Dedicated集群。
您已安装自定义指标自动缩放器Operator和相关的KEDA Controller。
您可以使用Web控制台上的OperatorHub安装Operator。安装Operator后,您可以创建一个KedaController实例。
通过运行以下命令创建一个服务帐户以对Thanos进行身份验证:
$ oc create -n openshift-ingress-operator serviceaccount thanos && oc describe -n openshift-ingress-operator serviceaccount thanos
Name: thanos
Namespace: openshift-ingress-operator
Labels: <none>
Annotations: <none>
Image pull secrets: thanos-dockercfg-kfvf2
Mountable secrets: thanos-dockercfg-kfvf2
Tokens: <none>
Events: <none>
使用以下命令手动创建服务帐户密钥令牌:
$ oc apply -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
name: thanos-token
namespace: openshift-ingress-operator
annotations:
kubernetes.io/service-account.name: thanos
type: kubernetes.io/service-account-token
EOF
使用服务帐户的令牌在openshift-ingress-operator命名空间中定义一个TriggerAuthentication对象。
创建TriggerAuthentication对象并将secret变量的值传递给TOKEN参数。
$ oc apply -f - <<EOF
apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
name: keda-trigger-auth-prometheus
namespace: openshift-ingress-operator
spec:
secretTargetRef:
- parameter: bearerToken
name: thanos-token
key: token
- parameter: ca
name: thanos-token
key: ca.crt
EOF
创建一个用于从Thanos读取指标的角色。
创建一个新的角色thanos-metrics-reader.yaml,该角色可从Pod和节点读取指标。
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: thanos-metrics-reader
namespace: openshift-ingress-operator
rules:
- apiGroups:
- ""
resources:
- pods
- nodes
verbs:
- get
- apiGroups:
- metrics.k8s.io
resources:
- pods
- nodes
verbs:
- get
- list
- watch
- apiGroups:
- ""
resources:
- namespaces
verbs:
- get
通过运行以下命令应用新角色:
$ oc apply -f thanos-metrics-reader.yaml
通过输入以下命令将新角色添加到服务帐户:
$ oc adm policy -n openshift-ingress-operator add-role-to-user thanos-metrics-reader -z thanos --role-namespace=openshift-ingress-operator
$ oc adm policy -n openshift-ingress-operator add-cluster-role-to-user cluster-monitoring-view -z thanos
|
仅当您使用跨命名空间查询时才需要参数 |
创建一个新的ScaledObject YAML文件ingress-autoscaler.yaml,该文件以默认Ingress Controller部署为目标。
ScaledObject定义示例:apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: ingress-scaler
namespace: openshift-ingress-operator
spec:
scaleTargetRef: (1)
apiVersion: operator.openshift.io/v1
kind: IngressController
name: default
envSourceContainerName: ingress-operator
minReplicaCount: 1
maxReplicaCount: 20 (2)
cooldownPeriod: 1
pollingInterval: 1
triggers:
- type: prometheus
metricType: AverageValue
metadata:
serverAddress: https://thanos-querier.openshift-monitoring.svc.cluster.local:9091 (3)
namespace: openshift-ingress-operator (4)
metricName: 'kube-node-role'
threshold: '1'
query: 'sum(kube_node_role{role="worker",service="kube-state-metrics"})' (5)
authModes: "bearer"
authenticationRef:
name: keda-trigger-auth-prometheus
| 1 | 您要定位的自定义资源。在本例中为Ingress Controller。 |
| 2 | 可选:最大副本数。如果您省略此字段,则默认最大值为100个副本。 |
| 3 | openshift-monitoring命名空间中的Thanos服务端点。 |
| 4 | Ingress Operator命名空间。 |
| 5 | 此表达式计算部署集群中存在的worker节点数量。 |
|
如果您使用跨命名空间查询,则必须在 |
通过运行以下命令应用自定义资源定义:
$ oc apply -f ingress-autoscaler.yaml
通过运行以下命令验证默认Ingress Controller是否已扩展到与kube-state-metrics查询返回的值匹配:
使用grep命令搜索Ingress Controller YAML文件中的副本。
$ oc get -n openshift-ingress-operator ingresscontroller/default -o yaml | grep replicas:
replicas: 3
获取openshift-ingress项目中的Pod。
$ oc get pods -n openshift-ingress
NAME READY STATUS RESTARTS AGE
router-default-7b5df44ff-l9pmm 2/2 Running 0 17h
router-default-7b5df44ff-s5sl5 2/2 Running 0 3d22h
router-default-7b5df44ff-wwsth 2/2 Running 0 66s
手动缩放Ingress Controller以满足路由性能或可用性要求,例如提高吞吐量的要求。使用oc命令缩放IngressController资源。以下步骤提供了一个用于扩展默认IngressController的示例。
|
缩放不是立即操作,因为它需要时间来创建所需数量的副本。 |
查看默认IngressController当前可用的副本数量:
$ oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'
2
使用oc patch命令将默认IngressController缩放至所需的副本数量。以下示例将默认IngressController缩放至3个副本:
$ oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"replicas": 3}}' --type=merge
ingresscontroller.operator.openshift.io/default patched
验证默认IngressController是否已缩放至您指定的副本数量。
$ oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'
3
|
您可以选择应用以下YAML将Ingress Controller缩放至三个副本:
|
| 1 | 如果需要不同数量的副本,请更改replicas值。 |
您可以配置Ingress Controller以启用访问日志。如果您的集群流量不大,则可以将日志记录到sidecar容器。如果您的集群流量很大,为了避免超过日志记录堆栈的容量或与OpenShift Dedicated之外的日志记录基础设施集成,您可以将日志转发到自定义syslog端点。您还可以指定访问日志的格式。
容器日志记录对于在低流量集群上启用访问日志很有用,此时没有现有的Syslog日志记录基础设施,或者在诊断Ingress Controller问题期间短期使用。
对于高流量集群,访问日志可能会超过OpenShift Logging堆栈的容量,或者对于任何日志记录解决方案都需要与现有的Syslog日志记录基础设施集成的环境,需要使用Syslog。Syslog的使用案例可能会有重叠。
以具有cluster-admin权限的用户身份登录。
将Ingress访问日志配置到sidecar容器。
要配置Ingress访问日志,必须使用spec.logging.access.destination指定目标。要指定将日志记录到sidecar容器,必须指定Container作为spec.logging.access.destination.type。以下示例是将日志记录到Container目标的Ingress Controller定义:
apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
name: default
namespace: openshift-ingress-operator
spec:
replicas: 2
logging:
access:
destination:
type: Container
当您将Ingress Controller配置为记录到sidecar容器时,operator会在Ingress Controller Pod内创建一个名为logs的容器。
$ oc -n openshift-ingress logs deployment.apps/router-default -c logs
2020-05-11T19:11:50.135710+00:00 router-default-57dfc6cd95-bpmk6 router-default-57dfc6cd95-bpmk6 haproxy[108]: 174.19.21.82:39654 [11/May/2020:19:11:50.133] public be_http:hello-openshift:hello-openshift/pod:hello-openshift:hello-openshift:10.128.2.12:8080 0/0/1/0/1 200 142 - - --NI 1/1/0/0/0 0/0 "GET / HTTP/1.1"
将Ingress访问日志配置到Syslog端点。
要配置Ingress访问日志,必须使用spec.logging.access.destination指定目标。要指定将日志记录到Syslog端点目标,必须为spec.logging.access.destination.type指定Syslog。如果目标类型为Syslog,则还必须使用spec.logging.access.destination.syslog.address指定目标端点,并且可以使用spec.logging.access.destination.syslog.facility指定设施。以下示例是将日志记录到Syslog目标的Ingress Controller定义:
apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
name: default
namespace: openshift-ingress-operator
spec:
replicas: 2
logging:
access:
destination:
type: Syslog
syslog:
address: 1.2.3.4
port: 10514
|
|
使用特定日志格式配置 Ingress 访问日志。
您可以指定 spec.logging.access.httpLogFormat 来自定义日志格式。以下示例是一个 Ingress Controller 定义,它将日志记录到 IP 地址为 1.2.3.4 且端口为 10514 的 syslog 端点。
apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
name: default
namespace: openshift-ingress-operator
spec:
replicas: 2
logging:
access:
destination:
type: Syslog
syslog:
address: 1.2.3.4
port: 10514
httpLogFormat: '%ci:%cp [%t] %ft %b/%s %B %bq %HM %HU %HV'
禁用 Ingress 访问日志记录。
要禁用 Ingress 访问日志记录,请将 spec.logging 或 spec.logging.access 留空。
apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
name: default
namespace: openshift-ingress-operator
spec:
replicas: 2
logging:
access: null
允许 Ingress Controller 在使用 sidecar 时修改 HAProxy 日志长度。
如果您使用的是 spec.logging.access.destination.type: Syslog,请使用 spec.logging.access.destination.syslog.maxLength。
apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
name: default
namespace: openshift-ingress-operator
spec:
replicas: 2
logging:
access:
destination:
type: Syslog
syslog:
address: 1.2.3.4
maxLength: 4096
port: 10514
如果您使用的是 spec.logging.access.destination.type: Container,请使用 spec.logging.access.destination.container.maxLength。
apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
name: default
namespace: openshift-ingress-operator
spec:
replicas: 2
logging:
access:
destination:
type: Container
container:
maxLength: 8192
集群管理员可以设置线程数以增加集群可以处理的传入连接数量。您可以修补现有的 Ingress Controller 以增加线程数量。
以下假设您已经创建了一个 Ingress Controller。
更新 Ingress Controller 以增加线程数
$ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"threadCount": 8}}}'
|
如果您有一个能够运行大量资源的节点,您可以使用与目标节点容量匹配的标签配置 |
在云平台上创建 Ingress Controller 时,Ingress Controller 默认由公共云负载均衡器发布。作为管理员,您可以创建一个使用内部云负载均衡器的 Ingress Controller。
|
如果您想更改 |
上图显示了与 OpenShift Dedicated Ingress LoadBalancerService 端点发布策略相关的以下概念。
您可以使用云提供商负载均衡器进行外部负载均衡,也可以使用 OpenShift Ingress Controller 负载均衡器进行内部负载均衡。
您可以使用负载均衡器的单个 IP 地址和更常用的端口,例如图中所示的集群中的 8080 和 4200。
来自外部负载均衡器的流量定向到 Pod,并由负载均衡器管理,如节点宕机实例所示。有关实现细节,请参阅Kubernetes 服务文档。
安装 OpenShift CLI (oc)。
以具有cluster-admin权限的用户身份登录。
在一个名为 <name>-ingress-controller.yaml 的文件中创建一个 IngressController 自定义资源 (CR),例如以下示例所示
apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
namespace: openshift-ingress-operator
name: <name> (1)
spec:
domain: <domain> (2)
endpointPublishingStrategy:
type: LoadBalancerService
loadBalancer:
scope: Internal (3)
| 1 | 将 <name> 替换为 IngressController 对象的名称。 |
| 2 | 指定控制器发布的应用程序的 domain。 |
| 3 | 指定值为 Internal 以使用内部负载均衡器。 |
通过运行以下命令创建上一步中定义的 Ingress Controller
$ oc create -f <name>-ingress-controller.yaml (1)
| 1 | 将 <name> 替换为 IngressController 对象的名称。 |
可选:通过运行以下命令确认 Ingress Controller 是否已创建
$ oc --all-namespaces=true get ingresscontrollers
集群管理员可以设置健康检查间隔,以定义路由器在两次连续健康检查之间等待的时间。此值作为所有路由的全局默认值应用。默认值为 5 秒。
以下假设您已经创建了一个 Ingress Controller。
更新 Ingress Controller 以更改后端健康检查之间的间隔
$ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"healthCheckInterval": "8s"}}}'
|
要覆盖单个路由的 |
您可以通过删除并重新创建默认的 Ingress Controller 来将其配置为内部。
|
如果您想更改 |
安装 OpenShift CLI (oc)。
以具有cluster-admin权限的用户身份登录。
您可以通过删除并重新创建默认的 Ingress Controller 来将其配置为内部。
$ oc replace --force --wait --filename - <<EOF
apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
namespace: openshift-ingress-operator
name: default
spec:
endpointPublishingStrategy:
type: LoadBalancerService
loadBalancer:
scope: Internal
EOF
管理员和应用程序开发人员可以在具有相同域名名的多个命名空间中运行应用程序。这适用于多个团队开发在同一主机名上公开的微服务的组织。
|
跨命名空间允许声明应仅在命名空间之间具有信任关系的集群中启用,否则恶意用户可能会接管主机名。因此,默认准入策略不允许跨命名空间的主机名声明。 |
集群管理员权限。
使用以下命令编辑 ingresscontroller 资源变量的 .spec.routeAdmission 字段
$ oc -n openshift-ingress-operator patch ingresscontroller/default --patch '{"spec":{"routeAdmission":{"namespaceOwnership":"InterNamespaceAllowed"}}}' --type=merge
spec:
routeAdmission:
namespaceOwnership: InterNamespaceAllowed
...
|
或者,您可以应用以下 YAML 来配置路由准入策略
|
HAProxy Ingress Controller 支持通配符路由。Ingress Operator 使用 wildcardPolicy 来配置 Ingress Controller 的 ROUTER_ALLOW_WILDCARD_ROUTES 环境变量。
Ingress Controller 的默认行为是接受通配符策略为 None 的路由,这与现有的 IngressController 资源向后兼容。
配置通配符策略。
使用以下命令编辑 IngressController 资源
$ oc edit IngressController
在 spec 下,将 wildcardPolicy 字段设置为 WildcardsDisallowed 或 WildcardsAllowed
spec:
routeAdmission:
wildcardPolicy: WildcardsDisallowed # or WildcardsAllowed
OpenShift Dedicated 提供了不同的方法来处理 HTTP 头。在设置或删除头时,您可以使用 Ingress Controller 或单个路由中的特定字段来修改请求和响应头。您还可以使用路由注释来设置某些头。各种配置头的方法在协同工作时可能会带来挑战。
|
您只能在 |
当 Ingress Controller 和 Route 中都修改了相同的 HTTP 头部时,HAProxy 会根据是请求头部还是响应头部,以特定的方式优先处理操作。
对于 HTTP 响应头部,Ingress Controller 中指定的操作会在 Route 中指定的操作之后执行。这意味着 Ingress Controller 中指定的操作优先。
对于 HTTP 请求头部,Route 中指定的操作会在 Ingress Controller 中指定的操作之后执行。这意味着 Route 中指定的操作优先。
例如,集群管理员使用以下配置在 Ingress Controller 中将 X-Frame-Options 响应头部设置为 `DENY` 值:
apiVersion: operator.openshift.io/v1
kind: IngressController
# ...
spec:
httpHeaders:
actions:
response:
- name: X-Frame-Options
action:
type: Set
set:
value: DENY
Route 所有者设置了与集群管理员在 Ingress Controller 中设置的相同的响应头部,但值使用 `SAMEORIGIN`,使用以下配置:
apiVersion: route.openshift.io/v1
kind: Route
# ...
spec:
httpHeaders:
actions:
response:
- name: X-Frame-Options
action:
type: Set
set:
value: SAMEORIGIN
当 `IngressController` 配置和 `Route` 配置都配置了 X-Frame-Options 响应头部时,即使特定 Route 允许框架,Ingress Controller 中全局级别为此头部设置的值也将优先,对于请求头部,`Route` 配置值会覆盖 `IngressController` 配置值。
这种优先级是因为 `haproxy.config` 文件使用了以下逻辑,其中 Ingress Controller 被视为前端,各个 Route 被视为后端。应用于前端配置的头部值 `DENY` 会覆盖在后端设置的相同头部值 `SAMEORIGIN`。
frontend public
http-response set-header X-Frame-Options 'DENY'
frontend fe_sni
http-response set-header X-Frame-Options 'DENY'
frontend fe_no_sni
http-response set-header X-Frame-Options 'DENY'
backend be_secure:openshift-monitoring:alertmanager-main
http-response set-header X-Frame-Options 'SAMEORIGIN'
此外,Ingress Controller 或 Route 中定义的任何操作都将覆盖使用 Route 注解设置的值。
以下头部要么完全禁止设置或删除,要么仅在特定情况下允许。
| 头部名称 | 可使用 `IngressController` 配置 | 可使用 `Route` 配置 | 禁止的原因 | 可使用其他方法配置 |
|---|---|---|---|---|
|
否 |
否 |
`proxy` HTTP 请求头部可用于通过将头部值注入 `HTTP_PROXY` 环境变量来利用易受攻击的 CGI 应用程序。`proxy` HTTP 请求头部也是非标准的,并且在配置过程中容易出错。 |
否 |
|
否 |
是 |
当使用 `IngressController` CR 设置 `host` HTTP 请求头部时,HAProxy 在查找正确的 Route 时可能会失败。 |
否 |
|
否 |
否 |
`strict-transport-security` HTTP 响应头部已使用 Route 注解处理,无需单独实现。 |
是:`haproxy.router.openshift.io/hsts_header` Route 注解 |
`cookie` 和 `set-cookie` |
否 |
否 |
HAProxy 设置的 Cookie 用于会话跟踪,以将客户端连接映射到特定的后端服务器。允许设置这些头部可能会干扰 HAProxy 的会话关联并限制 HAProxy 对 Cookie 的所有权。 |
是
|
您可以出于合规性或其他原因设置或删除某些 HTTP 请求和响应头部。您可以为 Ingress Controller 提供服务的所有 Route 或特定 Route 设置或删除这些头部。
例如,您可能希望迁移在您的集群上运行的应用程序以使用双向 TLS,这需要您的应用程序检查 X-Forwarded-Client-Cert 请求头部,但 OpenShift Dedicated 默认 Ingress Controller 提供的是 X-SSL-Client-Der 请求头部。
以下过程修改 Ingress Controller 以设置 X-Forwarded-Client-Cert 请求头部,并删除 X-SSL-Client-Der 请求头部。
您已安装OpenShift CLI (oc)。
您可以作为具有cluster-admin角色的用户访问OpenShift Dedicated集群。
编辑 Ingress Controller 资源
$ oc -n openshift-ingress-operator edit ingresscontroller/default
将 X-SSL-Client-Der HTTP 请求头部替换为 X-Forwarded-Client-Cert HTTP 请求头部
apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
name: default
namespace: openshift-ingress-operator
spec:
httpHeaders:
actions: (1)
request: (2)
- name: X-Forwarded-Client-Cert (3)
action:
type: Set (4)
set:
value: "%{+Q}[ssl_c_der,base64]" (5)
- name: X-SSL-Client-Der
action:
type: Delete
| 1 | 您要在 HTTP 头部上执行的操作列表。 |
| 2 | 您要更改的头部类型。在本例中,是请求头部。 |
| 3 | 您要更改的头部名称。有关您可以设置或删除的可用头部的列表,请参见“HTTP 头部配置”。 |
| 4 | 对头部执行的操作类型。此字段的值可以是 `Set` 或 `Delete`。 |
| 5 | 设置 HTTP 头部时,必须提供一个 `value`。该值可以是该头部可用指令列表中的字符串,例如 `DENY`,也可以是将使用 HAProxy 的动态值语法解释的动态值。在本例中,添加了动态值。 |
|
对于设置 HTTP 响应的动态头部值,允许的示例提取器是 `res.hdr` 和 `ssl_c_der`。对于设置 HTTP 请求的动态头部值,允许的示例提取器是 `req.hdr` 和 `ssl_c_der`。请求和响应动态值都可以使用 `lower` 和 `base64` 转换器。 |
保存文件以应用更改。
您可以配置 HAProxy Ingress Controller 以指定如何处理 HTTP 头部(包括 `Forwarded` 和 `X-Forwarded-For`)的策略。Ingress Operator 使用 `HTTPHeaders` 字段配置 Ingress Controller 的 `ROUTER_SET_FORWARDED_HEADERS` 环境变量。
配置 Ingress Controller 的 `HTTPHeaders` 字段。
使用以下命令编辑 IngressController 资源
$ oc edit IngressController
在 `spec` 下,将 `HTTPHeaders` 策略字段设置为 `Append`、`Replace`、`IfNone` 或 `Never`。
apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
name: default
namespace: openshift-ingress-operator
spec:
httpHeaders:
forwardedHeaderPolicy: Append
作为集群管理员,您可以:
配置一个外部代理,在将请求转发到 Ingress Controller 之前,将 `X-Forwarded-For` 头部注入到每个请求中。
要配置 Ingress Controller 以原样传递头部,请指定 `never` 策略。然后,Ingress Controller 永远不会设置头部,应用程序只会接收外部代理提供的头部。
配置 Ingress Controller 以原样传递外部代理在外部集群请求上设置的 `X-Forwarded-For` 头部。
要配置 Ingress Controller 在内部集群请求(不会通过外部代理)上设置 `X-Forwarded-For` 头部,请指定 `if-none` 策略。如果 HTTP 请求已通过外部代理设置了头部,则 Ingress Controller 会保留它。如果由于请求没有通过代理而缺少头部,则 Ingress Controller 会添加该头部。
作为应用程序开发人员,您可以:
配置一个应用程序特定的外部代理来注入 `X-Forwarded-For` 头部。
要配置 Ingress Controller 以在应用程序的 Route 上原样传递头部,而不影响其他 Route 的策略,请在应用程序的 Route 上添加注解 `haproxy.router.openshift.io/set-forwarded-headers: if-none` 或 `haproxy.router.openshift.io/set-forwarded-headers: never`。
|
您可以为每个路由单独设置 |
您可以在 HAProxy 中启用透明的端到端 HTTP/2 连接。这允许应用程序所有者使用 HTTP/2 协议的功能,包括单连接、报头压缩、二进制流等等。
您可以为单个 Ingress 控制器或整个集群启用 HTTP/2 连接。
要启用从客户端到 HAProxy 的连接使用 HTTP/2,路由必须指定自定义证书。使用默认证书的路由无法使用 HTTP/2。此限制是必要的,以避免连接合并问题,其中客户端对使用相同证书的不同路由重用连接。
从 HAProxy 到应用程序 Pod 的连接只能在重新加密路由中使用 HTTP/2,而不能在边缘终止或不安全的路由中使用。这是因为 HAProxy 使用应用程序级协议协商 (ALPN)(这是 TLS 扩展)与后端协商 HTTP/2 的使用。这意味着端到端 HTTP/2 可以与直通和重新加密一起使用,而不能与不安全或边缘终止的路由一起使用。
|
对于非直通路由,Ingress 控制器独立于来自客户端的连接来协商其与应用程序的连接。这意味着客户端可以连接到 Ingress 控制器并协商 HTTP/1.1,然后 Ingress 控制器可以连接到应用程序,协商 HTTP/2,并使用 HTTP/2 连接到应用程序转发来自客户端 HTTP/1.1 连接的请求。如果客户端随后尝试将其连接从 HTTP/1.1 升级到 WebSocket 协议,这就会产生问题,因为 Ingress 控制器无法将 WebSocket 转发到 HTTP/2,也无法将其 HTTP/2 连接升级到 WebSocket。因此,如果您有一个打算接受 WebSocket 连接的应用程序,则它必须不允许协商 HTTP/2 协议,否则客户端将无法升级到 WebSocket 协议。 |
在单个 Ingress 控制器上启用 HTTP/2。
要在 Ingress 控制器上启用 HTTP/2,请输入oc annotate 命令
$ oc -n openshift-ingress-operator annotate ingresscontrollers/<ingresscontroller_name> ingress.operator.openshift.io/default-enable-http2=true
将<ingresscontroller_name>替换为要添加注释的 Ingress 控制器的名称。
在整个集群上启用 HTTP/2。
要为整个集群启用 HTTP/2,请输入oc annotate 命令
$ oc annotate ingresses.config/cluster ingress.operator.openshift.io/default-enable-http2=true
|
或者,您可以应用以下 YAML 来添加注释
|
当 Ingress 控制器使用HostNetwork、NodePortService 或Private 端点发布策略类型时,集群管理员可以配置PROXY 协议。PROXY 协议使负载均衡器能够保留 Ingress 控制器接收的连接的原始客户端地址。原始客户端地址对于日志记录、过滤和注入 HTTP 头非常有用。在默认配置中,Ingress 控制器接收的连接仅包含与负载均衡器关联的源地址。
|
在非云平台上使用 Keepalived Ingress 虚拟 IP (VIP) 的安装程序预配集群的默认 Ingress 控制器不支持 PROXY 协议。 |
PROXY 协议使负载均衡器能够保留 Ingress 控制器接收的连接的原始客户端地址。原始客户端地址对于日志记录、过滤和注入 HTTP 头非常有用。在默认配置中,Ingress 控制器接收的连接仅包含与负载均衡器关联的源 IP 地址。
|
对于直通路由配置,OpenShift Dedicated 集群中的服务器无法观察原始客户端源 IP 地址。如果您需要知道原始客户端源 IP 地址,请为您的 Ingress 控制器配置 Ingress 访问日志记录,以便您可以查看客户端源 IP 地址。 对于重新加密和边缘路由,OpenShift Dedicated 路由器设置 有关 Ingress 访问日志记录的更多信息,请参阅“配置 Ingress 访问日志记录”。 |
使用LoadBalancerService 端点发布策略类型时,不支持为 Ingress 控制器配置 PROXY 协议。此限制是因为当 OpenShift Dedicated 在云平台上运行时,并且 Ingress 控制器指定应使用服务负载均衡器时,Ingress 运算符会根据平台保留源地址的要求配置负载均衡器服务并启用 PROXY 协议。
|
您必须将 OpenShift Dedicated 和外部负载均衡器都配置为使用 PROXY 协议或 TCP。 |
云部署中不支持此功能。此限制是因为当 OpenShift Dedicated 在云平台上运行时,并且 Ingress 控制器指定应使用服务负载均衡器时,Ingress 运算符会根据平台保留源地址的要求配置负载均衡器服务并启用 PROXY 协议。
|
您必须将 OpenShift Dedicated 和外部负载均衡器都配置为使用 PROXY 协议或传输控制协议 (TCP)。 |
您创建了一个 Ingress 控制器。
通过在您的 CLI 中输入以下命令来编辑 Ingress 控制器资源
$ oc -n openshift-ingress-operator edit ingresscontroller/default
设置 PROXY 配置
如果您的 Ingress 控制器使用HostNetwork 端点发布策略类型,请将spec.endpointPublishingStrategy.hostNetwork.protocol 子字段设置为PROXY
hostNetwork 配置设置为PROXY 的示例# ...
spec:
endpointPublishingStrategy:
hostNetwork:
protocol: PROXY
type: HostNetwork
# ...
如果您的 Ingress 控制器使用NodePortService 端点发布策略类型,请将spec.endpointPublishingStrategy.nodePort.protocol 子字段设置为PROXY
nodePort 配置设置为PROXY 的示例# ...
spec:
endpointPublishingStrategy:
nodePort:
protocol: PROXY
type: NodePortService
# ...
如果您的 Ingress 控制器使用Private 端点发布策略类型,请将spec.endpointPublishingStrategy.private.protocol 子字段设置为PROXY
private 配置设置为PROXY 的示例# ...
spec:
endpointPublishingStrategy:
private:
protocol: PROXY
type: Private
# ...
作为集群管理员,您可以通过配置appsDomain 字段来指定用户创建路由的默认集群域的替代方案。appsDomain 字段是 OpenShift Dedicated 用于代替默认域(在domain 字段中指定)的可选域。如果您指定了备用域,则它会覆盖默认集群域,用于确定新路由的默认主机。
例如,您可以使用贵公司的 DNS 域名作为集群上运行的应用程序的路由和入口的默认域名。
您已部署 OpenShift Dedicated 集群。
您已安装 oc 命令行界面。
通过指定用户创建路由的替代默认域名来配置 appsDomain 字段。
编辑入口cluster资源
$ oc edit ingresses.config/cluster -o yaml
编辑 YAML 文件
appsDomain 配置示例设置为 test.example.comapiVersion: config.openshift.io/v1
kind: Ingress
metadata:
name: cluster
spec:
domain: apps.example.com (1)
appsDomain: <test.example.com> (2)
| 1 | 指定默认域名。安装后无法修改默认域名。 |
| 2 | 可选:OpenShift Dedicated 基础设施用于应用程序路由的域名。您可以使用替代前缀(如 test),而不是默认前缀 apps。 |
通过公开路由并验证路由域名的更改,验证现有路由是否包含 appsDomain 字段中指定的域名。
|
等待 |
公开路由
$ oc expose service hello-openshift
route.route.openshift.io/hello-openshift exposed
$ oc get routes
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD
hello-openshift hello_openshift-<my_project>.test.example.com
hello-openshift 8080-tcp None
HAProxy 默认情况下会将 HTTP 头部名称转换为小写;例如,将 Host: xyz.com 更改为 host: xyz.com。如果旧版应用程序对 HTTP 头部名称的大小写敏感,请使用 Ingress Controller 的 spec.httpHeaders.headerNameCaseAdjustments API 字段,以解决此问题,直到可以修复这些旧版应用程序为止。
|
OpenShift Dedicated 包含 HAProxy 2.8。如果您想更新到此版本的基于 Web 的负载均衡器,请确保将 |
作为集群管理员,您可以通过输入 oc patch 命令或在 Ingress Controller YAML 文件中设置 HeaderNameCaseAdjustments 字段来转换 HTTP 头部大小写。
您已安装OpenShift CLI (oc)。
您具有作为具有cluster-admin角色的用户访问集群的权限。
使用 oc patch 命令将 HTTP 头部大写。
运行以下命令将 HTTP 头部从 host 更改为 Host
$ oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"httpHeaders":{"headerNameCaseAdjustments":["Host"]}}}'
创建一个 Route 资源 YAML 文件,以便可以将注释应用于应用程序。
my-application 的路由示例apiVersion: route.openshift.io/v1
kind: Route
metadata:
annotations:
haproxy.router.openshift.io/h1-adjust-case: true (1)
name: <application_name>
namespace: <application_name>
# ...
| 1 | 设置 haproxy.router.openshift.io/h1-adjust-case,以便 Ingress Controller 可以根据指定调整 host 请求标头。 |
通过在 Ingress Controller YAML 配置文件中配置 HeaderNameCaseAdjustments 字段来指定调整。
以下 Ingress Controller YAML 文件示例将 HTTP/1 请求到已正确注释路由的 host 头部调整为 Host
apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
name: default
namespace: openshift-ingress-operator
spec:
httpHeaders:
headerNameCaseAdjustments:
- Host
以下路由示例使用 haproxy.router.openshift.io/h1-adjust-case 注释启用 HTTP 响应标头名称大小写调整
apiVersion: route.openshift.io/v1
kind: Route
metadata:
annotations:
haproxy.router.openshift.io/h1-adjust-case: true (1)
name: my-application
namespace: my-application
spec:
to:
kind: Service
name: my-application
| 1 | 将 haproxy.router.openshift.io/h1-adjust-case 设置为 true。 |
您可以配置 HAProxy Ingress Controller 以全局指定针对特定 MIME 类型的路由器压缩。您可以使用 mimeTypes 变量定义应用压缩的 MIME 类型的格式。这些类型包括:application、image、message、multipart、text、video 或以“X-”开头的自定义类型。要查看 MIME 类型和子类型的完整表示法,请参阅 RFC1341。
|
为压缩分配的内存会影响最大连接数。此外,压缩大型缓冲区可能会导致延迟,例如繁重的正则表达式或很长的正则表达式列表。 并非所有 MIME 类型都受益于压缩,但如果指示 HAProxy 进行压缩,它仍然会使用资源进行尝试。通常,文本格式(例如 html、css 和 js 格式)会受益于压缩,但那些已经压缩的格式(例如图像、音频和视频)则几乎没有好处,但却要花费时间和资源进行压缩。 |
配置 Ingress Controller 的 httpCompression 字段。
使用以下命令编辑 IngressController 资源
$ oc edit -n openshift-ingress-operator ingresscontrollers/default
在 spec 下,将 httpCompression 策略字段设置为 mimeTypes 并指定应应用压缩的 MIME 类型列表。
apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
name: default
namespace: openshift-ingress-operator
spec:
httpCompression:
mimeTypes:
- "text/html"
- "text/css; charset=utf-8"
- "application/json"
...
您可以默认情况下以 Prometheus 格式在默认统计端口 1936 上公开 HAProxy 路由器指标。外部指标收集和聚合系统(例如 Prometheus)可以访问 HAProxy 路由器指标。您可以在浏览器中以 HTML 和逗号分隔值 (CSV) 格式查看 HAProxy 路由器指标。
您已将防火墙配置为访问默认统计端口 1936。
运行以下命令获取路由器 pod 名称
$ oc get pods -n openshift-ingress
NAME READY STATUS RESTARTS AGE
router-default-76bfffb66c-46qwp 1/1 Running 0 11h
获取路由器的用户名和密码,路由器 pod 将其存储在 /var/lib/haproxy/conf/metrics-auth/statsUsername 和 /var/lib/haproxy/conf/metrics-auth/statsPassword 文件中
运行以下命令获取用户名
$ oc rsh <router_pod_name> cat metrics-auth/statsUsername
运行以下命令获取密码
$ oc rsh <router_pod_name> cat metrics-auth/statsPassword
运行以下命令获取路由器 IP 和指标证书
$ oc describe pod <router_pod>
运行以下命令获取 Prometheus 格式的原始统计信息
$ curl -u <user>:<password> http://<router_IP>:<stats_port>/metrics
运行以下命令安全地访问指标
$ curl -u user:password https://<router_IP>:<stats_port>/metrics -k
运行以下命令访问默认统计端口 1936
$ curl -u <user>:<password> http://<router_IP>:<stats_port>/metrics
...
# HELP haproxy_backend_connections_total Total number of connections.
# TYPE haproxy_backend_connections_total gauge
haproxy_backend_connections_total{backend="http",namespace="default",route="hello-route"} 0
haproxy_backend_connections_total{backend="http",namespace="default",route="hello-route-alt"} 0
haproxy_backend_connections_total{backend="http",namespace="default",route="hello-route01"} 0
...
# HELP haproxy_exporter_server_threshold Number of servers tracked and the current threshold value.
# TYPE haproxy_exporter_server_threshold gauge
haproxy_exporter_server_threshold{type="current"} 11
haproxy_exporter_server_threshold{type="limit"} 500
...
# HELP haproxy_frontend_bytes_in_total Current total of incoming bytes.
# TYPE haproxy_frontend_bytes_in_total gauge
haproxy_frontend_bytes_in_total{frontend="fe_no_sni"} 0
haproxy_frontend_bytes_in_total{frontend="fe_sni"} 0
haproxy_frontend_bytes_in_total{frontend="public"} 119070
...
# HELP haproxy_server_bytes_in_total Current total of incoming bytes.
# TYPE haproxy_server_bytes_in_total gauge
haproxy_server_bytes_in_total{namespace="",pod="",route="",server="fe_no_sni",service=""} 0
haproxy_server_bytes_in_total{namespace="",pod="",route="",server="fe_sni",service=""} 0
haproxy_server_bytes_in_total{namespace="default",pod="docker-registry-5-nk5fz",route="docker-registry",server="10.130.0.89:5000",service="docker-registry"} 0
haproxy_server_bytes_in_total{namespace="default",pod="hello-rc-vkjqx",route="hello-route",server="10.130.0.90:8080",service="hello-svc-1"} 0
...
在浏览器中输入以下 URL 启动统计窗口
http://<user>:<password>@<router_IP>:<stats_port>
可选:在浏览器中输入以下 URL 获取 CSV 格式的统计信息
http://<user>:<password>@<router_ip>:1936/metrics;csv
作为集群管理员,您可以为 503、404 或这两个错误页面指定自定义错误代码响应页面。当应用程序 pod 未运行时,HAProxy 路由器会提供 503 错误页面;当请求的 URL 不存在时,HAProxy 路由器会提供 404 错误页面。例如,如果您自定义 503 错误代码响应页面,则当应用程序 pod 未运行时会提供该页面,而 HAProxy 路由器会为错误路由或不存在的路由提供默认的 404 错误代码 HTTP 响应页面。
自定义错误代码响应页面在配置映射中指定,然后将其修补到 Ingress Controller。配置映射键有两个可用的文件名,如下所示:error-page-503.http 和 error-page-404.http。
自定义 HTTP 错误代码响应页面必须遵循 HAProxy HTTP 错误页面配置指南。这是一个 OpenShift Dedicated HAProxy 路由器的默认 http 503 错误代码响应页面 示例。您可以使用默认内容作为创建自定义页面的模板。
默认情况下,当应用程序未运行或路由不正确或不存在时,HAProxy 路由器仅提供 503 错误页面。此默认行为与 OpenShift Dedicated 4.8 及更早版本的行为相同。如果没有提供用于自定义 HTTP 错误代码响应的配置映射,并且您正在使用自定义 HTTP 错误代码响应页面,则路由器会提供默认的 404 或 503 错误代码响应页面。
|
如果您使用 OpenShift Dedicated 默认的 503 错误代码页面作为自定义的模板,则文件中的标头需要可以使用 CRLF 行尾的编辑器。 |
在 openshift-config 命名空间中创建一个名为 my-custom-error-code-pages 的配置映射
$ oc -n openshift-config create configmap my-custom-error-code-pages \
--from-file=error-page-503.http \
--from-file=error-page-404.http
|
如果您未为自定义错误代码响应页面指定正确的格式,则会发生路由器 pod 故障。要解决此故障,您必须删除或更正配置映射并删除受影响的路由器 pod,以便可以使用正确的信息重新创建它们。 |
修补 Ingress Controller 以按名称引用 my-custom-error-code-pages 配置映射
$ oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"httpErrorCodePages":{"name":"my-custom-error-code-pages"}}}' --type=merge
Ingress Operator 将openshift-config命名空间中的my-custom-error-code-pages配置映射复制到openshift-ingress命名空间。Operator 根据模式<你的Ingress控制器名称>-errorpages在openshift-ingress命名空间中命名该配置映射。
显示复制结果
$ oc get cm default-errorpages -n openshift-ingress
NAME DATA AGE default-errorpages 2 25s (1)
| 1 | 由于default Ingress控制器自定义资源 (CR) 已被修补,因此示例配置映射名称为default-errorpages。 |
确认包含自定义错误响应页面的配置映射已挂载到路由器卷上,其中配置映射键是具有自定义HTTP错误代码响应的文件名。
对于503自定义HTTP错误代码响应
$ oc -n openshift-ingress rsh <router_pod> cat /var/lib/haproxy/conf/error_code_pages/error-page-503.http
对于404自定义HTTP错误代码响应
$ oc -n openshift-ingress rsh <router_pod> cat /var/lib/haproxy/conf/error_code_pages/error-page-404.http
验证您的自定义错误代码HTTP响应
创建一个测试项目和应用程序
$ oc new-project test-ingress
$ oc new-app django-psql-example
对于503自定义HTTP错误代码响应
停止应用程序的所有Pod。
运行以下curl命令或在浏览器中访问路由主机名
$ curl -vk <route_hostname>
对于404自定义HTTP错误代码响应
访问不存在的路由或不正确的路由。
运行以下curl命令或在浏览器中访问路由主机名
$ curl -vk <route_hostname>
检查haproxy.config文件中errorfile属性是否正确。
$ oc -n openshift-ingress rsh <router> cat /var/lib/haproxy/conf/haproxy.config | grep errorfile
集群管理员可以设置OpenShift路由器部署的最大并发连接数。您可以修补现有的Ingress控制器以增加最大连接数。
以下假设您已经创建了Ingress控制器。
更新Ingress控制器以更改HAProxy的最大连接数。
$ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"maxConnections": 7500}}}'
|
如果您将 |
下表详细说明了Ingress Operator的组件以及Red Hat站点可靠性工程师 (SRE) 是否在OpenShift Dedicated集群上维护此组件。
| Ingress组件 | 由谁管理 | 默认配置? |
|---|---|---|
扩展Ingress控制器 |
SRE |
是 |
Ingress Operator线程数 |
SRE |
是 |
Ingress控制器访问日志记录 |
SRE |
是 |
Ingress控制器分片 |
SRE |
是 |
Ingress控制器路由准入策略 |
SRE |
是 |
Ingress控制器通配符路由 |
SRE |
是 |
Ingress控制器X-Forwarded标头 |
SRE |
是 |
Ingress控制器路由压缩 |
SRE |
是 |