Kubernetes Core-koncept för Azure Kubernetes service på Azure Stack HCIKubernetes core concepts for Azure Kubernetes Service on Azure Stack HCI

Gäller för: AKS på Azure Stack HCI, AKS runtime på Windows Server 2019 Data CenterApplies to: AKS on Azure Stack HCI, AKS runtime on Windows Server 2019 Datacenter

Azure Kubernetes service på Azure Stack HCI är en plattform för Kubernetes-behållare i företags klass som drivs av Azure Stack HCI.Azure Kubernetes Service on Azure Stack HCI is an enterprise-grade Kubernetes container platform powered by Azure Stack HCI. Den innehåller Microsoft-Kubernetes som stöds, tillägg, en funktion som skapar en värd för Windows-behållare och en Microsoft-kompatibel Linux-container värd med målet att ha en enkel distributions-och livs cykel hanterings upplevelse.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.

Den här artikeln beskriver kärn Kubernetes infrastruktur komponenter som kontroll plan, noder och nodkonfigurationer.This article introduces the core Kubernetes infrastructure components such as the control plane, nodes, and node pools. Arbets belastnings resurser som poddar, distributioner och uppsättningar introduceras också, tillsammans med hur du grupperar resurser till namn områden.Workload resources such as pods, deployments, and sets are also introduced, along with how to group resources into namespaces.

Arkitektur för Kubernetes-klusterKubernetes cluster architecture

Kubernetes är kärn komponenten i Azure Kubernetes-tjänsten på Azure Stack HCI.Kubernetes is the core component of the Azure Kubernetes Service on Azure Stack HCI. Azure Kubernetes service på Azure Stack HCI använder en uppsättning fördefinierade konfigurationer för att distribuera Kubernetes-kluster effektivt och med skalbarhet i åtanke.Azure Kubernetes Service on Azure Stack HCI uses a set of predefined configurations to deploy Kubernetes cluster(s) effectively and with scalability in mind.

Distributions åtgärden skapar flera virtuella Linux-eller Windows-datorer och ansluter samman dem för att skapa Kubernetes-kluster.The deployment operation will create multiple Linux or Windows virtual machines and join these together to create Kubernetes cluster(s).

Det distribuerade systemet är redo att ta emot standard Kubernetes-arbetsbelastningar, skala dessa arbets belastningar eller till och med skala antalet virtuella datorer samt antalet kluster upp och ned efter behov.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.

Ett Azure Kubernetes service-kluster är uppdelat i två huvud komponenter på Azure Stack HCI:An Azure Kubernetes Service cluster is divided into two main components on Azure Stack HCI:

  • Hanterings kluster tillhandahåller mekanismen för kärn dirigering och gränssnitt för att distribuera och hantera ett eller flera mål kluster.Management cluster provides the the core orchestration mechanism and interface for deploying and managing one or more target clusters.
  • Mål kluster (även kallade arbets belastnings kluster) är där program arbets belastningar körs och hanteras av ett Hanterings kluster.Target clusters (also known as workload clusters) are where application workloads run and are managed by a management cluster.

Visar den tekniska arkitekturen i Azure Kubernetes service på Azure Stack HCI

Hanterings klusterManagement cluster

När du skapar ett Azure Kubernetes service-kluster på Azure Stack HCI skapas och konfigureras ett Hanterings kluster automatiskt.When you create an Azure Kubernetes Service cluster on Azure Stack HCI, a management cluster is automatically created and configured. Det här hanterings klustret ansvarar för etablering och hantering av mål kluster där arbets belastningar körs.This management cluster is responsible for provisioning and managing target clusters where workloads run. Ett Hanterings kluster innehåller följande kärn Kubernetes-komponenter:A management cluster includes the following core Kubernetes components:

  • API -Server – API-servern är hur de underliggande API: erna för Kubernetes exponeras.API Server - The API server is how the underlying Kubernetes APIs are exposed. Den här komponenten ger interaktion för hanterings verktyg som Windows administrations Center, PowerShell-moduler eller kubectl .This component provides the interaction for management tools such as Windows Admin Center, PowerShell modules, or kubectl.
  • Load Balancer – belastningsutjämnaren är en enskild dedikerad virtuell Linux-dator med en belastnings Utjämnings regel för hanterings KLUSTRETs API-Server.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 administrations CenterWindows Admin Center

Windows administrations Center erbjuder ett intuitivt användar gränssnitt för Kubernetes-operatören för att hantera livs cykeln för Azure Kubernetes service-kluster på 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.

PowerShell-modulPowerShell module

PowerShell-modulen är ett enkelt sätt att ladda ned, konfigurera och Distribuera Azure Kubernetes-tjänsten på Azure Stack HCI.The PowerShell module is an easy way to download, configure and deploy Azure Kubernetes Service on Azure Stack HCI. PowerShell-modulen stöder också distribution och konfiguration av ytterligare mål kluster samt omkonfigurering av befintliga.The PowerShell module also supports deploying and configuring additional target clusters as well as reconfiguring existing ones.

Mål klusterTarget cluster

Mål klustret (arbets belastning) är en distribution med hög tillgänglighet för Kubernetes med virtuella Linux-datorer för att köra Kubernetes Control plan-komponenter samt Linux Worker-noder.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. Windows Server Core-baserade virtuella datorer används för att etablera Windows Worker-noder.Windows Server Core based VMs are used for establishing Windows worker nodes. Det kan finnas ett eller flera mål kluster som hanteras av ett Hanterings kluster.There can be one or more target cluster(s) managed by one management cluster.

ArbetsnoderWorker nodes

Om du vill köra program och stöd tjänster behöver du en Kubernetes-nod.To run your applications and supporting services, you need a Kubernetes node. Ett Azure Kubernetes service Target-kluster på Azure Stack HCI har en eller flera arbetsnoder, som är en virtuell dator (VM) som kör Kubernetes-nodens komponenter, samt som värd för de poddar och tjänster som utgör programmets arbets belastning.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.

LastbalanserareLoad balancer

Belastningsutjämnaren är en virtuell dator som kör Linux och HAProxy + KeepAlive för att tillhandahålla belastningsutjämnade tjänster för mål kluster som distribueras av hanterings klustret.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.

För varje mål kluster kommer Azure Kubernetes-tjänsten på Azure Stack HCI att lägga till minst en virtuell belastningsutjämnare (LB VM).For each target cluster, Azure Kubernetes Service on Azure Stack HCI will add at least one load balancer virtual machines (LB VM). Förutom detta kan en annan belastningsutjämnare skapas för hög tillgänglighet för API-servern i mål klustret.In addition to this, another load balancer can be created for high availability of the API server on the target cluster. Alla Kubernetes-tjänster av typen LoadBalancer som skapas på mål klustret kommer att få skapa en belastnings Utjämnings regel i den virtuella lb-datorn.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.

Add-On-komponenterAdd-On components

Det finns flera valfria tilläggs komponenter som kan distribueras i ett angivet kluster, främst: Azure Arc, Prometheus, Grafana eller instrument panelen 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.

Kubernetes-komponenterKubernetes components

I det här avsnittet beskrivs kärn Kubernetes arbets belastnings komponenter som kan distribueras i Azure Kubernetes-tjänsten på Azure Stack HCI-mål kluster som poddar, distributioner och uppsättningar, tillsammans med hur du grupperar resurser till namn områden.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.

poddarpods

Kubernetes använder poddar för att köra en instans av programmet.Kubernetes uses pods to run an instance of your application. En POD representerar en enda instans av ditt program.A pod represents a single instance of your application. poddar har vanligt vis en 1:1-mappning med en behållare, även om det finns avancerade scenarier där en POD kan innehålla flera behållare.pods typically have a 1:1 mapping with a container, although there are advanced scenarios where a pod may contain multiple containers. Dessa poddar för flera behållare schemaläggs tillsammans på samma nod och tillåter att behållare delar relaterade resurser.These multi-container pods are scheduled together on the same node, and allow containers to share related resources.

När du skapar en POD kan du definiera resurs begär Anden för att begära en viss mängd CPU-eller minnes resurser.When you create a pod, you can define resource requests to request a certain amount of CPU or memory resources. Kubernetes Scheduler försöker schemalägga poddar att köra på en nod med tillgängliga resurser för att uppfylla begäran.The Kubernetes Scheduler tries to schedule the pods to run on a node with available resources to meet the request. Du kan också ange högsta antal resurs gränser som förhindrar att en specifik Pod förbrukar för mycket data bearbetnings resurser från den underliggande noden.You can also specify maximum resource limits that prevent a given pod from consuming too much compute resource from the underlying node. Ett bra tips är att inkludera resurs gränser för alla poddar som hjälper Kubernetes Scheduler att förstå vilka resurser som behövs och är tillåtna.A best practice is to include resource limits for all pods to help the Kubernetes Scheduler understand which resources are needed and permitted.

Mer information finns i Kubernetes poddar och Kubernetes Pod Lifecycle.For more information, see Kubernetes pods and Kubernetes pod lifecycle.

En pod är en logisk resurs, men behållarna är där program arbets belastningarna körs.A pod is a logical resource, but the container(s) are where the application workloads run. poddar är vanligt vis tillfälliga, disponibla resurser och individuellt schemalagda poddar saknar några av funktionerna för hög tillgänglighet och redundans Kubernetes ger.pods are typically ephemeral, disposable resources, and individually scheduled pods miss some of the high availability and redundancy features Kubernetes provides. I stället distribueras och hanteras poddar av Kubernetes- kontrollanter, till exempel distributions styrenheten.Instead, pods are deployed and managed by Kubernetes Controllers, such as the Deployment Controller.

Distributioner och YAML-manifestDeployments and YAML manifests

En distribution representerar en eller flera identiska poddar som hanteras av distributions styrenheten för Kubernetes.A deployment represents one or more identical pods, managed by the Kubernetes Deployment Controller. En distribution definierar antalet repliker (poddar) som ska skapas och Schemaläggaren för Kubernetes säkerställer att ytterligare poddar schemaläggs på felfria noder om poddar eller noder stöter på problem.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.

Du kan uppdatera distributioner för att ändra konfigurationen för poddar, behållar avbildning som används eller bifogad lagring.You can update deployments to change the configuration of pods, container image used, or attached storage. Distributions styrenheten tömmer och avslutar ett angivet antal repliker, skapar repliker från den nya distributions definitionen och fortsätter processen tills alla repliker i distributionen har uppdaterats.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.

De flesta tillstånds lösa program bör använda distributions modellen i stället för att schemalägga enskilda poddar.Most stateless applications should use the deployment model rather than scheduling individual pods. Kubernetes kan övervaka hälso tillstånd och status för distributioner för att säkerställa att antalet repliker som krävs körs i klustret.Kubernetes can monitor the health and status of deployments to ensure that the required number of replicas run within the cluster. När du bara schemalägger enskilda poddar startas poddar om, om det uppstår ett problem och inte omplaneras på felfria noder om deras aktuella nod påträffar ett problem.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.

Om ett program kräver ett kvorum av instanser för att alltid vara tillgängligt för hanterings beslut, vill du inte att en uppdaterings process ska störa den möjligheten.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. Pod avbrott i budgetar kan användas för att definiera hur många repliker i en distribution som kan tas offline under en uppdatering eller nod-uppgradering.pod Disruption Budgets can be used to define how many replicas in a deployment can be taken down during an update or node upgrade. Om du till exempel har fem (5) repliker i distributionen kan du definiera ett Pod-avbrott på 4 för att endast tillåta att en replik tas bort/ombokas i taget.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. Precis som med Pod resurs gränser är det en bra idé att definiera Pod avbrotts budgetar för program som kräver att det alltid finns ett minsta antal repliker.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.

Distributioner skapas och hanteras vanligt vis med kubectl create eller kubectl apply .Deployments are typically created and managed with kubectl create or kubectl apply. Om du vill skapa en distribution definierar du en manifest fil i formatet YAML (YAML Ain't Markup Language).To create a deployment, you define a manifest file in the YAML (YAML Ain't Markup Language) format. I följande exempel skapas en grundläggande distribution av NGINX-webbservern.The following example creates a basic deployment of the NGINX web server. I distributionen anges tre (3) repliker som ska skapas, och port 80 måste vara öppen på behållaren.The deployment specifies three (3) replicas to be created, and requires port 80 to be open on the container. Resurs begär Anden och gränser definieras också för processor och minne.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

Du kan också skapa mer komplexa program genom att även inkludera tjänster som belastningsutjämnare i YAML-manifestet.More complex applications can also be created by also including services such as load balancers within the YAML manifest.

Mer information finns i Kubernetes-distributionerFor more information, see Kubernetes deployments

Distributioner med blandat operativ systemMixed-OS deployments

Om en specifik Azure Kubernetes-tjänst på Azure Stack HCI-mål kluster består av både Linux-och Windows-arbetsnoder, måste arbets belastningarna schemaläggas till ett operativ system som har stöd för etablering av arbets belastningen.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 erbjuder två mekanismer för att säkerställa att arbets belastningar hamnar på noder med ett mål operativ system:Kubernetes offers two mechanisms to ensure workloads land on nodes with a target operating system:

  • Node Selector är ett enkelt fält i pod-specifikationen som begränsar poddar till att bara schemaläggas till felfria noder som matchar operativ systemet.Node Selector is a simple field in the pod spec that constraints pods to only be scheduled onto healthy nodes matching the operating system.
  • Bismakar och-tolererar fungerar tillsammans för att säkerställa att poddar inte är schemalagda till noderna oavsiktligt.Taints and tolerations work together to ensure that pods are not scheduled onto nodes unintentionally. En nod kan vara "förvarad" så att den inte accepterar poddar som inte uttryckligen tolererar dess bismak genom en "tolerera" i pod-specifikationen.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.

Mer information finns i Node selecters och- bismakar och tolererar.For more information, see node selectors and taints and tolerations.

StatefulSets och DaemonSetsStatefulSets and DaemonSets

Distributions styrenheten använder Kubernetes Scheduler för att köra ett angivet antal repliker på alla tillgängliga noder med tillgängliga resurser.The Deployment Controller uses the Kubernetes Scheduler to run a given number of replicas on any available node with available resources. Den här metoden för att använda distributioner kan vara tillräckligt för tillstånds lösa program, men inte för program som kräver en beständig namngivnings konvention eller lagring.This approach of using deployments may be sufficient for stateless applications, but not for applications that require a persistent naming convention or storage. För program som kräver att en replik finns på varje nod, eller valda noder, i ett kluster, tittar distributions hanteraren inte på hur repliker distribueras mellan noderna.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.

Det finns två Kubernetes-resurser som låter dig hantera följande typer av program:There are two Kubernetes resources that let you manage these types of applications:

  • StatefulSets – underhålla program tillstånd bortom en enskild Pod-livscykel, till exempel lagring.StatefulSets - Maintain the state of applications beyond an individual pod lifecycle, such as storage.
  • DaemonSets – se till att en instans körs på varje nod, tidigt i Start processen för Kubernetes.DaemonSets - Ensure a running instance on each node, early in the Kubernetes bootstrap process.

StatefulSetsStatefulSets

Modern program utveckling syftar ofta till tillstånds lösa program, men StatefulSets kan användas för tillstånds känsliga program, till exempel program som innehåller databas komponenter.Modern application development often aims for stateless applications, but StatefulSets can be used for stateful applications, such as applications that include database components. En StatefulSet liknar en distribution i som en eller flera identiska poddar skapas och hanteras.A StatefulSet is similar to a deployment in that one or more identical pods are created and managed. Repliker i en StatefulSet följer en korrekt, sekventiell metod för distribution, skalning, uppgraderingar och avslutning.Replicas in a StatefulSet follow a graceful, sequential approach to deployment, scale, upgrades, and terminations. Med en StatefulSet (som repliker omplaneras) namngivnings konventionen, nätverks namn och lagrings utrymme.With a StatefulSet (as replicas are rescheduled) the naming convention, network names, and storage persist.

Du definierar programmet i YAML-format med kind: StatefulSet , och StatefulSet-kontrollanten hanterar sedan distributionen och hanteringen av de nödvändiga replikerna.You define the application in YAML format using kind: StatefulSet, and the StatefulSet Controller then handles the deployment and management of the required replicas. Data skrivs till beständig lagring, med den underliggande lagringen kvar även efter att StatefulSet har tagits bort.Data is written to persistent storage, with the underlying storage persisting even after the StatefulSet is deleted.

Mer information finns i Kubernetes StatefulSets.For more information, see Kubernetes StatefulSets.

Repliker i en StatefulSet schemaläggs och körs över alla tillgängliga noder i en Azure Kubernetes-tjänst på Azure Stack HCI-kluster.Replicas in a StatefulSet are scheduled and run across any available node in an Azure Kubernetes Service on Azure Stack HCI cluster. Om du behöver se till att minst en POD i uppsättningen körs på en nod kan du i stället använda en DaemonSet.If you need to ensure that at least one pod in your Set runs on a node, you can instead use a DaemonSet.

DaemonSetsDaemonSets

För specifik logg samling eller övervaknings behov kan du behöva köra en viss Pod på alla eller valda noder.For specific log collection or monitoring needs, you may need to run a given pod on all, or selected, nodes. En DaemonSet används återigen för att distribuera en eller flera identiska poddar, men DaemonSet-styrenheten säkerställer att varje nod som anges kör en instans av 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.

DaemonSet-kontrollanten kan schemalägga poddar på noderna tidigt i kluster start processen, innan standard-Kubernetes Scheduler har startat.The DaemonSet Controller can schedule pods on nodes early in the cluster boot process, before the default Kubernetes scheduler has started. Den här funktionen säkerställer att poddar i en DaemonSet startas innan traditionella poddar i en distribution eller StatefulSet schemaläggs.This ability ensures that the pods in a DaemonSet are started before traditional pods in a Deployment or StatefulSet are scheduled.

Som StatefulSets definieras en DaemonSet som en del av en YAML-definition med hjälp av kind: DaemonSet .Like StatefulSets, a DaemonSet is defined as part of a YAML definition using kind: DaemonSet.

Mer information finns i Kubernetes DaemonSets.For more information, see Kubernetes DaemonSets.

NamnrymderNamespaces

Kubernetes-resurser, till exempel poddar och distributioner, grupperas logiskt i ett namn område.Kubernetes resources, such as pods and Deployments, are logically grouped into a namespace. Dessa grupperingar ger ett sätt att logiskt dela upp en Azure Kubernetes-tjänst på Azure Stack HCI-mål kluster och begränsa åtkomsten till att skapa, Visa eller hantera resurser.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. Du kan till exempel skapa namn områden för att separera affärs grupper.You can create namespaces to separate business groups, for example. Användare kan bara interagera med resurser inom de tilldelade namn områdena.Users can only interact with resources within their assigned namespaces.

När du skapar ett Azure Kubernetes service-kluster på Azure Stack HCI är följande namn rymder tillgängliga:When you create an Azure Kubernetes Service cluster on Azure Stack HCI, the following namespaces are available:

  • standard – det här namn området är där poddar och distributioner skapas som standard när inget anges.default - This namespace is where pods and deployments are created by default when none is provided. I mindre miljöer kan du distribuera program direkt till standard namn området utan att skapa ytterligare logiska separationer.In smaller environments, you can deploy applications directly into the default namespace without creating additional logical separations. När du interagerar med Kubernetes-API: t, till exempel med kubectl get pods , används standard namn området när inget anges.When you interact with the Kubernetes API, such as with kubectl get pods, the default namespace is used when none is specified.
  • Kube-system – det här namn området är där kärn resurser finns, till exempel nätverks funktioner som DNS och proxy eller Kubernetes-instrumentpanelen.kube-system - This namespace is where core resources exist, such as network features like DNS and proxy, or the Kubernetes dashboard. Du distribuerar vanligt vis inte dina egna program till det här namn området.You typically don't deploy your own applications into this namespace.
  • Kube – det här namn området används vanligt vis inte, men kan användas för att visa resurser över hela klustret och kan visas av alla användare.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.

Mer information finns i Kubernetes-namnområden.For more information, see Kubernetes namespaces.