Este conteúdo não está disponível no idioma selecionado.
Chapter 2. Understanding networking settings
Learn how to apply networking customization and default settings to MicroShift deployments. Each node is contained to a single machine and single MicroShift, so each deployment requires individual configuration, pods, and settings.
Cluster Administrators have several options for exposing applications that run inside a cluster to external traffic and securing network connections:
- A service such as NodePort
-
API resources, such as
IngressandRoute
By default, Kubernetes allocates each pod an internal IP address for applications running within the pod. Pods and their containers can have traffic between them, but clients outside the cluster do not have direct network access to pods except when exposed with a service such as NodePort.
To troubleshoot connection problems with the NodePort service, read about the known issue in the Release Notes.
2.1. Creating an OVN-Kubernetes configuration file Copiar o linkLink copiado para a área de transferência!
MicroShift uses built-in default OVN-Kubernetes values if an OVN-Kubernetes configuration file is not created. You can write an OVN-Kubernetes configuration file to /etc/microshift/ovn.yaml. An example file is provided for your configuration.
Procedure
To create your
ovn.yamlfile, run the following command:$ sudo cp /etc/microshift/ovn.yaml.default /etc/microshift/ovn.yamlTo list the contents of the configuration file you created, run the following command:
$ cat /etc/microshift/ovn.yaml.defaultExample YAML file with default maximum transmission unit (MTU) value
mtu: 1400To customize your configuration, you can change the MTU value. The table that follows provides details:
Expand Table 2.1. Supported optional OVN-Kubernetes configurations for MicroShift Field Type Default Description Example mtu
uint32
auto
MTU value used for the pods
1300
ImportantIf you change the
mtuconfiguration value in theovn.yamlfile, you must restart the host that Red Hat build of MicroShift is running on to apply the updated setting.Example custom
ovn.yamlconfiguration filemtu: 1300
2.2. Restarting the ovnkube-master pod Copiar o linkLink copiado para a área de transferência!
The following procedure restarts the ovnkube-master pod.
Prerequisites
-
The OpenShift CLI (
oc) is installed. -
Access to the cluster as a user with the
cluster-adminrole. - A cluster installed on infrastructure configured with the OVN-Kubernetes network plugin.
- The KUBECONFIG environment variable is set.
Procedure
Use the following steps to restart the ovnkube-master pod.
Access the remote cluster by running the following command:
$ export KUBECONFIG=$PWD/kubeconfigFind the name of the
ovnkube-masterpod that you want to restart by running the following command:$ pod=$(oc get pods -n openshift-ovn-kubernetes | awk -F " " '/ovnkube-master/{print $1}')Delete the
ovnkube-masterpod by running the following command:$ oc -n openshift-ovn-kubernetes delete pod $podConfirm that a new
ovnkube-masterpod is running by using the following command:$ oc get pods -n openshift-ovn-kubernetesThe listing of the running pods shows a new
ovnkube-masterpod name and age.
2.3. Deploying MicroShift behind an HTTP(S) proxy Copiar o linkLink copiado para a área de transferência!
Deploy a MicroShift cluster behind an HTTP(S) proxy when you want to add basic anonymity and security measures to your pods.
You must configure the host operating system to use the proxy service with all components initiating HTTP(S) requests when deploying MicroShift behind a proxy.
All the user-specific workloads or pods with egress traffic, such as accessing cloud services, must be configured to use the proxy. There is no built-in transparent proxying of egress traffic in MicroShift.
2.4. Using the RPM-OStree HTTP(S) proxy Copiar o linkLink copiado para a área de transferência!
To use the HTTP(S) proxy in RPM-OStree, you must add a Service section to the configuration file and set the http_proxy environment variable for the rpm-ostreed service.
Procedure
Add this setting to the
/etc/systemd/system/rpm-ostreed.service.d/00-proxy.conffile:[Service] Environment="http_proxy=http://$PROXY_USER:$PROXY_PASSWORD@$PROXY_SERVER:$PROXY_PORT/"Next, reload the configuration settings and restart the service to apply your changes.
Reload the configuration settings by running the following command:
$ sudo systemctl daemon-reloadRestart the
rpm-ostreedservice by running the following command:$ sudo systemctl restart rpm-ostreed.service
2.5. Using a proxy in the CRI-O container runtime Copiar o linkLink copiado para a área de transferência!
To use an HTTP(S) proxy in CRI-O, you must add a Service section to the configuration file and set the HTTP_PROXY and HTTPS_PROXY environment variables. You can also set the NO_PROXY variable to exclude a list of hosts from being proxied.
Procedure
Create the directory for the configuration file if it does not exist:
$ sudo mkdir /etc/systemd/system/crio.service.d/Add the following settings to the
/etc/systemd/system/crio.service.d/00-proxy.conffile:[Service] Environment=NO_PROXY="localhost,127.0.0.1" Environment=HTTP_PROXY="http://$PROXY_USER:$PROXY_PASSWORD@$PROXY_SERVER:$PROXY_PORT/" Environment=HTTPS_PROXY="http://$PROXY_USER:$PROXY_PASSWORD@$PROXY_SERVER:$PROXY_PORT/"ImportantYou must define the
Servicesection of the configuration file for the environment variables or the proxy settings fail to apply.Reload the configuration settings:
$ sudo systemctl daemon-reloadRestart the CRI-O service:
$ sudo systemctl restart crioRestart the MicroShift service to apply the settings:
$ sudo systemctl restart microshift
Verification
Verify that pods are started by running the following command and examining the output:
$ oc get all -AVerify that MicroShift is able to pull container images by running the following command and examining the output:
$ sudo crictl images
2.6. Getting a snapshot of OVS interfaces from a running cluster Copiar o linkLink copiado para a área de transferência!
A snapshot represents the state and data of OVS interfaces at a specific point in time.
Procedure
To see a snapshot of OVS interfaces from a running MicroShift cluster, use the following command:
$ sudo ovs-vsctl showExample OVS interfaces in a running cluster
9d9f5ea2-9d9d-4e34-bbd2-dbac154fdc93 Bridge br-ex Port br-ex Interface br-ex type: internal Port patch-br-ex_localhost.localdomain-to-br-int1 Interface patch-br-ex_localhost.localdomain-to-br-int type: patch options: {peer=patch-br-int-to-br-ex_localhost.localdomain}2 Bridge br-int fail_mode: secure datapath_type: system Port patch-br-int-to-br-ex_localhost.localdomain Interface patch-br-int-to-br-ex_localhost.localdomain type: patch options: {peer=patch-br-ex_localhost.localdomain-to-br-int} Port eebee1ce5568761 Interface eebee1ce55687613 Port b47b1995ada84f4 Interface b47b1995ada84f44 Port "3031f43d67c167f" Interface "3031f43d67c167f"5 Port br-int Interface br-int type: internal Port ovn-k8s-mp06 Interface ovn-k8s-mp0 type: internal ovs_version: "2.17.3"- 1
- The
patch-br-ex_localhost.localdomain-to-br-intandpatch-br-int-to-br-ex_localhost.localdomainare OVS patch ports that connectbr-exandbr-int. - 2
- The
patch-br-ex_localhost.localdomain-to-br-intandpatch-br-int-to-br-ex_localhost.localdomainare OVS patch ports that connectbr-exandbr-int. - 3
- The pod interface
eebee1ce5568761is named with the first 15 bits of the pod sandbox ID and is plugged into thebr-intbridge. - 4
- The pod interface
b47b1995ada84f4is named with the first 15 bits of the pod sandbox ID and is plugged into thebr-intbridge. - 5
- The pod interface
3031f43d67c167fis named with the first 15 bits of the pod sandbox ID and is plugged into thebr-intbridge. - 6
- The OVS internal port for hairpin traffic,
ovn-k8s-mp0is created by theovnkube-mastercontainer.
2.7. Deploying a load balancer for a workload Copiar o linkLink copiado para a área de transferência!
MicroShift has a built-in implementation of network load balancers. The following example procedure uses the node IP address as the external IP address for the LoadBalancer service configuration file. You can use this example as guidance for how to deploy load balancers for your workloads.
Prerequisites
-
The OpenShift CLI (
oc) is installed. - You have access to the cluster as a user with the cluster administration role.
- You installed a cluster on an infrastructure configured with the OVN-Kubernetes network plugin.
-
The
KUBECONFIGenvironment variable is set.
Procedure
Verify that your pods are running by running the following command:
$ oc get pods -ACreate the example namespace by running the following commands:
$ NAMESPACE=nginx-lb-test$ oc create ns $NAMESPACEThe following example deploys three replicas of the test
nginxapplication in your namespace:$ oc apply -n $NAMESPACE -f - <<EOF apiVersion: v1 kind: ConfigMap metadata: name: nginx data: headers.conf: | add_header X-Server-IP \$server_addr always; --- apiVersion: apps/v1 kind: Deployment metadata: name: nginx spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - image: quay.io/packit/nginx-unprivileged imagePullPolicy: Always name: nginx ports: - containerPort: 8080 volumeMounts: - name: nginx-configs subPath: headers.conf mountPath: /etc/nginx/conf.d/headers.conf securityContext: allowPrivilegeEscalation: false seccompProfile: type: RuntimeDefault capabilities: drop: ["ALL"] runAsNonRoot: true volumes: - name: nginx-configs configMap: name: nginx items: - key: headers.conf path: headers.conf EOFYou can verify that the three sample replicas started successfully by running the following command:
$ oc get pods -n $NAMESPACECreate a
LoadBalancerservice for thenginxtest application with the following sample commands:$ oc create -n $NAMESPACE -f - <<EOF apiVersion: v1 kind: Service metadata: name: nginx spec: ports: - port: 81 targetPort: 8080 selector: app: nginx type: LoadBalancer EOFNoteYou must ensure that the
portparameter is a host port that is not occupied by otherLoadBalancerservices or Red Hat build of MicroShift components.Verify that the service file exists, that the external IP address is properly assigned, and that the external IP is identical to the node IP by running the following command:
$ oc get svc -n $NAMESPACEExample output
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nginx LoadBalancer 10.43.183.104 192.168.1.241 81:32434/TCP 2m
Verification
The following command forms five connections to the example
nginxapplication using the external IP address of theLoadBalancerservice configuration. The result of the command is a list of those server IP addresses. Verify that the load balancer sends requests to all the running applications with the following command:EXTERNAL_IP=192.168.1.241 seq 5 | xargs -Iz curl -s -I http://$EXTERNAL_IP:81 | grep X-Server-IPThe output of the previous command contains different IP addresses if the load balancer is successfully distributing the traffic to the applications, for example:
Example output
X-Server-IP: 10.42.0.41 X-Server-IP: 10.42.0.41 X-Server-IP: 10.42.0.43 X-Server-IP: 10.42.0.41 X-Server-IP: 10.42.0.43
2.8. Blocking external access to the NodePort service on a specific host interface Copiar o linkLink copiado para a área de transferência!
OVN-Kubernetes does not restrict the host interface where a NodePort service can be accessed from outside a Red Hat build of MicroShift node. The following procedure explains how to block the NodePort service on a specific host interface and restrict external access.
Prerequisites
- You must have an account with root privileges.
Procedure
Change the
NODEPORTvariable to the host port number assigned to your Kubernetes NodePort service by running the following command:# export NODEPORT=30700Change the
INTERFACE_IPvalue to the IP address from the host interface that you want to block. For example:# export INTERFACE_IP=192.168.150.33Insert a new rule in the
nattable PREROUTING chain to drop all packets that match the destination port and IP address. For example:$ sudo nft -a insert rule ip nat PREROUTING tcp dport $NODEPORT ip daddr $INTERFACE_IP dropList the new rule by running the following command:
$ sudo nft -a list chain ip nat PREROUTING table ip nat { chain PREROUTING { # handle 1 type nat hook prerouting priority dstnat; policy accept; tcp dport 30700 ip daddr 192.168.150.33 drop # handle 134 counter packets 108 bytes 18074 jump OVN-KUBE-ETP # handle 116 counter packets 108 bytes 18074 jump OVN-KUBE-EXTERNALIP # handle 114 counter packets 108 bytes 18074 jump OVN-KUBE-NODEPORT # handle 112 } }NoteNote the
handlenumber of the newly added rule. You need to remove thehandlenumber in the following step.Remove the custom rule with the following sample command:
$ sudo nft -a delete rule ip nat PREROUTING handle 134
2.9. The multicast DNS protocol Copiar o linkLink copiado para a área de transferência!
You can use the multicast DNS protocol (mDNS) to allow name resolution and service discovery within a Local Area Network (LAN) using multicast exposed on the 5353/UDP port.
MicroShift includes an embedded mDNS server for deployment scenarios in which the authoritative DNS server cannot be reconfigured to point clients to services on MicroShift. The embedded DNS server allows .local domains exposed by MicroShift to be discovered by other elements on the LAN.