Beachten Sie vor dem Einrichten von OpenShift und NCP die folgenden Informationen.

  • Ein Pod darf nicht mehr als 11 Bezeichnungen haben, und ein Namespace darf nicht mehr als 12 Bezeichnungen aufweisen.

  • Hinzugefügte Bezeichnungen für die interne Verwendung von OpenShift, z. B. eine Bezeichnung mit Präfix „openshift.io“ im zugehörigen Schlüssel, werden von NCP ignoriert. Demzufolge werden dem Benutzer die entsprechenden Tags, die auf den entsprechenden NSX-Ressourcen erstellt wurden, nicht angezeigt. Hier finden Sie eine Liste mit von OpenShift verwendeten Bezeichnungspräfixen. Vermeiden Sie die Verwendung eines Bezeichnungsschlüssels, der wie folgt beginnt:

        openshift.io
        pod-template
  • Die Knoten benötigen Zugriff auf die Pods, beispielsweise für Kubelet-Integritätsprüfungen. Stellen Sie sicher, dass die Host-Verwaltungsschnittstelle auf das Pod-Netzwerk zugreifen kann.

  • Die Linux-Funktionen NET_ADMIN und NET_RAW können von Angreifern ausgenutzt werden, um das Pod-Netzwerk zu gefährden. Sie sollten diese beiden Funktionen der nicht vertrauenswürdigen Container deaktivieren. Standardmäßig erhält NET_ADMIN bei SCC mit „restricted“ und „anyuid“ keinen Zugriff. Seien Sie vorsichtig bei einem SCC-Objekt, das NET_ADMIN explizit aktiviert oder die Pod-Ausführung im privilegierten Modus ermöglicht. Erstellen Sie darüber hinaus für nicht vertrauenswürdige Container ein separates SCC-Objekt, z. B. basierend auf SCC mit „anyuid“, und entfernen Sie dabei die Funktion NET_RAW. Dies kann durch Hinzufügen von NET_RAW zu der Liste „RequiredDropCapabilities“ in der SCC-Definition erfolgen.

  • Erlauben Sie den Root-Zugriff in PODs/Containern (nur zu Testzwecken). Die unten aufgeführten Befehle benötigen Root-Zugriff in allen PODs des oc-Projekts, bei dem Sie aktuell angemeldet sind.

        oc new-project test-project
        oc project test-project
        oc adm policy add-scc-to-user anyuid -z default
  • Konfigurieren Sie die OpenShift-Registrierung (fügen Sie sie hinzu).

        oc login -u system:admin -n default
        oc adm registry --service-account=registry --config=/etc/origin/master/admin.kubeconfig
  • Löschen der OpenShift-Registrierung

        oc login -u system:admin -n default
        oc delete svc/docker-registry dc/docker-registry
  • Es fehlt eine IPtables-Firewallregel zum Zulassen von DNS-Anforderungen von Docker-Standard-Bridge-Containern für den dnsmasq-Prozess auf dem Knoten. Sie muss manuell geöffnet werden. Bearbeiten Sie /etc/sysconfig/iptables, und fügen Sie am Ende der Datei vor COMMIT die folgenden Regeln hinzu:

        -A OS_FIREWALL_ALLOW -p tcp -m state --state NEW -m tcp --dport 53 -j ACCEPT
        -A OS_FIREWALL_ALLOW -p udp -m state --state NEW -m udp --dport 53 -j ACCEPT
        COMMIT
  • Starten Sie iptables, docker und origin-node neu (Kube-Proxy und Kubelet werden neu gestartet).

        systemctl restart iptables
        systemctl restart docker
        systemctl restart origin-node
  • Die interne Docker-Registrierung von OpenShift muss Nicht-TLS verwenden können, damit OpenShift funktioniert. In der Regel sollte dies automatisch vom OpenShift Ansible-Installationsprogramm hinzugefügt werden. Momentan scheint dies aber nicht zu funktionieren. Bearbeiten Sie „/etc/sysconfig/docker“ und fügen Sie Folgendes hinzu:

        INSECURE_REGISTRY='--insecure-registry 172.30.0.0/16'
  • Starten Sie Docker neu.

    systemctl restart docker
  • Die NCP-Unterstützung für Netzwerkrichtlinien entspricht der von Kubernetes bereitgestellten Unterstützung und richtet sich nach der von OpenShift verwendeten Kubernetes-Version.

    • OpenShift 3.9 – Die Regelklauseln in der Netzwerkrichtlinie können höchstens einen der Selektoren namespaceSelector, podSelector und ipBlock enthalten.

  • Der Kubernetes-API-Server unterzieht eine Netzwerkrichtlinienspezifikation keiner Validierung. Es ist daher möglich, eine Netzwerkrichtlinie zu erstellen, die ungültig ist. NCP lehnt ungültige Netzwerkrichtlinien ab. Falls Sie die Netzwerkrichtlinie aktualisieren, damit sie gültig ist, wird sie von NCP trotzdem nicht verarbeitet. Sie müssen die Netzwerkrichtlinie löschen und mit einer gültigen Spezifikation neu erstellen.

  • Bestimmte Kubernetes-Versionen weisen ein auf subPath bezogenes Problem auf (siehe https://github.com/kubernetes/kubernetes/issues/61076). Wenn die OpenShift-Version keinen Fix für dieses Problem enthält, schlägt die Erstellung des NCP-Pods mit folgendem Fehler fehl: CreateContainerConfigError: subPath für volumeMount konnte nicht vorbereitet werden. Sie können dieses Problem umgehen, indem Sie die Verwendung von subPath aus der NCP-YAML-Datei entfernen. Entfernen Sie insbesondere die Zeile mit subPath: ncp.ini und ersetzen Sie die Konfiguration für volumes durch Folgendes:

        volumes:
          - name: config-volume
            # ConfigMap nsx-ncp-config is expected to supply ncp.ini
            configMap:
              name: nsx-ncp-config
              items:
                - key: ncp.ini
                  path: ncp.ini

    Ein Nebeneffekt dieser Änderung besteht darin, dass das gesamte /etc/nsx-ujo-Verzeichnis mit einem Schreibschutz versehen wird. Dies führt dazu, dass eine Verbindung mit NSX-T über ein Zertifikat und einen privaten Schlüssel nicht funktioniert, da NCP kein temporäres Verzeichnis unter /etc/nsx-ujo erstellen kann, um Zertifikat und privaten Schlüssel in eine einzige Datei zu verschieben.

  • Beachten Sie Folgendes, wenn Sie einen OpenShift 3.10-Cluster ausführen oder ein Upgrade darauf durchführen:

    • Sie müssen die Konfiguration der Knotengruppen angeben, die für den OpenShift 3.10-Cluster spezifisch sind. Die Konfiguration des ConfigMap-Objekts des Knotens muss in der Bestandslisten-Hostdatei angegeben werden.

    • Allen Hosts, die in der [nodes]-Gruppe in der Bestandslisten-Hostdatei definiert sind, muss ein Knotengruppenname zugewiesen werden.

    • Wenn Sie über ein Ansible-Playbook ein Upgrade des OpenShift-Clusters durchführen, kommt es möglicherweise zu einem Netzwerkausfall. Fügen Sie den Patch (https://github.com/openshift/openshift-ansible/pull/8016/files#diff-2386e21861da3f95091dbb27d72ca366) im „openshift-ansible“-Repository hinzu, um die Beendigung/Deinstallation von Open vSwitch-Paketen zu unterbinden.

  • Seit OpenShift 3.10 wurde Kube-Proxy vom „openshift-node“-Dienst zu einem DaemonSet verschoben. Es wird nicht mehr standardmäßig gestartet. Führen Sie die folgenden Schritte durch, um Kube-Proxy manuell zu starten (davon ausgehend, dass das „openshift-ansible“-Repository geklont wurde):

    • Wechseln Sie in das Verzeichnis openshift-ansible und legen Sie unter [defaults] Folgendes fest:

          library = roles/lib_utils/library/
    • Erstellen Sie eine „create_proxy.yaml“-Datei im Playbooks-Verzeichnis mit den folgenden Einträgen:

          - import_playbook: byo/openshift_facts.yml
          - hosts: masters
            run_once: True
            roles:
              - kube_proxy_and_dns
    • Führen Sie das Playbook aus:

          ansible-playbook -i hosts playbooks/create_proxy.yaml

      Sie sehen Fehlermeldungen, die auf das Fehlschlagen einiger Vorgänge hinweisen. Diese Meldungen können ignoriert werden. Sie können das Ergebnis überprüfen, indem Sie den Befehl oc get po --all-namespaces ausführen.