Angepasste Teilnetze beim Erstellen Ihrer Position definieren

Bei der Erstellung von Standorten

Wenn Sie Ihren Standort in der Befehlszeilenschnittstelle erstellen, können Sie die folgenden Parameter definieren, um den Netzbetrieb an Ihrem Standort anzupassen. Weitere Informationen finden Sie in der Referenz für den Befehl ibmcloud sat location create.

Sie können die Option --pod-subnet angeben, um ein angepasstes Teilnetz-CIDR anzugeben, um private IP-Adressen für Pods bereitzustellen. Diese Option kann nur verwendet werden, wenn Sie zusätzlich Red Hat unter CoreOS mit dem Flag --coreos-enabled aktivieren. Das Subnetz muss mindestens oder /23 größer sein. Der Standardwert ist 172.16.0.0/16.

Sie können auch die Option --service-subnet angeben, um ein angepasstes Teilnetz-CIDR anzugeben, um private IP-Adressen für Services bereitzustellen. Diese Option kann nur verwendet werden, wenn Sie zusätzlich Red Hat unter CoreOS mit dem Flag --coreos-enabled aktivieren. Das Subnetz muss mindestens oder /24 größer sein. Der Standardwert ist 172.20.0.0/16.

Pod-Netzschnittstelle beim Erstellen des Standorts definieren

Bei der Erstellung von Standorten

Wenn Sie Ihren Standort in der Befehlszeilenschnittstelle (CLI) erstellen, können Sie --pod-network-interface definieren, um die Pod-Netzschnittstelle festzulegen. Die verfügbaren Methoden sind can-reach und interface.

• Um eine direkte URL oder IP-Adresse anzugeben, geben Sie can-reach=<url> oder can-reach=<ip_address> an. Wenn die Netzwerkschnittstelle die angegebene URL oder IP-Adresse erreichen kann, wird diese Option verwendet. Verwenden Sie zum Beispiel can-reach=www.exampleurl.com für die Angabe einer URL und can-reach=172.19.0.0 für die Angabe einer IP-Adresse.
• Um eine Schnittstelle mit einer Regex-Zeichenfolge auszuwählen, geben Sie interface=<regex_string> an, z. B. interface=eth.*.

Weitere Informationen finden Sie in der Referenz für den Befehl ibmcloud sat location create.

Pod-Netzschnittstelle beim Erstellen Ihres Clusters definieren

Während der Erstellung des Clusters

Wenn Sie Ihren Cluster in der Befehlszeilenschnittstelle erstellen, können Sie die --pod-network-interface definieren, um die Pod-Netzschnittstelle festzulegen. Die verfügbaren Methoden sind can-reach und interface.

• Um eine direkte URL oder IP-Adresse anzugeben, geben Sie can-reach=<url> oder can-reach=<ip_address> an. Wenn die Netzwerkschnittstelle die angegebene URL oder IP-Adresse erreichen kann, wird diese Option verwendet. Verwenden Sie zum Beispiel can-reach=www.exampleurl.com für die Angabe einer URL und can-reach=172.19.0.0 für die Angabe einer IP-Adresse.
• Um eine Schnittstelle mit einer Regex-Zeichenfolge auszuwählen, geben Sie interface=<regex_string> an, z. B. interface=eth.*.

Weitere Informationen finden Sie in der Referenz für den Befehl ibmcloud oc cluster create satellite.

Begrenzen des Zugriffs auf Ihren Satellite-Cluster

Nach Standort- und Clusterbildung

Nachdem Sie Ihren Standort und Cluster erstellt haben, können Sie den Befehl ibmcloud ks cluster master satellite-service-endpoint allowlist add verwenden, um ein Teilnetz zur Zulassungsliste des Serviceendpunkts eines Satellite-Clusters hinzuzufügen. Autorisierte Anfragen an den Cluster-Master, die aus dem Subnetz stammen, werden über den Endpunkt des Satellite-Dienstes zugelassen. Die Zulassungsliste muss aktiviert sein, damit die Einschränkungen gelten.

Netzrichtlinien mithilfe von Calico-Hostendpunkten erstellen

Nach Standort- und Clusterbildung

Wenn Sie einen Satellite-Cluster der Version 4.12 und höher erstellen, gibt es Calico Hostendpoint-Instanzen, die im Cluster für die Netzschnittstelle jedes Workerknotens bereitgestellt werden.

Sie können diese Hostendpoint-Instanzen verwenden, um globale Netzrichtlinien mithilfe der Bezeichnung “ibm-cloud.kubernetes.io/interface-name: <network_interface_name>” zu definieren, die jeder Hostendpoint-Instanz hinzugefügt wird.

Zusätzlich zu dieser Bezeichnung werden alle Bezeichnungen des Workerknotens für zusätzliche Anpassungsoptionen hinzugefügt.

Diese Hostendpoints haben das Profil “projectcalico-default-allow", was bedeutet, dass diese Hostendpoints das zuvor erwartete Verhalten ändern können, wenn Sie auf 4.12 aktualisieren.

Stellen Sie vor der Aktualisierung auf 4.12sicher, dass alle zuvor erwarteten Netzbetriebsregeln, Richtlinien und Hostendpoints nach der Aktualisierung identisch sind.

Weitere Informationen finden Sie in der Dokumentation zuCalico.

NodePort-Servicezugriff beschränken

Nach Standort- und Clusterbildung

Standardmäßig sind die NodePort-Services über alle Netzschnittstellen zugänglich, die für den Cluster verfügbar sind, z. B. 0.0.0.0.

An Satellite-Standorten, an denen mehrere Netze für die Hosts verfügbar sind, können Sie die verfügbaren Netzschnittstellen für Ihre Services jedoch begrenzen.

Um den Bereich zu begrenzen, beschränken Sie die Empfangsadressen für NodePort-Services auf Clusterebene. Diese Einschränkung ermöglicht es dem Clusteradministrator, den Zugriff auf eine bestimmte Netzschnittstelle zu beschränken, indem das IP-Teilnetz als zulässiger Empfangsadressbereich verwendet wird. Führen Sie die folgenden Schritte aus, um die Komponente kube-proxy neu zu konfigurieren, um den Empfangsadressbereich für Ihre NodePort-Services zu begrenzen.

Wenn Sie node-port-addresses nicht ordnungsgemäß konfigurieren, werden Ihre Services möglicherweise von gültigen Quellen isoliert. Stellen Sie sicher, dass Sie alle erforderlichen Subnetze einplanen, die Ihr Dienst benötigt. IBM Cloud benötigt keinen Zugriff auf ein Subnetz, um Ihre Cluster zu verwalten.

1. Rufen Sie Ihren Red Hat OpenShift-Cluster auf.

2. Bereiten Sie Ihre geplante Teilnetz-CIDR-Liste vor, die Sie für den Zugriff auf die NodePort-Services zulassen möchten.

3. Führen Sie den folgenden Befehl aus, um die network.operator.openshift.io-Konfiguration abzurufen, und speichern Sie eine Kopie, falls Sie die Änderungen zurücksetzen müssen.

   kubectl get network.operator.openshift.io cluster -o yaml
   

4. Bearbeiten Sie die network.operator.openshift.io-Konfiguration, legen Sie die Teilnetzliste im Abschnitt spec fest und schließen Sie die erforderlichen Teilnetze für Ihren NodePort-Service ein.

   spec:
     kubeProxyConfig:
       proxyArguments:
         node-port-addresses:
         - 192.0.2.0/24
         - 198.51.100.0/24
   

5. Speichern Sie Ihre Änderungen und wenden Sie sie auf den Cluster an.

   oc apply -f updated-network-config.yaml
   

6. Setzen Sie für Clusterversion 4.10.x und früher den Verwaltungszustand des Clusternetzoperators auf Unmanaged.

    oc patch network.operator.openshift.io cluster --type=merge --patch  '{"spec": {"managementState": "Unmanaged"}}'
   

7. Starten Sie den DaemonSetkube-proxy neu, um die Änderungen zu übernehmen. Dieser Vorgang verursacht keine Unterbrechungen.

   oc rollout restart ds -n openshift-kube-proxy openshift-kube-proxy
   

8. Warten Sie, bis alle kube-proxy-Pods erneut gestartet wurden. Überprüfen Sie den Status, indem Sie den folgenden Befehl ausführen.

   oc get po -n openshift-kube-proxy --selector app=kube-proxy
   

9. Setzen Sie für die Clusterversion 4.10.x und früher den Verwaltungsstatus des Clusternetzoperators auf Managed zurück. Beachten Sie, dass diese Aktion möglicherweise die Proxy-Pods erneut startet.

    oc patch network.operator.openshift.io cluster --type=merge --patch  '{"spec": {"managementState": "Managed"}}'
   

Nachdem alle Pods erneut gestartet wurden, wird Ihr Cluster mit den eingeschränkten Teilnetzen konfiguriert. Sie können diese Schritte wiederholen, um die Teilnetzliste nach Bedarf zu aktualisieren oder zu löschen.

Sie können den Datenverkehr weiter einschränken, indem Sie NetworkPolicies auf Servicebasisverwenden.