Componenti master Red Hat OpenShift

Controllare i seguenti componenti nel master IBM gestito del proprio Red Hat OpenShift on IBM Cloud cluster.

Non è possibile modificare questi componenti. IBM gestisce i componenti e li aggiorna automaticamente durante gli aggiornamenti patch del master.

In OpenShift Container Platform 4, molti componenti sono configurati da un operatore corrispondente per facilitare la gestione. La seguente tabella illustra insieme questi operatori e componenti, per concentrarsi sulle funzionalità principali che il componente fornisce al cluster.

Tenancy singola

Il master e tutti i componenti master sono dedicati solo a te e non sono condivisi con altri clienti IBM.

Repliche

I componenti master, tra cui il server API Red Hat OpenShift e l'archivio dati etcd, dispongono di tre repliche e, se si trovano in un'area metropolitana multizona, sono distribuiti tra le diverse zone per garantire una disponibilità ancora maggiore.

cloud-controller-manager

Il gestore controller cloud gestisce i componenti specifici del provider cloud, come ad esempio il programma di bilanciamento del carico IBM Cloud.

cluster-health

Il componente di integrità del cluster monitora l'integrità del cluster e si integra con il monitoraggio e le metriche IBM Cloud per il servizio.

cluster-policy-controller

Il cluster-policy-controller gestisce le risorse di policy necessarie per creare i pod all'interno del cluster.

cluster-version-operator

L'operatore della versione cluster (CVO, cluster version operator) installa e aggiorna altri operatori eseguiti nel cluster. Per ulteriori informazioni, consultare il progetto “ GitHub ”.

control-plane-operator

L'operatore del piano di controllo gestisce l'installazione e l'aggiornamento dei componenti del piano di controllo nel master.

etcd, etcd-molecule, etcd-operator

etcd è un archivio di valori chiave altamente disponibile che archivia lo stato di tutte le risorse Kubernetes di un cluster, quali servizi, distribuzioni e pod. Il backup dei dati in etcd viene eseguito ogni 8 ore su un'istanza di archiviazione crittografata gestita da IBM.

kube-controller-manager, openshift-controller-manager

Il controller “ Kubernetes ” monitora lo stato degli oggetti all’interno del cluster, come ad esempio il set di repliche di un carico di lavoro. Quando lo stato di un oggetto cambia, ad esempio se si verifica un'interruzione di un pod in una serie di repliche, il gestore controller avvia le azioni correttive per raggiungere lo stato richiesto. Il controller “ Red Hat OpenShift ” svolge la stessa funzione per gli oggetti specifici dell’API “ Red Hat OpenShift ”, come ad esempio i progetti.

kube-scheduler

Lo scheduler di Kubernetes monitora i pod appena creati e decide dove distribuirli in base alla capacità, alle esigenze di prestazioni, ai vincoli delle policy, alle specifiche di anti-affinità e ai requisiti del carico di lavoro. Se non è possibile trovare alcun nodo di lavoro che corrisponda ai requisiti, il pod non viene distribuito nel cluster.

manifests-bootstrapper

Il processo " manifests-boot-strapper " configura il master con i certificati necessari per l'inserimento nel cluster come nodo master.

oauth-openshift

Il server OAuth integrato viene configurato automaticamente per l'integrazione con IBM Cloud IAM (Identity and Access Management). Non è possibile aggiungere altri provider di identità supportati al cluster. Per ulteriori informazioni su come effettuare l'autenticazione al cluster tramite IAM, consulta la sezione " Accesso ai cluster di Red Hat OpenShift ".

openshift-apiserver, openshift-apiserver-operator, kube-apiserver

Il server API è il punto di ingresso principale per tutte le richieste di gestione del cluster dal nodo di lavoro al master. Il server API verifica e elabora le richieste che modificano lo stato degli oggetti " Kubernetes ", quali pod o servizi, e degli oggetti " Red Hat OpenShift ", quali progetti o utenti. Quindi, il server API memorizza questo stato nell'archivio dati etcd.

konnectivity-server, konnectivity-operator

Il server Konnectivity collabora con l'agente Konnectivity per collegare in modo sicuro il nodo master al nodo worker. Questa connessione supporta le chiamate apiserver proxy ai tuoi pod e servizi, le chiamate oc exec, attach e logs a kubelet e i webhook di variazione e convalida.

Controller di ammissione

I controller di ammissione sono implementati per funzionalità specifiche nei cluster di " Red Hat OpenShift on IBM Cloud ". Con i controller di ammissione, puoi configurare le politiche nel tuo cluster che determinano se una specifica azione nel cluster è consentita o meno. Nella politica è possibile specificare le condizioni in cui un utente non può eseguire un'azione, anche se tale azione rientra nelle autorizzazioni generali assegnate all'utente tramite RBAC. Pertanto, i controllori di ammissione possono fornire un ulteriore livello di sicurezza per il cluster prima che una richiesta API venga elaborata dal server API Red Hat OpenShift. Quando si crea un cluster Red Hat OpenShift, i seguenti controller di ammissione Kubernetes vengono installati automaticamente nell'ordine indicato nel master Red Hat OpenShift; tale ordine non può essere modificato dall'utente:

• NamespaceLifecycle
• LimitRanger
• ServiceAccount
• DefaultStorageClass
• ResourceQuota
• StorageObjectInUseProtection
• PersistentVolumeClaimResize
• Priority
• BuildByStrategy
• OriginPodNodeEnvironment
• PodNodeSelector
• ExternalIPRanger
• NodeRestriction
• SecurityContextConstraint
• SCCExecRestrictions
• PersistentVolumeLabel
• OwnerReferencesPermissionEnforcement
• PodTolerationRestriction
• openshift.io/JenkinsBootstrapper
• openshift.io/BuildConfigSecretInjector
• openshift.io/ImageLimitRange
• openshift.io/RestrictedEndpointsAdmission
• openshift.io/ImagePolicy
• openshift.io/IngressAdmission
• openshift.io/ClusterResourceQuota
• MutatingAdmissionWebhook
• ValidatingAdmissionWebhook

È possibile installare i propri controller di ammissione nel cluster oppure scegliere tra i controller di ammissione opzionali forniti da Red Hat OpenShift on IBM Cloud. Applicazione della sicurezza dell'immagine contenitore: installare Portieris per bloccare le distribuzioni del contenitore da immagini non firmate.

Se hai installato manualmente i controller di ammissione e non desideri più utilizzarli, assicurati di rimuoverli completamente. Se i controllori di accesso non vengono rimossi completamente, potrebbero bloccare tutte le operazioni che si desidera eseguire sul cluster.

Red Hat OpenShift componenti del nodo di lavoro

Controllare i seguenti componenti nei nodi worker gestiti dal cliente del proprio Red Hat OpenShift on IBM Cloud cluster.

Questi componenti vengono eseguiti sui tuoi nodi di lavoro perché puoi utilizzarli con i carichi di lavoro che distribuisci nel tuo cluster. Ad esempio, le tue app potrebbero utilizzare un operatore dell' OperatorHub e che esegue un container a partire da un'immagine presente nel registro interno. Sei responsabile dell'utilizzo di questi componenti, ma IBM ne fornisce degli aggiornamenti negli aggiornamenti patch del nodo di lavoro che scegli di applicare.

In OpenShift Container Platform, molti componenti vengono configurati da un operatore dedicato per facilitare la gestione. La seguente tabella illustra insieme questi operatori e componenti, per concentrarsi sulle funzionalità principali che il componente fornisce al cluster.

Tenancy singola

I nodi di lavoro e tutti i componenti di nodo di lavoro sono dedicati solo a te e non sono condivisi con altri clienti IBM. Tuttavia, se si utilizzano macchine virtuali dei nodi di lavoro, l'hardware sottostante potrebbe essere condiviso con altri clienti di IBM, a seconda del livello di isolamento hardware scelto.

Sistema operativo

Per un elenco dei sistemi operativi supportati per versione cluster, consultare Informazioni sulla versione.

Runtime contenitore CRI-O

I tuoi nodi di lavoro vengono installati con CRI-O come interfaccia di runtime del contenitore. Per ulteriori informazioni, vedi Runtime contenitore.

Progetti

Red Hat OpenShift organizza le risorse in progetti, che sono spazi dei nomi Kubernetes con annotazioni, e include molti più componenti rispetto ai cluster Kubernetes della comunità per l'esecuzione di funzionalità Red Hat OpenShift quali il catalogo. I componenti selezionati dei progetti sono descritti nelle seguenti righe. Per ulteriori informazioni, vedere Lavorare su un progetto.

calico-system, tigera-operator

Calico gestisce le politiche di rete per il tuo cluster e include alcuni componenti per gestire la connettività di rete dei contenitori, l'assegnazione di indirizzi IP e il controllo del traffico di rete. L'operatore Tigera installa e gestisce il ciclo di vita dei componenti Calico.

default

Questo progetto viene utilizzato se non si specifica un progetto o non se ne crea uno per le risorse di Kubernetes.

ibm-system

Questo progetto include la distribuzione ibm-cloud-provider-ip che funziona con keepalived per fornire il controllo dell'integrità e il bilanciamento del carico di livello 4 per le richieste ai pod dell'applicazione.

kube-system

Questo progetto include molti componenti che vengono utilizzati per eseguire Kubernetes sul nodo di lavoro.

• ibm-master-proxy: L' ibm-master-proxy è un daemon set che inoltra le richieste provenienti dal nodo worker agli indirizzi IP delle repliche master ad alta disponibilità. Nei cluster a zona singola, il master ha tre repliche su host separati. Per i cluster che si trovano in una zona che supporta il multizona, il master ha tre repliche che vengono distribuite tra le zone. Un programma di bilanciamento del carico altamente disponibile inoltra le richieste effettuate al nome di dominio del master alle repliche del master.
• kubelet: Il kubelet è un agente dei nodi di lavoro che viene eseguito su ogni nodo di lavoro ed è responsabile del monitoraggio dello stato dei pod in esecuzione sul nodo di lavoro e del controllo degli eventi inviati dal server API. In base agli eventi, il kubelet crea o rimuove i pod, garantisce i probe di attività e disponibilità e segnala in risposta lo stato dei pod al server API.
• vpn: L'agente Konnectivity collabora con il server Konnectivity per connettere in modo sicuro il nodo master al nodo worker. Questa connessione supporta le chiamate apiserver proxy ai tuoi pod e servizi e le chiamate oc exec, attach e logs a kubelet.
• Altri componenti: Il progetto “ kube-system ” include anche componenti per la gestione delle risorse fornite d IBM, quali plug-in di archiviazione per l’archiviazione di file e a blocchi, il bilanciatore di carico in ingresso (ALB) e keepalived.

openshift-cloud-credential-operator

L'operatore delle credenziali cloud gestisce un controller per i componenti dell' Red Hat OpenShift e che richiedono le credenziali del provider cloud. Il controller assicura che vengano utilizzate solo le credenziali richieste per l'operazione e non le autorizzazioni elevate come admin. Per ulteriori informazioni, consultare il progetto “ GitHub ”.

openshift-cluster-node-tuning-operator

IBM gestisce l'operatore di ottimizzazione dei nodi, che esegue un daemon set su ciascun nodo di lavoro del cluster per ottimizzare tali nodi.

openshift-cluster-samples-operator

L'operatore "samples" gestisce determinati flussi di immagini e modelli forniti di default con il cluster " Red Hat OpenShift ". È possibile distribuire questi modelli dal sito Sviluppatore prospettiva nella console web di Red Hat OpenShift.

openshift-cluster-storage-operator

L'operatore di archiviazione del cluster garantisce che sia impostata una classe di archiviazione predefinita.

openshift-console, openshift-console-operator

La console web di Red Hat OpenShift è un'interfaccia basata sul web che è possibile utilizzare per gestire le risorse Red Hat OpenShift e Kubernetes in esecuzione nel proprio cluster. Puoi anche utilizzare la console per visualizzare un token oc login per eseguire l'autenticazione nel tuo cluster da una CLI. Per ulteriori informazioni, vedi Navigazione nella console Red Hat OpenShift.

openshift-dns, openshift-dns-operator

Il progetto DNS include i componenti per convalidare il traffico di rete in entrata rispetto alle regole iptables configurate sul nodo di lavoro e le richieste di proxy che possono entrare o uscire dal cluster.

openshift-image-registry

Red Hat OpenShift mette a disposizione un' registro delle immagini dei container e interna che è possibile utilizzare per gestire e visualizzare le immagini localmente tramite la console. In alternativa, puoi configurare l'IBM Cloud Container Registry privato oppure importare immagini da IBM Cloud Container Registry al registro interno. Il registro interno include un volume di tipo “ File Storage for Classic ” nell’account dell’infrastruttura IBM Cloud, destinato all’archiviazione delle immagini del registro. Il provisioning del volume di archiviazione file viene eseguito tramite l'attestazione del volume persistente (PVC, persistent volume claim) image-registry-storage.

openshift-ingress, openshift-ingress-operator

Red Hat OpenShift utilizza i percorsi per rendere direttamente accessibile il servizio di un'applicazione su un nome host, in modo che i client esterni possano raggiungerlo. Per creare percorsi, il cluster utilizza l'operatore Ingress. Puoi anche utilizzare Ingress per esporre le applicazioni esternamente e personalizzare l'instradamento. Ingress è composto da tre componenti: l'operatore Ingress, il controllore Ingress e le risorse di instradamento. Il controller di Ingress associa il servizio al nome host. Per impostazione predefinita, il controller Ingress include due repliche. Assicurati che il tuo cluster disponga di almeno due nodi di lavoro, in modo che il controller Ingress possa essere eseguito su host di elaborazione distinti per garantire una maggiore disponibilità.

openshift-marketplace

Il marketplace include il OperatorHub che viene fornito di default con il cluster Red Hat OpenShift. OperatorHub include operatori di Red Hat e provider di terze parti. Tieni presente che questi operatori sono forniti dalla community, potrebbero non integrarsi con il tuo cluster e non sono supportati da IBM. È possibile abilitare gli operatori dalla sezione " OperatorHub " nella console web di Red Hat OpenShift.

openshift-monitoring

OpenShift Container Platform include uno stack di monitoraggio integrato per il tuo cluster, che comprende metriche e funzionalità di gestione degli avvisi. Per un confronto dello stack di monitoraggio integrato e altre opzioni come IBM Cloud Monitoring, vedi Descrizione delle opzioni per la registrazione e il monitoraggio.

openshift-multus

OpenShift Container Platform utilizza il plug-in Multus per l'interfaccia di rete dei container (CNI) per consentire l'uso di più reti di pod. Tuttavia, non puoi configurare il cluster per utilizzare più reti pod. I cluster Red Hat OpenShift on IBM Cloud supportano solo Calico, che è configurato per il cluster per impostazione predefinita. Se abilitato, Service Mesh utilizza il plug-in Multus.

openshift-network-operator

L'operatore della rete del cluster(CNO) gestisce i componenti della rete del cluster configurati per impostazione predefinita, come il plug-in del provider di rete per i pod CNI e l'operatore DNS.

openshift-operator-lifecycle-manager

Il gestore del ciclo di vita degli operatori(OLM) gestisce il ciclo di vita di tutti gli operatori e del catalogo in esecuzione nel cluster, compresi gli operatori relativi ai componenti predefiniti e qualsiasi operatore personalizzato aggiunto dall'utente.

openshift-service-ca, openshift-service-ca-operator

L'operatore dell'autorità di certificazione (CA, certificate authority) esegue la firma del certificato e immette i certificati nelle risorse del server API e nelle mappe di configurazione nel cluster. Per ulteriori informazioni, consultare il progetto “ GitHub ”.

Cluster con endpoint di servizi cloud pubblici e privati

Il diagramma seguente illustra i componenti del cluster e il modo in cui interagiscono quando sia l'Gli endpoint dei servizi cloud pubblici e privati sono abilitati. Poiché sono abilitati entrambi gli endpoint del servizio, il tuo VPC crea un programma di bilanciamento del carico pubblico per ogni servizio per il traffico in entrata.

Cluster con solo endpoint del servizio cloud privato

Il diagramma seguente illustra i componenti del cluster e il modo in cui interagiscono quando è attivo solo l'L'endpoint del servizio cloud privato è abilitato. Poiché è abilitato solo l'endpoint del servizio cloud privato, la VPC crea un bilanciatore di carico privato per ciascun servizio per il traffico in entrata.

Componenti nodo di lavoro e master VPC

Master e nodi di lavoro includono gli stessi componenti descritti nell'architettura dei cluster Classic. Per ulteriori informazioni OpenShift Container Platform sull'architettura, consultare la Red Hat OpenShift documentazione.

Master

I componenti master, tra cui il server API ed etcd, hanno tre repliche e vengono estesi tra le zone per una disponibilità ancora maggiore. I master includono gli stessi componenti descritti nell'architettura dei cluster "Classic". Il master e tutti i componenti master sono dedicati solo a te e non vengono condivisi con altri clienti IBM.

Nodo di lavoro

Con Red Hat OpenShift on IBM Cloud, le macchine virtuali gestite dal tuo cluster sono istanze denominate nodi di lavoro. Queste macchine virtuali dei nodi di lavoro e tutti i componenti del nodo di lavoro sono dedicati solo a te e non vengono condivisi con altri clienti IBM. Tuttavia, l'hardware sottostante viene condiviso con altri clienti IBM. La gestione dei nodi di lavoro avviene tramite gli strumenti di automazione forniti da Red Hat OpenShift on IBM Cloud, quali l'API, la CLI o la console. A differenza dei cluster classici, i nodi di elaborazione VPC non sono visibili nel portale dell'infrastruttura né in una fattura separata relativa all'infrastruttura, ma tutte le attività di manutenzione e fatturazione relative ai nodi di elaborazione vengono gestite tramite Red Hat OpenShift on IBM Cloud.

I nodi di lavoro includono gli stessi componenti descritti nell'architettura del cluster Classic.

Quando esegui oc get nodes, potresti notare che i ROLES dei tuoi nodi di lavoro sono contrassegnati come master,worker. Questi nodi sono nodi di lavoro in IBM Cloud e non includono i componenti master gestiti da IBM. Questi nodi, invece, sono contrassegnati come master perché eseguono i componenti di OpenShift Container Platform che sono necessari per configurare e gestire le risorse predefinite all'interno del cluster, come OperatorHub e il registro interno.

Rete cluster

I tuoi nodi di lavoro vengono creati in una sottorete VPC nella zona da te specificata. Le comunicazioni tra il master e i nodi di lavoro avvengono sulla rete privata. Se si crea un cluster con gli endpoint dei servizi cloud pubblici e privati abilitati, gli utenti esterni autenticati possono comunicare con il master tramite la rete pubblica, ad esempio per eseguire comandi oc. Se si crea un cluster con abilitati solo gli endpoint del servizio cloud privato, gli utenti esterni autenticati potranno comunicare con il master esclusivamente tramite la rete privata. Puoi configurare il tuo cluster per comunicare con le risorse nelle reti in loco, in altri VPC o nell'infrastruttura classica configurando una VPN VPC, IBM Cloud Direct Link o IBM Cloud Transit Gateway sulla rete privata.

Rete di applicazioni

I bilanciatori di carico del Virtual Private Cloud vengono creati automaticamente nella VPC, al di fuori del cluster, per tutti i servizi di rete creati all'interno del cluster. Ad esempio, un programma di bilanciamento del carico VPC espone i servizi router nel tuo cluster per impostazione predefinita. In alternativa, puoi creare un servizio LoadBalancer di Kubernetes per le tue applicazioni e verrà generato automaticamente un programma di bilanciamento del carico VPC. I bilanciatori di carico VPC sono multizona e instradano le richieste destinate alla tua app attraverso le porte private dei nodi che vengono aperte automaticamente sui tuoi nodi di lavoro. Se gli endpoint dei servizi cloud pubblici e privati sono abilitati, i router e i bilanciatori di carico VPC vengono creati come pubblici per impostazione predefinita. Se è abilitato solo l'endpoint del servizio cloud privato, i router e i bilanciatori di carico VPC vengono creati come privati per impostazione predefinita. Per ulteriori informazioni, vedi Rete di applicazioni pubblica o privata per i cluster VPC. Calico viene utilizzato come fabric delle politiche di rete del cluster.

Archiviazione

Puoi configurare solo IBM Cloud Object Storage e Cloud Databases.