Questo contenuto non è disponibile nella lingua selezionata.
Chapter 8. Postinstallation network configuration
After installing OpenShift Container Platform, you can further expand and customize your network to your requirements.
8.1. Cluster Network Operator configuration Copia collegamentoCollegamento copiato negli appunti!
The configuration for the cluster network is specified as part of the Cluster Network Operator (CNO) configuration and stored in a custom resource (CR) object that is named
cluster
Network
operator.openshift.io
The CNO configuration inherits the following fields during cluster installation from the
Network
Network.config.openshift.io
clusterNetwork- IP address pools from which pod IP addresses are allocated.
serviceNetwork- IP address pool for services.
defaultNetwork.type- Cluster network provider, such as OpenShift SDN or OVN-Kubernetes.
After cluster installation, you cannot modify the fields listed in the previous section.
8.2. Enabling the cluster-wide proxy Copia collegamentoCollegamento copiato negli appunti!
The
Proxy
Proxy
spec
apiVersion: config.openshift.io/v1
kind: Proxy
metadata:
name: cluster
spec:
trustedCA:
name: ""
status:
A cluster administrator can configure the proxy for OpenShift Container Platform by modifying this
cluster
Proxy
Only the
Proxy
cluster
Prerequisites
- Cluster administrator permissions
-
OpenShift Container Platform CLI tool installed
oc
Procedure
Create a config map that contains any additional CA certificates required for proxying HTTPS connections.
NoteYou can skip this step if the proxy’s identity certificate is signed by an authority from the RHCOS trust bundle.
Create a file called
with the following contents, and provide the values of your PEM-encoded certificates:user-ca-bundle.yamlapiVersion: v1 data: ca-bundle.crt: |1 <MY_PEM_ENCODED_CERTS>2 kind: ConfigMap metadata: name: user-ca-bundle3 namespace: openshift-config4 Create the config map from this file:
$ oc create -f user-ca-bundle.yaml
Use the
command to modify theoc editobject:Proxy$ oc edit proxy/clusterConfigure the necessary fields for the proxy:
apiVersion: config.openshift.io/v1 kind: Proxy metadata: name: cluster spec: httpProxy: http://<username>:<pswd>@<ip>:<port>1 httpsProxy: https://<username>:<pswd>@<ip>:<port>2 noProxy: example.com3 readinessEndpoints: - http://www.google.com4 - https://www.google.com trustedCA: name: user-ca-bundle5 - 1
- A proxy URL to use for creating HTTP connections outside the cluster. The URL scheme must be
http. - 2
- A proxy URL to use for creating HTTPS connections outside the cluster. The URL scheme must be either
httporhttps. Specify a URL for the proxy that supports the URL scheme. For example, most proxies will report an error if they are configured to usehttpsbut they only supporthttp. This failure message may not propagate to the logs and can appear to be a network connection failure instead. If using a proxy that listens forhttpsconnections from the cluster, you may need to configure the cluster to accept the CAs and certificates that the proxy uses. - 3
- A comma-separated list of destination domain names, domains, IP addresses or other network CIDRs to exclude proxying.
Preface a domain with
to match subdomains only. For example,.matches.y.com, but notx.y.com. Usey.comto bypass proxy for all destinations. If you scale up workers that are not included in the network defined by the*field from the installation configuration, you must add them to this list to prevent connection issues.networking.machineNetwork[].cidrThis field is ignored if neither the
orhttpProxyfields are set.httpsProxy - 4
- One or more URLs external to the cluster to use to perform a readiness check before writing the
httpProxyandhttpsProxyvalues to status. - 5
- A reference to the config map in the
openshift-confignamespace that contains additional CA certificates required for proxying HTTPS connections. Note that the config map must already exist before referencing it here. This field is required unless the proxy’s identity certificate is signed by an authority from the RHCOS trust bundle.
- Save the file to apply the changes.
8.3. Setting DNS to private Copia collegamentoCollegamento copiato negli appunti!
After you deploy a cluster, you can modify its DNS to use only a private zone.
Procedure
Review the
custom resource for your cluster:DNS$ oc get dnses.config.openshift.io/cluster -o yamlExample output
apiVersion: config.openshift.io/v1 kind: DNS metadata: creationTimestamp: "2019-10-25T18:27:09Z" generation: 2 name: cluster resourceVersion: "37966" selfLink: /apis/config.openshift.io/v1/dnses/cluster uid: 0e714746-f755-11f9-9cb1-02ff55d8f976 spec: baseDomain: <base_domain> privateZone: tags: Name: <infrastructure_id>-int kubernetes.io/cluster/<infrastructure_id>: owned publicZone: id: Z2XXXXXXXXXXA4 status: {}Note that the
section contains both a private and a public zone.specPatch the
custom resource to remove the public zone:DNS$ oc patch dnses.config.openshift.io/cluster --type=merge --patch='{"spec": {"publicZone": null}}' dns.config.openshift.io/cluster patchedBecause the Ingress Controller consults the
definition when it createsDNSobjects, when you create or modifyIngressobjects, only private records are created.IngressImportantDNS records for the existing Ingress objects are not modified when you remove the public zone.
Optional: Review the
custom resource for your cluster and confirm that the public zone was removed:DNS$ oc get dnses.config.openshift.io/cluster -o yamlExample output
apiVersion: config.openshift.io/v1 kind: DNS metadata: creationTimestamp: "2019-10-25T18:27:09Z" generation: 2 name: cluster resourceVersion: "37966" selfLink: /apis/config.openshift.io/v1/dnses/cluster uid: 0e714746-f755-11f9-9cb1-02ff55d8f976 spec: baseDomain: <base_domain> privateZone: tags: Name: <infrastructure_id>-int kubernetes.io/cluster/<infrastructure_id>-wfpg4: owned status: {}
8.4. Configuring ingress cluster traffic Copia collegamentoCollegamento copiato negli appunti!
OpenShift Container Platform provides the following methods for communicating from outside the cluster with services running in the cluster:
- If you have HTTP/HTTPS, use an Ingress Controller.
- If you have a TLS-encrypted protocol other than HTTPS, such as TLS with the SNI header, use an Ingress Controller.
- Otherwise, use a load balancer, an external IP, or a node port.
| Method | Purpose |
|---|---|
| Allows access to HTTP/HTTPS traffic and TLS-encrypted protocols other than HTTPS, such as TLS with the SNI header. | |
| Automatically assign an external IP by using a load balancer service | Allows traffic to non-standard ports through an IP address assigned from a pool. |
| Allows traffic to non-standard ports through a specific IP address. | |
| Expose a service on all nodes in the cluster. |
8.5. Configuring the node port service range Copia collegamentoCollegamento copiato negli appunti!
As a cluster administrator, you can expand the available node port range. If your cluster uses of a large number of node ports, you might need to increase the number of available ports.
The default port range is
30000-32767
8.5.1. Prerequisites Copia collegamentoCollegamento copiato negli appunti!
-
Your cluster infrastructure must allow access to the ports that you specify within the expanded range. For example, if you expand the node port range to , the inclusive port range of
30000-32900must be allowed by your firewall or packet filtering configuration.32768-32900
8.5.1.1. Expanding the node port range Copia collegamentoCollegamento copiato negli appunti!
You can expand the node port range for the cluster.
Prerequisites
-
Install the OpenShift CLI ().
oc -
Log in to the cluster with a user with privileges.
cluster-admin
Procedure
To expand the node port range, enter the following command. Replace
with the largest port number in the new range.<port>$ oc patch network.config.openshift.io cluster --type=merge -p \ '{ "spec": { "serviceNodePortRange": "30000-<port>" } }'TipYou can alternatively apply the following YAML to update the node port range:
apiVersion: config.openshift.io/v1 kind: Network metadata: name: cluster spec: serviceNodePortRange: "30000-<port>"Example output
network.config.openshift.io/cluster patchedTo confirm that the configuration is active, enter the following command. It can take several minutes for the update to apply.
$ oc get configmaps -n openshift-kube-apiserver config \ -o jsonpath="{.data['config\.yaml']}" | \ grep -Eo '"service-node-port-range":["[[:digit:]]+-[[:digit:]]+"]'Example output
"service-node-port-range":["30000-33000"]
8.6. Configuring IPsec encryption Copia collegamentoCollegamento copiato negli appunti!
With IPsec enabled, all network traffic between nodes on the OVN-Kubernetes Container Network Interface (CNI) cluster network travels through an encrypted tunnel.
IPsec is disabled by default.
8.6.1. Prerequisites Copia collegamentoCollegamento copiato negli appunti!
- Your cluster must use the OVN-Kubernetes cluster network provider.
8.6.1.1. Enabling IPsec encryption Copia collegamentoCollegamento copiato negli appunti!
As a cluster administrator, you can enable IPsec encryption after cluster installation.
Prerequisites
-
Install the OpenShift CLI ().
oc -
Log in to the cluster with a user with privileges.
cluster-admin -
You have reduced the size of your cluster MTU by bytes to allow for the overhead of the IPsec ESP header.
46
Procedure
To enable IPsec encryption, enter the following command:
$ oc patch networks.operator.openshift.io cluster --type=merge \ -p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"ipsecConfig":{ }}}}}'
8.6.1.2. Verifying that IPsec is enabled Copia collegamentoCollegamento copiato negli appunti!
As a cluster administrator, you can verify that IPsec is enabled.
Verification
To find the names of the OVN-Kubernetes control plane pods, enter the following command:
$ oc get pods -n openshift-ovn-kubernetes | grep ovnkube-masterExample output
ovnkube-master-4496s 1/1 Running 0 6h39m ovnkube-master-d6cht 1/1 Running 0 6h42m ovnkube-master-skblc 1/1 Running 0 6h51m ovnkube-master-vf8rf 1/1 Running 0 6h51m ovnkube-master-w7hjr 1/1 Running 0 6h51m ovnkube-master-zsk7x 1/1 Running 0 6h42mVerify that IPsec is enabled on your cluster:
$ oc -n openshift-ovn-kubernetes -c nbdb rsh ovnkube-master-<XXXXX> \ ovn-nbctl --no-leader-only get nb_global . ipsecwhere:
<XXXXX>- Specifies the random sequence of letters for a pod from the previous step.
Example output
true
8.7. Configuring network policy Copia collegamentoCollegamento copiato negli appunti!
As a cluster administrator or project administrator, you can configure network policies for a project.
8.7.1. About network policy Copia collegamentoCollegamento copiato negli appunti!
In a cluster using a Kubernetes Container Network Interface (CNI) plugin that supports Kubernetes network policy, network isolation is controlled entirely by
NetworkPolicy
Network policy does not apply to the host network namespace. Pods with host networking enabled are unaffected by network policy rules. However, pods connecting to the host-networked pods might be affected by the network policy rules.
Network policies cannot block traffic from localhost or from their resident nodes.
By default, all pods in a project are accessible from other pods and network endpoints. To isolate one or more pods in a project, you can create
NetworkPolicy
NetworkPolicy
If a pod is matched by selectors in one or more
NetworkPolicy
NetworkPolicy
NetworkPolicy
A network policy applies to only the TCP, UDP, ICMP, and SCTP protocols. Other protocols are not affected.
The following example
NetworkPolicy
Deny all traffic:
To make a project deny by default, add a
object that matches all pods but accepts no traffic:NetworkPolicykind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: deny-by-default spec: podSelector: {} ingress: []Only allow connections from the OpenShift Container Platform Ingress Controller:
To make a project allow only connections from the OpenShift Container Platform Ingress Controller, add the following
object.NetworkPolicyapiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-openshift-ingress spec: ingress: - from: - namespaceSelector: matchLabels: network.openshift.io/policy-group: ingress podSelector: {} policyTypes: - IngressOnly accept connections from pods within a project:
To make pods accept connections from other pods in the same project, but reject all other connections from pods in other projects, add the following
object:NetworkPolicykind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-same-namespace spec: podSelector: {} ingress: - from: - podSelector: {}Only allow HTTP and HTTPS traffic based on pod labels:
To enable only HTTP and HTTPS access to the pods with a specific label (
in following example), add arole=frontendobject similar to the following:NetworkPolicykind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-http-and-https spec: podSelector: matchLabels: role: frontend ingress: - ports: - protocol: TCP port: 80 - protocol: TCP port: 443Accept connections by using both namespace and pod selectors:
To match network traffic by combining namespace and pod selectors, you can use a
object similar to the following:NetworkPolicykind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-pod-and-namespace-both spec: podSelector: matchLabels: name: test-pods ingress: - from: - namespaceSelector: matchLabels: project: project_name podSelector: matchLabels: name: test-pods
NetworkPolicy
NetworkPolicy
For example, for the
NetworkPolicy
allow-same-namespace
allow-http-and-https
role=frontend
80
443
8.7.1.1. Using the allow-from-router network policy Copia collegamentoCollegamento copiato negli appunti!
Use the following
NetworkPolicy
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-from-router
spec:
ingress:
- from:
- namespaceSelector:
matchLabels:
policy-group.network.openshift.io/ingress: ""
podSelector: {}
policyTypes:
- Ingress
- 1
policy-group.network.openshift.io/ingress:""label supports both OpenShift-SDN and OVN-Kubernetes.
8.7.1.2. Using the allow-from-hostnetwork network policy Copia collegamentoCollegamento copiato negli appunti!
Add the following
allow-from-hostnetwork
NetworkPolicy
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-from-hostnetwork
spec:
ingress:
- from:
- namespaceSelector:
matchLabels:
policy-group.network.openshift.io/host-network: ""
podSelector: {}
policyTypes:
- Ingress
8.7.2. Example NetworkPolicy object Copia collegamentoCollegamento copiato negli appunti!
The following annotates an example NetworkPolicy object:
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: allow-27107
spec:
podSelector:
matchLabels:
app: mongodb
ingress:
- from:
- podSelector:
matchLabels:
app: app
ports:
- protocol: TCP
port: 27017
- 1
- The name of the NetworkPolicy object.
- 2
- A selector that describes the pods to which the policy applies. The policy object can only select pods in the project that defines the NetworkPolicy object.
- 3
- A selector that matches the pods from which the policy object allows ingress traffic. The selector matches pods in the same namespace as the NetworkPolicy.
- 4
- A list of one or more destination ports on which to accept traffic.
8.7.3. Creating a network policy using the CLI Copia collegamentoCollegamento copiato negli appunti!
To define granular rules describing ingress or egress network traffic allowed for namespaces in your cluster, you can create a network policy.
If you log in with a user with the
cluster-admin
Prerequisites
-
Your cluster uses a cluster network provider that supports objects, such as the OpenShift SDN network provider with
NetworkPolicyset. This mode is the default for OpenShift SDN.mode: NetworkPolicy -
You installed the OpenShift CLI ().
oc -
You are logged in to the cluster with a user with privileges.
admin - You are working in the namespace that the network policy applies to.
Procedure
Create a policy rule:
Create a
file:<policy_name>.yaml$ touch <policy_name>.yamlwhere:
<policy_name>- Specifies the network policy file name.
Define a network policy in the file that you just created, such as in the following examples:
Deny ingress from all pods in all namespaces
kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: deny-by-default spec: podSelector: ingress: []Allow ingress from all pods in the same namespace
kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-same-namespace spec: podSelector: ingress: - from: - podSelector: {}
To create the network policy object, enter the following command:
$ oc apply -f <policy_name>.yaml -n <namespace>where:
<policy_name>- Specifies the network policy file name.
<namespace>- Optional: Specifies the namespace if the object is defined in a different namespace than the current namespace.
Example output
networkpolicy.networking.k8s.io/default-deny created
If you log in to the web console with
cluster-admin
8.7.4. Configuring multitenant isolation by using network policy Copia collegamentoCollegamento copiato negli appunti!
You can configure your project to isolate it from pods and services in other project namespaces.
Prerequisites
-
Your cluster uses a cluster network provider that supports objects, such as the OpenShift SDN network provider with
NetworkPolicyset. This mode is the default for OpenShift SDN.mode: NetworkPolicy -
You installed the OpenShift CLI ().
oc -
You are logged in to the cluster with a user with privileges.
admin
Procedure
Create the following
objects:NetworkPolicyA policy named
.allow-from-openshift-ingress$ cat << EOF| oc create -f - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-openshift-ingress spec: ingress: - from: - namespaceSelector: matchLabels: policy-group.network.openshift.io/ingress: "" podSelector: {} policyTypes: - Ingress EOFNoteis the preferred namespace selector label for OpenShift SDN. You can use thepolicy-group.network.openshift.io/ingress: ""namespace selector label, but this is a legacy label.network.openshift.io/policy-group: ingressA policy named
:allow-from-openshift-monitoring$ cat << EOF| oc create -f - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-openshift-monitoring spec: ingress: - from: - namespaceSelector: matchLabels: network.openshift.io/policy-group: monitoring podSelector: {} policyTypes: - Ingress EOFA policy named
:allow-same-namespace$ cat << EOF| oc create -f - kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-same-namespace spec: podSelector: ingress: - from: - podSelector: {} EOFA policy named
:allow-from-kube-apiserver-operator$ cat << EOF| oc create -f - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-kube-apiserver-operator spec: ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: openshift-kube-apiserver-operator podSelector: matchLabels: app: kube-apiserver-operator policyTypes: - Ingress EOFFor more details, see New
kube-apiserver-operatorwebhook controller validating health of webhook.
Optional: To confirm that the network policies exist in your current project, enter the following command:
$ oc describe networkpolicyExample output
Name: allow-from-openshift-ingress Namespace: example1 Created on: 2020-06-09 00:28:17 -0400 EDT Labels: <none> Annotations: <none> Spec: PodSelector: <none> (Allowing the specific traffic to all pods in this namespace) Allowing ingress traffic: To Port: <any> (traffic allowed to all ports) From: NamespaceSelector: network.openshift.io/policy-group: ingress Not affecting egress traffic Policy Types: Ingress Name: allow-from-openshift-monitoring Namespace: example1 Created on: 2020-06-09 00:29:57 -0400 EDT Labels: <none> Annotations: <none> Spec: PodSelector: <none> (Allowing the specific traffic to all pods in this namespace) Allowing ingress traffic: To Port: <any> (traffic allowed to all ports) From: NamespaceSelector: network.openshift.io/policy-group: monitoring Not affecting egress traffic Policy Types: Ingress
8.7.5. Creating default network policies for a new project Copia collegamentoCollegamento copiato negli appunti!
As a cluster administrator, you can modify the new project template to automatically include
NetworkPolicy
8.7.6. Modifying the template for new projects Copia collegamentoCollegamento copiato negli appunti!
As a cluster administrator, you can modify the default project template so that new projects are created using your custom requirements.
To create your own custom project template:
Procedure
-
Log in as a user with privileges.
cluster-admin Generate the default project template:
$ oc adm create-bootstrap-project-template -o yaml > template.yaml-
Use a text editor to modify the generated file by adding objects or modifying existing objects.
template.yaml The project template must be created in the
namespace. Load your modified template:openshift-config$ oc create -f template.yaml -n openshift-configEdit the project configuration resource using the web console or CLI.
Using the web console:
-
Navigate to the Administration
Cluster Settings page. - Click Configuration to view all configuration resources.
- Find the entry for Project and click Edit YAML.
-
Navigate to the Administration
Using the CLI:
Edit the
resource:project.config.openshift.io/cluster$ oc edit project.config.openshift.io/cluster
Update the
section to include thespecandprojectRequestTemplateparameters, and set the name of your uploaded project template. The default name isname.project-requestProject configuration resource with custom project template
apiVersion: config.openshift.io/v1 kind: Project metadata: ... spec: projectRequestTemplate: name: <template_name>- After you save your changes, create a new project to verify that your changes were successfully applied.
8.7.6.1. Adding network policies to the new project template Copia collegamentoCollegamento copiato negli appunti!
As a cluster administrator, you can add network policies to the default template for new projects. OpenShift Container Platform will automatically create all the
NetworkPolicy
Prerequisites
-
Your cluster uses a default CNI network provider that supports objects, such as the OpenShift SDN network provider with
NetworkPolicyset. This mode is the default for OpenShift SDN.mode: NetworkPolicy -
You installed the OpenShift CLI ().
oc -
You must log in to the cluster with a user with privileges.
cluster-admin - You must have created a custom default project template for new projects.
Procedure
Edit the default template for a new project by running the following command:
$ oc edit template <project_template> -n openshift-configReplace
with the name of the default template that you configured for your cluster. The default template name is<project_template>.project-requestIn the template, add each
object as an element to theNetworkPolicyparameter. Theobjectsparameter accepts a collection of one or more objects.objectsIn the following example, the
parameter collection includes severalobjectsobjects.NetworkPolicyobjects: - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-same-namespace spec: podSelector: {} ingress: - from: - podSelector: {} - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-openshift-ingress spec: ingress: - from: - namespaceSelector: matchLabels: network.openshift.io/policy-group: ingress podSelector: {} policyTypes: - Ingress - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-kube-apiserver-operator spec: ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: openshift-kube-apiserver-operator podSelector: matchLabels: app: kube-apiserver-operator policyTypes: - Ingress ...Optional: Create a new project to confirm that your network policy objects are created successfully by running the following commands:
Create a new project:
$ oc new-project <project>1 - 1
- Replace
<project>with the name for the project you are creating.
Confirm that the network policy objects in the new project template exist in the new project:
$ oc get networkpolicy NAME POD-SELECTOR AGE allow-from-openshift-ingress <none> 7s allow-from-same-namespace <none> 7s
8.8. Supported configurations Copia collegamentoCollegamento copiato negli appunti!
The following configurations are supported for the current release of Red Hat OpenShift Service Mesh.
8.8.1. Supported platforms Copia collegamentoCollegamento copiato negli appunti!
The Red Hat OpenShift Service Mesh Operator supports multiple versions of the
ServiceMeshControlPlane
- Red Hat OpenShift Container Platform version 4.10 or later.
- Red Hat OpenShift Dedicated version 4.
- Azure Red Hat OpenShift (ARO) version 4.
- Red Hat OpenShift Service on AWS (ROSA).
8.8.2. Unsupported configurations Copia collegamentoCollegamento copiato negli appunti!
Explicitly unsupported cases include:
- OpenShift Online is not supported for Red Hat OpenShift Service Mesh.
- Red Hat OpenShift Service Mesh does not support the management of microservices outside the cluster where Service Mesh is running.
8.8.3. Supported network configurations Copia collegamentoCollegamento copiato negli appunti!
Red Hat OpenShift Service Mesh supports the following network configurations.
- OpenShift-SDN
- OVN-Kubernetes is available on all supported versions of OpenShift Container Platform.
- Third-Party Container Network Interface (CNI) plugins that have been certified on OpenShift Container Platform and passed Service Mesh conformance testing. See Certified OpenShift CNI Plug-ins for more information.
8.8.4. Supported configurations for Service Mesh Copia collegamentoCollegamento copiato negli appunti!
This release of Red Hat OpenShift Service Mesh is only available on OpenShift Container Platform x86_64, IBM Z, and IBM Power.
- IBM Z is only supported on OpenShift Container Platform 4.10 and later.
- IBM Power is only supported on OpenShift Container Platform 4.10 and later.
- Configurations where all Service Mesh components are contained within a single OpenShift Container Platform cluster.
- Configurations that do not integrate external services such as virtual machines.
-
Red Hat OpenShift Service Mesh does not support configuration except where explicitly documented.
EnvoyFilter
8.8.5. Supported configurations for Kiali Copia collegamentoCollegamento copiato negli appunti!
- The Kiali console is only supported on the two most recent releases of the Google Chrome, Microsoft Edge, Mozilla Firefox, or Apple Safari browsers.
-
The authentication strategy is the only supported authentication configuration when Kiali is deployed with Red Hat OpenShift Service Mesh (OSSM). The
openshiftstrategy controls access based on the individual’s role-based access control (RBAC) roles of the OpenShift Container Platform.openshift
8.8.6. Supported configurations for Distributed Tracing Copia collegamentoCollegamento copiato negli appunti!
- Jaeger agent as a sidecar is the only supported configuration for Jaeger. Jaeger as a daemonset is not supported for multitenant installations or OpenShift Dedicated.
8.8.7. Supported WebAssembly module Copia collegamentoCollegamento copiato negli appunti!
- 3scale WebAssembly is the only provided WebAssembly module. You can create custom WebAssembly modules.
8.8.8. Operator overview Copia collegamentoCollegamento copiato negli appunti!
Red Hat OpenShift Service Mesh requires the following four Operators:
- OpenShift Elasticsearch - (Optional) Provides database storage for tracing and logging with the distributed tracing platform (Jaeger). It is based on the open source Elasticsearch project.
- Red Hat OpenShift distributed tracing platform (Jaeger) - Provides distributed tracing to monitor and troubleshoot transactions in complex distributed systems. It is based on the open source Jaeger project.
- Kiali Operator provided by Red Hat - Provides observability for your service mesh. You can view configurations, monitor traffic, and analyze traces in a single console. It is based on the open source Kiali project.
-
Red Hat OpenShift Service Mesh - Allows you to connect, secure, control, and observe the microservices that comprise your applications. The Service Mesh Operator defines and monitors the resources that manage the deployment, updating, and deletion of the Service Mesh components. It is based on the open source Istio project.
ServiceMeshControlPlane
Next steps
- Install Red Hat OpenShift Service Mesh in your OpenShift Container Platform environment.
8.9. Optimizing routing Copia collegamentoCollegamento copiato negli appunti!
The OpenShift Container Platform HAProxy router can be scaled or configured to optimize performance.
8.9.1. Baseline Ingress Controller (router) performance Copia collegamentoCollegamento copiato negli appunti!
The OpenShift Container Platform Ingress Controller, or router, is the ingress point for ingress traffic for applications and services that are configured using routes and ingresses.
When evaluating a single HAProxy router performance in terms of HTTP requests handled per second, the performance varies depending on many factors. In particular:
- HTTP keep-alive/close mode
- Route type
- TLS session resumption client support
- Number of concurrent connections per target route
- Number of target routes
- Back end server page size
- Underlying infrastructure (network/SDN solution, CPU, and so on)
While performance in your specific environment will vary, Red Hat lab tests on a public cloud instance of size 4 vCPU/16GB RAM. A single HAProxy router handling 100 routes terminated by backends serving 1kB static pages is able to handle the following number of transactions per second.
In HTTP keep-alive mode scenarios:
| Encryption | LoadBalancerService | HostNetwork |
|---|---|---|
| none | 21515 | 29622 |
| edge | 16743 | 22913 |
| passthrough | 36786 | 53295 |
| re-encrypt | 21583 | 25198 |
In HTTP close (no keep-alive) scenarios:
| Encryption | LoadBalancerService | HostNetwork |
|---|---|---|
| none | 5719 | 8273 |
| edge | 2729 | 4069 |
| passthrough | 4121 | 5344 |
| re-encrypt | 2320 | 2941 |
The default Ingress Controller configuration was used with the
spec.tuningOptions.threadCount
4
When running on bare metal with modern processors, you can expect roughly twice the performance of the public cloud instance above. This overhead is introduced by the virtualization layer in place on public clouds and holds mostly true for private cloud-based virtualization as well. The following table is a guide to how many applications to use behind the router:
| Number of applications | Application type |
|---|---|
| 5-10 | static file/web server or caching proxy |
| 100-1000 | applications generating dynamic content |
In general, HAProxy can support routes for up to 1000 applications, depending on the technology in use. Ingress Controller performance might be limited by the capabilities and performance of the applications behind it, such as language or static versus dynamic content.
Ingress, or router, sharding should be used to serve more routes towards applications and help horizontally scale the routing tier.
8.10. Postinstallation RHOSP network configuration Copia collegamentoCollegamento copiato negli appunti!
You can configure some aspects of an OpenShift Container Platform on Red Hat OpenStack Platform (RHOSP) cluster after installation.
8.10.1. Configuring application access with floating IP addresses Copia collegamentoCollegamento copiato negli appunti!
After you install OpenShift Container Platform, configure Red Hat OpenStack Platform (RHOSP) to allow application network traffic.
You do not need to perform this procedure if you provided values for
platform.openstack.apiFloatingIP
platform.openstack.ingressFloatingIP
install-config.yaml
os_api_fip
os_ingress_fip
inventory.yaml
Prerequisites
- OpenShift Container Platform cluster must be installed
- Floating IP addresses are enabled as described in the OpenShift Container Platform on RHOSP installation documentation.
Procedure
After you install the OpenShift Container Platform cluster, attach a floating IP address to the ingress port:
Show the port:
$ openstack port show <cluster_name>-<cluster_ID>-ingress-portAttach the port to the IP address:
$ openstack floating ip set --port <ingress_port_ID> <apps_FIP>Add a wildcard
record forAto your DNS file:*apps.*.apps.<cluster_name>.<base_domain> IN A <apps_FIP>
If you do not control the DNS server but want to enable application access for non-production purposes, you can add these hostnames to
/etc/hosts
<apps_FIP> console-openshift-console.apps.<cluster name>.<base domain>
<apps_FIP> integrated-oauth-server-openshift-authentication.apps.<cluster name>.<base domain>
<apps_FIP> oauth-openshift.apps.<cluster name>.<base domain>
<apps_FIP> prometheus-k8s-openshift-monitoring.apps.<cluster name>.<base domain>
<apps_FIP> <app name>.apps.<cluster name>.<base domain>
8.10.2. Kuryr ports pools Copia collegamentoCollegamento copiato negli appunti!
A Kuryr ports pool maintains a number of ports on standby for pod creation.
Keeping ports on standby minimizes pod creation time. Without ports pools, Kuryr must explicitly request port creation or deletion whenever a pod is created or deleted.
The Neutron ports that Kuryr uses are created in subnets that are tied to namespaces. These pod ports are also added as subports to the primary port of OpenShift Container Platform cluster nodes.
Because Kuryr keeps each namespace in a separate subnet, a separate ports pool is maintained for each namespace-worker pair.
Prior to installing a cluster, you can set the following parameters in the
cluster-network-03-config.yml
-
The parameter controls pool prepopulation, which forces Kuryr to add Neutron ports to the pools when the first pod that is configured to use the dedicated network for pods is created in a namespace. The default value is
enablePortPoolsPrepopulation.false -
The parameter is the minimum number of free ports that are kept in the pool. The default value is
poolMinPorts.1 The
parameter is the maximum number of free ports that are kept in the pool. A value ofpoolMaxPortsdisables that upper bound. This is the default setting.0If your OpenStack port quota is low, or you have a limited number of IP addresses on the pod network, consider setting this option to ensure that unneeded ports are deleted.
-
The parameter defines the maximum number of Neutron ports that can be created at once. The default value is
poolBatchPorts.3
8.10.3. Adjusting Kuryr ports pool settings in active deployments on RHOSP Copia collegamentoCollegamento copiato negli appunti!
You can use a custom resource (CR) to configure how Kuryr manages Red Hat OpenStack Platform (RHOSP) Neutron ports to control the speed and efficiency of pod creation on a deployed cluster.
Procedure
From a command line, open the Cluster Network Operator (CNO) CR for editing:
$ oc edit networks.operator.openshift.io clusterEdit the settings to meet your requirements. The following file is provided as an example:
apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec: clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23 serviceNetwork: - 172.30.0.0/16 defaultNetwork: type: Kuryr kuryrConfig: enablePortPoolsPrepopulation: false1 poolMinPorts: 12 poolBatchPorts: 33 poolMaxPorts: 54 - 1
- Set
enablePortPoolsPrepopulationtotrueto make Kuryr create Neutron ports when the first pod that is configured to use the dedicated network for pods is created in a namespace. This setting raises the Neutron ports quota but can reduce the time that is required to spawn pods. The default value isfalse. - 2
- Kuryr creates new ports for a pool if the number of free ports in that pool is lower than the value of
poolMinPorts. The default value is1. - 3
poolBatchPortscontrols the number of new ports that are created if the number of free ports is lower than the value ofpoolMinPorts. The default value is3.- 4
- If the number of free ports in a pool is higher than the value of
poolMaxPorts, Kuryr deletes them until the number matches that value. Setting the value to0disables this upper bound, preventing pools from shrinking. The default value is0.
- Save your changes and quit the text editor to commit your changes.
Modifying these options on a running cluster forces the kuryr-controller and kuryr-cni pods to restart. As a result, the creation of new pods and services will be delayed.
8.10.4. Enabling OVS hardware offloading Copia collegamentoCollegamento copiato negli appunti!
For clusters that run on Red Hat OpenStack Platform (RHOSP), you can enable Open vSwitch (OVS) hardware offloading.
OVS is a multi-layer virtual switch that enables large-scale, multi-server network virtualization.
Prerequisites
- You installed a cluster on RHOSP that is configured for single-root input/output virtualization (SR-IOV).
- You installed the SR-IOV Network Operator on your cluster.
-
You created two type virtual function (VF) interfaces on your cluster.
hw-offload
Application layer gateway flows are broken in OpenShift Container Platform version 4.10, 4.11, and 4.12. Also, you cannot offload the application layer gateway flow for OpenShift Container Platform version 4.13.
Procedure
Create an
policy for the twoSriovNetworkNodePolicytype VF interfaces that are on your cluster:hw-offloadThe first virtual function interface
apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetworkNodePolicy1 metadata: name: "hwoffload9" namespace: openshift-sriov-network-operator spec: deviceType: netdevice isRdma: true nicSelector: pfNames:2 - ens6 nodeSelector: feature.node.kubernetes.io/network-sriov.capable: 'true' numVfs: 1 priority: 99 resourceName: "hwoffload9"The second virtual function interface
apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetworkNodePolicy1 metadata: name: "hwoffload10" namespace: openshift-sriov-network-operator spec: deviceType: netdevice isRdma: true nicSelector: pfNames:2 - ens5 nodeSelector: feature.node.kubernetes.io/network-sriov.capable: 'true' numVfs: 1 priority: 99 resourceName: "hwoffload10"Create
resources for the two interfaces:NetworkAttachmentDefinitionA
NetworkAttachmentDefinitionresource for the first interfaceapiVersion: k8s.cni.cncf.io/v1 kind: NetworkAttachmentDefinition metadata: annotations: k8s.v1.cni.cncf.io/resourceName: openshift.io/hwoffload9 name: hwoffload9 namespace: default spec: config: '{ "cniVersion":"0.3.1", "name":"hwoffload9","type":"host-device","device":"ens6" }'A
NetworkAttachmentDefinitionresource for the second interfaceapiVersion: k8s.cni.cncf.io/v1 kind: NetworkAttachmentDefinition metadata: annotations: k8s.v1.cni.cncf.io/resourceName: openshift.io/hwoffload10 name: hwoffload10 namespace: default spec: config: '{ "cniVersion":"0.3.1", "name":"hwoffload10","type":"host-device","device":"ens5" }'Use the interfaces that you created with a pod. For example:
A pod that uses the two OVS offload interfaces
apiVersion: v1 kind: Pod metadata: name: dpdk-testpmd namespace: default annotations: irq-load-balancing.crio.io: disable cpu-quota.crio.io: disable k8s.v1.cni.cncf.io/resourceName: openshift.io/hwoffload9 k8s.v1.cni.cncf.io/resourceName: openshift.io/hwoffload10 spec: restartPolicy: Never containers: - name: dpdk-testpmd image: quay.io/krister/centos8_nfv-container-dpdk-testpmd:latest
8.10.5. Attaching an OVS hardware offloading network Copia collegamentoCollegamento copiato negli appunti!
You can attach an Open vSwitch (OVS) hardware offloading network to your cluster.
Prerequisites
- Your cluster is installed and running.
- You provisioned an OVS hardware offloading network on Red Hat OpenStack Platform (RHOSP) to use with your cluster.
Procedure
Create a file named
from the following template:network.yamlspec: additionalNetworks: - name: hwoffload1 namespace: cnf rawCNIConfig: '{ "cniVersion": "0.3.1", "name": "hwoffload1", "type": "host-device","pciBusId": "0000:00:05.0", "ipam": {}}'1 type: Rawwhere:
pciBusIdSpecifies the device that is connected to the offloading network. If you do not have it, you can find this value by running the following command:
$ oc describe SriovNetworkNodeState -n openshift-sriov-network-operator
From a command line, enter the following command to patch your cluster with the file:
$ oc apply -f network.yaml