Concetti di base di Kubernetes per il servizio Kubernetes di Azure in Azure Stack HCIKubernetes core concepts for Azure Kubernetes Service on Azure Stack HCI

Si applica a: AKS in Azure Stack HCI, Runtime AKS in Windows Server 2019 DatacenterApplies to: AKS on Azure Stack HCI, AKS runtime on Windows Server 2019 Datacenter

Il servizio Azure Kubernetes in Azure Stack HCI è una piattaforma di contenitori Kubernetes di livello aziendale con tecnologia di Azure Stack HCI.Azure Kubernetes Service on Azure Stack HCI is an enterprise-grade Kubernetes container platform powered by Azure Stack HCI. Include Microsoft supported Core Kubernetes, componenti aggiuntivi, un host contenitore di Windows progettato per lo sviluppo e un host contenitore Linux supportato da Microsoft, con l'obiettivo di ottenere una semplice esperienza di gestione della distribuzione e del ciclo di vita.It includes Microsoft supported core Kubernetes, add-ons, a purpose-built Windows container host and a Microsoft-supported Linux container host with a goal to have a simple deployment and life cycle management experience.

Questo articolo presenta i componenti principali dell'infrastruttura Kubernetes, ad esempio il piano di controllo, i nodi e i pool di nodi.This article introduces the core Kubernetes infrastructure components such as the control plane, nodes, and node pools. Sono presentate anche risorse del carico di lavoro come pod, distribuzioni e set, nonché la procedura per raggruppare risorse in spazi dei nomi.Workload resources such as pods, deployments, and sets are also introduced, along with how to group resources into namespaces.

Architettura del cluster KubernetesKubernetes cluster architecture

Kubernetes è il componente principale del servizio Azure Kubernetes in Azure Stack HCI.Kubernetes is the core component of the Azure Kubernetes Service on Azure Stack HCI. Il servizio Azure Kubernetes in Azure Stack HCI usa un set di configurazioni predefinite per distribuire i cluster Kubernetes in modo efficace e con la scalabilità.Azure Kubernetes Service on Azure Stack HCI uses a set of predefined configurations to deploy Kubernetes cluster(s) effectively and with scalability in mind.

L'operazione di distribuzione creerà più macchine virtuali Linux o Windows e le unirà per creare i cluster Kubernetes.The deployment operation will create multiple Linux or Windows virtual machines and join these together to create Kubernetes cluster(s).

Il sistema distribuito è pronto per ricevere carichi di lavoro Kubernetes standard, ridimensionare questi carichi di lavoro o persino ridimensionare il numero di macchine virtuali, nonché il numero di cluster in base alle esigenze.The deployed system is ready to receive standard Kubernetes workloads, scale these workloads, or even scale the number of virtual machines as well as the number of clusters up and down as needed.

Un cluster di servizi Kubernetes di Azure è suddiviso in due componenti principali in Azure Stack HCI:An Azure Kubernetes Service cluster is divided into two main components on Azure Stack HCI:

  • Il cluster di gestione fornisce il meccanismo di orchestrazione e l'interfaccia di base per la distribuzione e la gestione di uno o più cluster di destinazione.Management cluster provides the the core orchestration mechanism and interface for deploying and managing one or more target clusters.
  • I cluster di destinazione (noti anche come cluster del carico di lavoro) sono i punti in cui i carichi di lavoro dell'applicazione vengono eseguiti e vengono gestiti da un cluster di gestione.Target clusters (also known as workload clusters) are where application workloads run and are managed by a management cluster.

Viene illustrata l'architettura tecnica del servizio Kubernetes di Azure in Azure Stack HCI

Cluster di gestioneManagement cluster

Quando si crea un cluster del servizio Kubernetes di Azure in Azure Stack HCI, viene creato e configurato automaticamente un cluster di gestione.When you create an Azure Kubernetes Service cluster on Azure Stack HCI, a management cluster is automatically created and configured. Questo cluster di gestione è responsabile del provisioning e della gestione dei cluster di destinazione in cui vengono eseguiti i carichi di lavoro.This management cluster is responsible for provisioning and managing target clusters where workloads run. Un cluster di gestione include i componenti Kubernetes principali seguenti:A management cluster includes the following core Kubernetes components:

  • Server API : il server API è il modo in cui vengono esposte le API Kubernetes sottostanti.API Server - The API server is how the underlying Kubernetes APIs are exposed. Questo componente fornisce l'interazione per gli strumenti di gestione, ad esempio l'interfaccia di amministrazione di Windows, i moduli di PowerShell o kubectl .This component provides the interaction for management tools such as Windows Admin Center, PowerShell modules, or kubectl.
  • Load Balancer : il servizio di bilanciamento del carico è una singola VM Linux dedicata con una regola di bilanciamento del carico per il server API del cluster di gestione.Load Balancer - The load balancer is a single dedicated Linux VM with a load balancing rule for the API server of the management cluster.

Windows Admin CenterWindows Admin Center

Centro di amministrazione di Windows offre un'interfaccia utente intuitiva per l'operatore Kubernetes per gestire il ciclo di vita dei cluster di servizi Kubernetes di Azure in Azure Stack HCI.Windows Admin Center offers an intuitive UI for the Kubernetes operator to manage the lifecycle of Azure Kubernetes Service clusters on Azure Stack HCI.

Modulo PowerShellPowerShell module

Il modulo PowerShell è un modo semplice per scaricare, configurare e distribuire il servizio Azure Kubernetes in Azure Stack HCI.The PowerShell module is an easy way to download, configure and deploy Azure Kubernetes Service on Azure Stack HCI. Il modulo PowerShell supporta anche la distribuzione e la configurazione di cluster di destinazione aggiuntivi, nonché la riconfigurazione di quelli esistenti.The PowerShell module also supports deploying and configuring additional target clusters as well as reconfiguring existing ones.

Cluster di destinazioneTarget cluster

Il cluster di destinazione (carico di lavoro) è una distribuzione a disponibilità elevata di Kubernetes con macchine virtuali Linux per l'esecuzione di componenti del piano di controllo Kubernetes e di nodi di lavoro Linux.The target (workload) cluster is a highly available deployment of Kubernetes using Linux VMs for running Kubernetes control plane components as well as Linux worker nodes. Le macchine virtuali basate su Windows Server Core vengono usate per stabilire i nodi del ruolo di lavoro Windows.Windows Server Core based VMs are used for establishing Windows worker nodes. Uno o più cluster di destinazione possono essere gestiti da un cluster di gestione.There can be one or more target cluster(s) managed by one management cluster.

Nodi di lavoroWorker nodes

Per eseguire le applicazioni e i servizi di supporto, è necessario un nodo Kubernetes.To run your applications and supporting services, you need a Kubernetes node. Un cluster di destinazione del servizio Kubernetes di Azure in Azure Stack HCI dispone di uno o più nodi del ruolo di lavoro, ovvero una macchina virtuale (VM) che esegue i componenti del nodo Kubernetes, oltre a ospitare i pod e i servizi che costituiscono il carico di lavoro dell'applicazione.An Azure Kubernetes Service target cluster on Azure Stack HCI has one or more worker nodes, which is a virtual machine (VM) that runs the Kubernetes node components, as well as hosting the pods and services that make up the application workload.

Bilanciamento del caricoLoad balancer

Il servizio di bilanciamento del carico è una macchina virtuale che esegue Linux e HAProxy + KeepAlive per fornire servizi con bilanciamento del carico per i cluster di destinazione distribuiti dal cluster di gestione.The load balancer is a virtual machine running Linux and HAProxy + KeepAlive to provide load balanced services for the target clusters deployed by the management cluster.

Per ogni cluster di destinazione, il servizio Azure Kubernetes in Azure Stack HCI aggiungerà almeno una macchina virtuale di bilanciamento del carico (VM LB).For each target cluster, Azure Kubernetes Service on Azure Stack HCI will add at least one load balancer virtual machines (LB VM). Inoltre, è possibile creare un altro servizio di bilanciamento del carico per la disponibilità elevata del server API nel cluster di destinazione.In addition to this, another load balancer can be created for high availability of the API server on the target cluster. Qualsiasi servizio Kubernetes di tipo LoadBalancer creato nel cluster di destinazione creerà una regola di bilanciamento del carico nella macchina virtuale lb.Any Kubernetes service of type LoadBalancer that is created on the target cluster will end up creating a load balancing rule in the LB VM.

Componenti Add-OnAdd-On components

Sono disponibili diversi componenti aggiuntivi facoltativi che possono essere distribuiti in un determinato cluster, in particolare: Azure Arc, Prometeo, Grafana o il dashboard di Kubernetes.There are several optional add-on components that can be deployed in any given cluster, most notably: Azure Arc, Prometheus, Grafana, or the Kubernetes Dashboard.

Componenti di KubernetesKubernetes components

Questa sezione presenta i componenti principali del carico di lavoro di Kubernetes che possono essere distribuiti nel servizio Azure Kubernetes in Azure Stack cluster di destinazione HCI come Pod, distribuzioni e set, oltre a come raggruppare le risorse in spazi dei nomi.This section introduces the core Kubernetes workload components that can be deployed on Azure Kubernetes Service on Azure Stack HCI target clusters such as pods, deployments, and sets, along with how to group resources into namespaces.

Baccellipods

Kubernetes usa i pod per eseguire un'istanza dell'applicazione.Kubernetes uses pods to run an instance of your application. Un pod rappresenta una singola istanza dell'applicazione.A pod represents a single instance of your application. i pod hanno in genere un mapping 1:1 con un contenitore, sebbene esistano scenari avanzati in cui un pod può contenere più contenitori.pods typically have a 1:1 mapping with a container, although there are advanced scenarios where a pod may contain multiple containers. I pod multi-contenitore sono pianificati insieme nello stesso nodo e consentono ai contenitori di condividere le risorse correlate.These multi-container pods are scheduled together on the same node, and allow containers to share related resources.

Quando si crea un pod, è possibile definire richieste di risorse per richiedere una determinata quantità di risorse di CPU o di memoria.When you create a pod, you can define resource requests to request a certain amount of CPU or memory resources. L'Utilità di pianificazione di Kubernetes tenta di pianificare i pod per l'esecuzione in un nodo con le risorse disponibili per soddisfare la richiesta.The Kubernetes Scheduler tries to schedule the pods to run on a node with available resources to meet the request. È anche possibile specificare limiti massimi per le risorse che impediscono a un pod dato di usare troppe risorse di calcolo del nodo sottostante.You can also specify maximum resource limits that prevent a given pod from consuming too much compute resource from the underlying node. Una procedura consigliata consiste nell'includere limiti per le risorse per tutti i pod, per consentire all'l'Utilità di pianificazione di Kubernetes di capire quali risorse sono necessarie e consentite.A best practice is to include resource limits for all pods to help the Kubernetes Scheduler understand which resources are needed and permitted.

Per altre informazioni, vedere Pod di Kubernetes e Ciclo di vita dei pod di Kubernetes.For more information, see Kubernetes pods and Kubernetes pod lifecycle.

Un pod è una risorsa logica, i carichi di lavoro applicativi sono eseguiti nei contenitori.A pod is a logical resource, but the container(s) are where the application workloads run. i pod sono in genere risorse temporanee e monouso e i pod pianificati singolarmente mancano alcune delle funzionalità di disponibilità elevata e ridondanza fornite da Kubernetes.pods are typically ephemeral, disposable resources, and individually scheduled pods miss some of the high availability and redundancy features Kubernetes provides. I pod vengono invece distribuiti e gestiti dai controller Kubernetes, ad esempio il controller di distribuzione.Instead, pods are deployed and managed by Kubernetes Controllers, such as the Deployment Controller.

Distribuzioni e manifesti YAMLDeployments and YAML manifests

Una distribuzione rappresenta uno o più pod identici gestiti dal controller di distribuzione di Kubernetes.A deployment represents one or more identical pods, managed by the Kubernetes Deployment Controller. Una distribuzione specifica il numero di repliche (pod) da creare e l'Utilità di pianificazione di Kubernetes assicura che, in caso di problemi dei pod o dei nodi, vengano pianificati pod aggiuntivi su nodi integri.A deployment defines the number of replicas (pods) to create, and the Kubernetes Scheduler ensures that if pods or nodes encounter problems, additional pods are scheduled on healthy nodes.

È possibile aggiornare le distribuzioni per modificare la configurazione dei pod, l'immagine del contenitore utilizzata o la risorsa di archiviazione collegata.You can update deployments to change the configuration of pods, container image used, or attached storage. Il controller di distribuzione svuota e termina un determinato numero di repliche, crea repliche dalla nuova definizione della distribuzione e continua il processo fino a quando non vengono aggiornate tutte le repliche della distribuzione.The Deployment Controller drains and terminates a given number of replicas, creates replicas from the new deployment definition, and continues the process until all replicas in the deployment are updated.

La maggior parte delle applicazioni senza stato dovrebbe usare il modello di distribuzione anziché pianificare singoli pod.Most stateless applications should use the deployment model rather than scheduling individual pods. Kubernetes può monitorare l'integrità e lo stato delle distribuzioni per garantire che il numero di repliche richiesto si esegua all'interno del cluster.Kubernetes can monitor the health and status of deployments to ensure that the required number of replicas run within the cluster. Quando si pianificano solo singoli Pod, i Pod non vengono riavviati se si verifica un problema e non vengono ripianificati in nodi integri se il nodo corrente rileva un problema.When you only schedule individual pods, the pods aren't restarted if they encounter a problem, and aren't rescheduled on healthy nodes if their current node encounters a problem.

Se un'applicazione richiede la disponibilità costante di un quorum specifico di istanze per consentire la presa di decisioni di gestione, è preferibile che il processo di aggiornamento non comprometta tale capacità.If an application requires a quorum of instances to always be available for management decisions to be made, you don't want an update process to disrupt that ability. i budget per l' interruzione del Pod possono essere usati per definire il numero di repliche in una distribuzione che possono essere disattivate durante un aggiornamento del nodo o dell'aggiornamento.pod Disruption Budgets can be used to define how many replicas in a deployment can be taken down during an update or node upgrade. Se, ad esempio, si dispone di cinque (5) repliche nella distribuzione, è possibile definire un'alterazione del pod di 4 per consentire l'eliminazione o la ripianificazione di una sola replica alla volta.For example, if you have five (5) replicas in your deployment, you can define a pod disruption of 4 to only permit one replica from being deleted/rescheduled at a time. Come con i limiti delle risorse di pod, una procedura consigliata è definire i budget di interruzione dei pod nelle applicazioni che richiedono la presenza costante di un numero minimo di repliche.As with pod resource limits, a best practice is to define pod disruption budgets on applications that require a minimum number of replicas to always be present.

Le distribuzioni vengono in genere create e gestite con kubectl create o kubectl apply.Deployments are typically created and managed with kubectl create or kubectl apply. Per creare una distribuzione si definisce un file manifesto nel formato YAML (YAML Ain't Markup Language).To create a deployment, you define a manifest file in the YAML (YAML Ain't Markup Language) format. L'esempio seguente crea una distribuzione di base del server Web NGINX.The following example creates a basic deployment of the NGINX web server. La distribuzione specifica tre (3) repliche da creare e richiede che la porta 80 sia aperta nel contenitore.The deployment specifies three (3) replicas to be created, and requires port 80 to be open on the container. Richieste e limiti relativi alle risorse sono definiti anche per la CPU e la memoria.Resource requests and limits are also defined for CPU and memory.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.15.2
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 250m
            memory: 64Mi
          limits:
            cpu: 500m
            memory: 256Mi

È anche possibile creare applicazioni più complesse includendo anche servizi quali i servizi di bilanciamento del carico all'interno del manifesto YAML.More complex applications can also be created by also including services such as load balancers within the YAML manifest.

Per altre informazioni, vedere distribuzioni KubernetesFor more information, see Kubernetes deployments

Distribuzioni con sistema operativo mistoMixed-OS deployments

Se un determinato servizio Kubernetes di Azure in Azure Stack cluster di destinazione HCI è costituito da nodi di lavoro sia Linux che Windows, è necessario pianificare i carichi di lavoro in un sistema operativo in grado di supportare il provisioning del carico di lavoro.If a given Azure Kubernetes Service on Azure Stack HCI target cluster consists of both Linux and Windows worker nodes, workloads need to be scheduled onto an OS that can support provisioning the workload. Kubernetes offre due meccanismi per garantire che i carichi di lavoro si trovino sui nodi con un sistema operativo di destinazione:Kubernetes offers two mechanisms to ensure workloads land on nodes with a target operating system:

  • Il selettore del nodo è un campo semplice nella specifica pod che consente di pianificare i pod solo in nodi integri che corrispondono al sistema operativo.Node Selector is a simple field in the pod spec that constraints pods to only be scheduled onto healthy nodes matching the operating system.
  • I guasti e le tolleranze interagiscono per garantire che i Pod non siano pianificati sui nodi in modo involontario.Taints and tolerations work together to ensure that pods are not scheduled onto nodes unintentionally. Un nodo può essere "macchiato" in modo da non accettare i pod che non tollerano in modo esplicito il proprio macchia attraverso una "tolleranza" nella specifica del Pod.A node can be "tainted" so as to not accept pods that do not explicitly tolerate its taint through a "toleration" in the pod spec.

Per altre informazioni, vedere selettori di nodo , tains e tollerations.For more information, see node selectors and taints and tolerations.

Oggetti StatefulSet e DaemonSetStatefulSets and DaemonSets

Il controller di distribuzione usa l'Utilità di pianificazione di Kubernetes per eseguire un determinato numero di repliche su qualsiasi nodo disponibile con le risorse disponibili.The Deployment Controller uses the Kubernetes Scheduler to run a given number of replicas on any available node with available resources. Questo approccio di usare le distribuzioni può essere sufficiente per le applicazioni senza stato, ma non per le applicazioni che richiedono una convenzione di denominazione o una risorsa di archiviazione permanente.This approach of using deployments may be sufficient for stateless applications, but not for applications that require a persistent naming convention or storage. Per le applicazioni che richiedono una replica per ogni nodo o per nodi selezionati di un cluster, il controller di distribuzione non esamina come le repliche sono distribuite tra i nodi.For applications that require a replica to exist on each node, or selected nodes, within a cluster, the Deployment Controller doesn't look at how replicas are distributed across the nodes.

Esistono due risorse di Kubernetes che consentono di gestire questi tipi di applicazioni:There are two Kubernetes resources that let you manage these types of applications:

  • Gli oggetti StatefulSet mantengono lo stato delle applicazioni oltre il ciclo di vita di un singolo pod, ad esempio la risorsa di archiviazione.StatefulSets - Maintain the state of applications beyond an individual pod lifecycle, such as storage.
  • Gli oggetti DaemonSet assicurano che ci sia un'istanza in esecuzione in ogni nodo in una delle prime fasi del processo di bootstrap di Kubernetes.DaemonSets - Ensure a running instance on each node, early in the Kubernetes bootstrap process.

Oggetti StatefulSetStatefulSets

Molte applicazioni sviluppate attualmente sono senza stato, mentre gli oggetti StatefulSet possono essere usati per le applicazioni con stato, ad esempio le applicazioni che includono componenti di database.Modern application development often aims for stateless applications, but StatefulSets can be used for stateful applications, such as applications that include database components. Un oggetto StatefulSet è simile a una distribuzione per il fatto che vengono creati e gestiti uno o più pod identici.A StatefulSet is similar to a deployment in that one or more identical pods are created and managed. Le repliche in un oggetto StatefulSet seguono un approccio sequenziale normale alla distribuzione, il ridimensionamento, gli aggiornamenti e la chiusura.Replicas in a StatefulSet follow a graceful, sequential approach to deployment, scale, upgrades, and terminations. Con StatefulSet (quando le repliche vengono ripianificate) la convenzione di denominazione, i nomi di rete e l'archiviazione vengono mantenuti.With a StatefulSet (as replicas are rescheduled) the naming convention, network names, and storage persist.

Si definisce l'applicazione nel formato YAML tramite kind: StatefulSet e poi il controller StatefulSet gestisce la distribuzione e la gestione delle repliche necessarie.You define the application in YAML format using kind: StatefulSet, and the StatefulSet Controller then handles the deployment and management of the required replicas. I dati vengono scritti nell'archivio permanente, con l'archiviazione sottostante persistente anche dopo l'eliminazione del StatefulSet.Data is written to persistent storage, with the underlying storage persisting even after the StatefulSet is deleted.

Per altre informazioni, vedere Oggetti StatefulSet di Kubernetes.For more information, see Kubernetes StatefulSets.

Le repliche in un StatefulSet vengono pianificate ed eseguite in qualsiasi nodo disponibile in un servizio Azure Kubernetes in Azure Stack cluster HCI.Replicas in a StatefulSet are scheduled and run across any available node in an Azure Kubernetes Service on Azure Stack HCI cluster. Se è necessario assicurarsi che almeno un pod del set venga eseguito in un nodo, è possibile usare un oggetto DaemonSet.If you need to ensure that at least one pod in your Set runs on a node, you can instead use a DaemonSet.

Oggetti DaemonSetDaemonSets

Per esigenze specifiche di raccolta di log o monitoraggio potrebbe essere necessario eseguire un pod specifico su tutti i nodi o su nodi selezionati.For specific log collection or monitoring needs, you may need to run a given pod on all, or selected, nodes. Un oggetto DaemonSet anche in questo caso viene usato per distribuire uno o più pod identici, ma il controller DaemonSet garantisce che ogni nodo specificato esegua un'istanza del pod.A DaemonSet is again used to deploy one or more identical pods, but the DaemonSet Controller ensures that each node specified runs an instance of the pod.

Il controller DaemonSet può pianificare i pod nei nodi in una delle prime fasi del processo di avvio del cluster, prima che sia avviata l'utilità di pianificazione predefinita di Kubernetes.The DaemonSet Controller can schedule pods on nodes early in the cluster boot process, before the default Kubernetes scheduler has started. Questa capacità garantisce che i pod di un oggetto DaemonSet vengono avviati prima che siano pianificati i pod tradizionali in una distribuzione o in un oggetto StatefulSet.This ability ensures that the pods in a DaemonSet are started before traditional pods in a Deployment or StatefulSet are scheduled.

Come gli oggetti StatefulSet, un oggetto DaemonSet viene definito come parte di una definizione YAML usando kind: DaemonSet.Like StatefulSets, a DaemonSet is defined as part of a YAML definition using kind: DaemonSet.

Per altre informazioni, vedere Oggetti DaemonSet di Kubernetes.For more information, see Kubernetes DaemonSets.

Spazi dei nomiNamespaces

Le risorse di Kubernetes, ad esempio i pod e le distribuzioni, vengono raggruppate logicamente in uno spazio dei nomi.Kubernetes resources, such as pods and Deployments, are logically grouped into a namespace. Questi raggruppamenti consentono di dividere logicamente un servizio Azure Kubernetes in Azure Stack cluster di destinazione HCI e di limitare l'accesso per creare, visualizzare o gestire le risorse.These groupings provide a way to logically divide an Azure Kubernetes Service on Azure Stack HCI target cluster and restrict access to create, view, or manage resources. Ad esempio, è possibile creare spazi dei nomi per separare gruppi aziendali.You can create namespaces to separate business groups, for example. Gli utenti possono interagire solo con le risorse all'interno degli spazi dei nomi assegnati.Users can only interact with resources within their assigned namespaces.

Quando si crea un cluster del servizio Kubernetes di Azure in Azure Stack HCI, sono disponibili gli spazi dei nomi seguenti:When you create an Azure Kubernetes Service cluster on Azure Stack HCI, the following namespaces are available:

  • predefinito: lo spazio dei nomi dove i pod e le distribuzioni vengono creati per impostazione predefinita se non ne viene specificato un altro.default - This namespace is where pods and deployments are created by default when none is provided. Negli ambienti più piccoli è possibile distribuire le applicazioni direttamente nello spazio dei nomi predefinito senza creare altre suddivisioni logiche.In smaller environments, you can deploy applications directly into the default namespace without creating additional logical separations. Quando si interagisce con l'API di Kubernetes, ad esempio kubectl get pods, viene usato lo spazio dei nomi predefinito se non ne viene specificato un altro.When you interact with the Kubernetes API, such as with kubectl get pods, the default namespace is used when none is specified.
  • kube system: lo spazio dei nomi in cui sono presenti le risorse principali, ad esempio le funzionalità di rete come DNS e proxy o il dashboard di Kubernetes.kube-system - This namespace is where core resources exist, such as network features like DNS and proxy, or the Kubernetes dashboard. In genere non si distribuiscono le proprie applicazioni in questo spazio dei nomi.You typically don't deploy your own applications into this namespace.
  • kube-public: questo spazio dei nomi solitamente non viene usato ma può essere usato per le risorse che devono essere visibili nell'intero cluster ed essere visualizzate da tutti gli utenti.kube-public - This namespace is typically not used, but can be used for resources to be visible across the whole cluster, and can be viewed by any user.

Per altre informazioni, vedere Spazi dei nomi di Kubernetes.For more information, see Kubernetes namespaces.