Masterbtc/Kubernetes_documentation huggingface dataset:
# Scale a StatefulSet

Scale a StatefulSetThis task shows how to scale a StatefulSet. Scaling a StatefulSet refers to increasing or decreasing the number of replicas.Before you beginStatefulSets are only available in Kubernetes version 1.5 or later. To check your version of Kubernetes, run kubectl version.Not all stateful applications scale nicely. If you are unsure about whether to scale your StatefulSets, see StatefulSet concepts or StatefulSet tutorial for further information.You should perform scaling only when you are confident that your stateful application cluster is completely healthy.Scaling StatefulSetsUse kubectl to scale StatefulSetsFirst, find the StatefulSet you want to scale.kubectl get statefulsets <stateful-set-name> Change the number of replicas of your StatefulSet:kubectl scale statefulsets <stateful-set-name> --replicas=<new-replicas> Make in-place updates on your StatefulSetsAlternatively, you can do in-place updates on your StatefulSets.If your StatefulSet was initially created with kubectl apply, update .spec.replicas of the StatefulSet manifests, and then do a kubectl apply:kubectl apply -f <stateful-set-file-updated> Otherwise, edit that field with kubectl edit:kubectl edit statefulsets <stateful-set-name> Or use kubectl patch:kubectl patch statefulsets <stateful-set-name> -p '{"spec":{"replicas":<new-replicas>}}' TroubleshootingScaling down does not work rightYou cannot scale down a StatefulSet when any of the stateful Pods it manages is unhealthy. Scaling down only takes place after those stateful Pods become running and ready.If spec.replicas > 1, Kubernetes cannot determine the reason for an unhealthy Pod. It might be the result of a permanent fault or of a transient fault. A transient fault can be caused by a restart required by upgrading or maintenance.If the Pod is unhealthy due to a permanent fault, scaling without correcting the fault may lead to a state where the StatefulSet membership drops below a certain minimum number of replicas that are needed to function correctly. This may cause your StatefulSet to become unavailable.If the Pod is unhealthy due to a transient fault and the Pod might become available again, the transient error may interfere with your scale-up or scale-down operation. Some distributed databases have issues when nodes join and leave at the same time. It is better to reason about scaling operations at the application level in these cases, and perform scaling only when you are sure that your stateful application cluster is completely healthy.What's nextLearn more about deleting a StatefulSet.
# kubeadm version

kubeadm versionThis command prints the version of kubeadm.SynopsisPrint the version of kubeadmkubeadm version [flags] Options-h, --helphelp for version-o, --output stringOutput format; available options are 'yaml', 'json' and 'short'Options inherited from parent commands--rootfs stringThe path to the 'real' host root filesystem. This will cause kubeadm to chroot into the provided path.
# ComponentStatus

ComponentStatusComponentStatus (and ComponentStatusList) holds the cluster validation info.apiVersion: v1import "k8s.io/api/core/v1"ComponentStatusComponentStatus (and ComponentStatusList) holds the cluster validation info. Deprecated: This API is deprecated in v1.19+apiVersion: v1kind: ComponentStatusmetadata (ObjectMeta)Standard object's metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadataconditions ([]ComponentCondition)Patch strategy: merge on key typeMap: unique values on key type will be kept during a mergeList of component conditions observedInformation about the condition of a component.conditions.status (string), requiredStatus of the condition for a component. Valid values for "Healthy": "True", "False", or "Unknown".conditions.type (string), requiredType of condition for a component. Valid value: "Healthy"conditions.error (string)Condition error code for a component. For example, a health check error code.conditions.message (string)Message about the condition for a component. For example, information about a health check.ComponentStatusListStatus of all the conditions for the component as a list of ComponentStatus objects. Deprecated: This API is deprecated in v1.19+apiVersion: v1kind: ComponentStatusListmetadata (ListMeta)Standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kindsitems ([]ComponentStatus), requiredList of ComponentStatus objects.Operationsget read the specified ComponentStatusHTTP RequestGET /api/v1/componentstatuses/{name}Parametersname (in path): string, requiredname of the ComponentStatuspretty (in query): stringprettyResponse200 (ComponentStatus): OK401: Unauthorizedlist list objects of kind ComponentStatusHTTP RequestGET /api/v1/componentstatusesParametersallowWatchBookmarks (in query): booleanallowWatchBookmarkscontinue (in query): stringcontinuefieldSelector (in query): stringfieldSelectorlabelSelector (in query): stringlabelSelectorlimit (in query): integerlimitpretty (in query): stringprettyresourceVersion (in query): stringresourceVersionresourceVersionMatch (in query): stringresourceVersionMatchsendInitialEvents (in query): booleansendInitialEventstimeoutSeconds (in query): integertimeoutSecondswatch (in query): booleanwatchResponse200 (ComponentStatusList): OK401: UnauthorizedThis page is automatically generated.If you plan to report an issue with this page, mention that the page is auto-generated in your issue description. The fix may need to happen elsewhere in the Kubernetes project.
# Developing Cloud Controller Manager

Developing Cloud Controller ManagerFEATURE STATE: Kubernetes v1.11 [beta]The cloud-controller-manager is a Kubernetes control plane component that embeds cloud-specific control logic. The cloud controller manager lets you link your cluster into your cloud provider's API, and separates out the components that interact with that cloud platform from components that only interact with your cluster.By decoupling the interoperability logic between Kubernetes and the underlying cloud infrastructure, the cloud-controller-manager component enables cloud providers to release features at a different pace compared to the main Kubernetes project.BackgroundSince cloud providers develop and release at a different pace compared to the Kubernetes project, abstracting the provider-specific code to the cloud-controller-manager binary allows cloud vendors to evolve independently from the core Kubernetes code.The Kubernetes project provides skeleton cloud-controller-manager code with Go interfaces to allow you (or your cloud provider) to plug in your own implementations. This means that a cloud provider can implement a cloud-controller-manager by importing packages from Kubernetes core; each cloudprovider will register their own code by calling cloudprovider.RegisterCloudProvider to update a global variable of available cloud providers.DevelopingOut of treeTo build an out-of-tree cloud-controller-manager for your cloud:Create a go package with an implementation that satisfies cloudprovider.Interface.Use main.go in cloud-controller-manager from Kubernetes core as a template for your main.go. As mentioned above, the only difference should be the cloud package that will be imported.Import your cloud package in main.go, ensure your package has an init block to run cloudprovider.RegisterCloudProvider.Many cloud providers publish their controller manager code as open source. If you are creating a new cloud-controller-manager from scratch, you could take an existing out-of-tree cloud controller manager as your starting point.In treeFor in-tree cloud providers, you can run the in-tree cloud controller manager as a DaemonSet in your cluster. See Cloud Controller Manager Administration for more details.
# Migrating from dockershim

Migrating from dockershimThis section presents information you need to know when migrating from dockershim to other container runtimes.Since the announcement of dockershim deprecation in Kubernetes 1.20, there were questions on how this will affect various workloads and Kubernetes installations. Our Dockershim Removal FAQ is there to help you to understand the problem better.Dockershim was removed from Kubernetes with the release of v1.24. If you use Docker Engine via dockershim as your container runtime and wish to upgrade to v1.24, it is recommended that you either migrate to another runtime or find an alternative means to obtain Docker Engine support. Check out the container runtimes section to know your options.The version of Kubernetes with dockershim (1.23) is out of support and the v1.24 will run out of support soon. Make sure to report issues you encountered with the migration so the issues can be fixed in a timely manner and your cluster would be ready for dockershim removal. After v1.24 running out of support, you will need to contact your Kubernetes provider for support or upgrade multiple versions at a time if there are critical issues affecting your cluster.Your cluster might have more than one kind of node, although this is not a common configuration.These tasks will help you to migrate:Check whether Dockershim removal affects youMigrating telemetry and security agents from dockershimWhat's nextCheck out container runtimes to understand your options for an alternative.If you find a defect or other technical concern relating to migrating away from dockershim, you can report an issue to the Kubernetes project.
# Compute, Storage, and Networking Extensions

Compute, Storage, and Networking ExtensionsThis section covers extensions to your cluster that do not come as part as Kubernetes itself. You can use these extensions to enhance the nodes in your cluster, or to provide the network fabric that links Pods together.CSI and FlexVolume storage pluginsContainer Storage Interface (CSI) plugins provide a way to extend Kubernetes with supports for new kinds of volumes. The volumes can be backed by durable external storage, or provide ephemeral storage, or they might offer a read-only interface to information using a filesystem paradigm.Kubernetes also includes support for FlexVolume plugins, which are deprecated since Kubernetes v1.23 (in favour of CSI).FlexVolume plugins allow users to mount volume types that aren't natively supported by Kubernetes. When you run a Pod that relies on FlexVolume storage, the kubelet calls a binary plugin to mount the volume. The archived FlexVolume design proposal has more detail on this approach.The Kubernetes Volume Plugin FAQ for Storage Vendors includes general information on storage plugins.Device pluginsDevice plugins allow a node to discover new Node facilities (in addition to the built-in node resources such as cpu and memory), and provide these custom node-local facilities to Pods that request them.Network pluginsNetwork plugins allow Kubernetes to work with different networking topologies and technologies. Your Kubernetes cluster needs a network plugin in order to have a working Pod network and to support other aspects of the Kubernetes network model.Kubernetes 1.34 is compatible with CNI network plugins.
# Kubectl user preferences (kuberc)

Kubectl user preferences (kuberc)FEATURE STATE: Kubernetes 1.34 [beta]A Kubernetes kuberc configuration file allows you to define preferences for kubectl, such as default options and command aliases. Unlike the kubeconfig file, a kuberc configuration file does not contain cluster details, usernames or passwords.The default location of this configuration file is $HOME/.kube/kuberc. To provide kubectl with a path to a custom kuberc file, use the --kuberc command line option, or set the KUBERC environment variable.A kuberc using the kubectl.config.k8s.io/v1beta1 format allows you to define two types of user preferences:Aliases - allow you to create shorter versions of your favorite commands, optionally setting options and arguments.Defaults - allow you to configure default option values for your favorite commands.aliasesWithin a kuberc configuration, the aliases section allows you to define custom shortcuts for kubectl commands, optionally with preset command line arguments and flags.This
# CRI Pod & Container Metrics

CRI Pod & Container MetricsCollection of Pod & Container metrics via the CRI.FEATURE STATE: Kubernetes v1.23 [alpha]The kubelet collects pod and container metrics via cAdvisor. As an alpha feature, Kubernetes lets you configure the collection of pod and container metrics via the Container Runtime Interface (CRI). You must enable the PodAndContainerStatsFromCRI feature gate and use a compatible CRI implementation (containerd >= 1.6.0, CRI-O >= 1.23.0) to use the CRI based collection mechanism.CRI Pod & Container MetricsWith PodAndContainerStatsFromCRI enabled, the kubelet polls the underlying container runtime for pod and container stats instead of inspecting the host system directly using cAdvisor. The benefits of relying on the container runtime for this information as opposed to direct collection with cAdvisor include:Potential improved performance if the container runtime already collects this information during normal operations. In this case, the data can be re-used instead of being aggregated again by the kubelet.It further decouples the kubelet and the container runtime allowing collection of metrics for container runtimes that don't run processes directly on the host with kubelet where they are observable by cAdvisor (for example: container runtimes that use virtualization).
# Enable Or Disable A Kubernetes API

Enable Or Disable A Kubernetes APIThis page shows how to enable or disable an API version from your cluster's control plane.Specific API versions can be turned on or off by passing --runtime-config=api/<version> as a command line argument to the API server. The values for this argument are a comma-separated list of API versions. Later values override earlier values.The runtime-config command line argument also supports 2 special keys:api/all, representing all known APIsapi/legacy, representing only legacy APIs. Legacy APIs are any APIs that have been explicitly deprecated.For example, to turn off all API versions except v1, pass --runtime-config=api/all=false,api/v1=true to the kube-apiserver.What's nextRead the full documentation for the kube-apiserver component.
# Kubernetes Security and Disclosure Information

Kubernetes Security and Disclosure InformationThis page describes Kubernetes security and disclosure information.Security AnnouncementsJoin the kubernetes-security-announce group for emails about security and major API announcements.Report a VulnerabilityWe're extremely grateful for security researchers and users that report vulnerabilities to the Kubernetes Open Source Community. All reports are thoroughly investigated by a set of community volunteers.To make a report, submit your vulnerability to the Kubernetes bug bounty program. This allows triage and handling of the vulnerability with standardized response times.You can also email the private security@kubernetes.io list with the security details and the details expected for all Kubernetes bug reports.You may encrypt your email to this list using the GPG keys of the Security Response Committee members. Encryption using GPG is NOT required to make a disclosure.When Should I Report a Vulnerability?You think you discovered a potential security vulnerability in KubernetesYou are unsure how a vulnerability affects KubernetesYou think you discovered a vulnerability in another project that Kubernetes depends onFor projects with their own vulnerability reporting and disclosure process, please report it directly thereWhen Should I NOT Report a Vulnerability?You need help tuning Kubernetes components for securityYou need help applying security related updatesYour issue is not security relatedSecurity Vulnerability ResponseEach report is acknowledged and analyzed by Security Response Committee members within 3 working days. This will set off the Security Release Process.Any vulnerability information shared with Security Response Committee stays within Kubernetes project and will not be disseminated to other projects unless it is necessary to get the issue fixed.As the security issue moves from triage, to identified fix, to release planning we will keep the reporter updated.Public Disclosure TimingA public disclosure date is negotiated by the Kubernetes Security Response Committee and the bug submitter. We prefer to fully disclose the bug as soon as possible once a user mitigation is available. It is reasonable to delay disclosure when the bug or the fix is not yet fully understood, the solution is not well-tested, or for vendor coordination. The timeframe for disclosure is from immediate (especially if it's already publicly known) to a few weeks. For a vulnerability with a straightforward mitigation, we expect report date to disclosure date to be on the order of 7 days. The Kubernetes Security Response Committee holds the final say when setting a disclosure date.
# Contribute to Kubernetes

There are lots of ways to contribute to Kubernetes. You can work on designs for new features, you can document the code we already have, you can write for our blogs. There's more: you can implement those new features or fix bugs. You can help people join our contributor community, or support existing contributors.With all these different ways to make a difference to the project, we - Kubernetes - have made a dedicated website: https://k8s.dev/. You can go there to learn more about contributing to Kubernetes.If you specifically want to learn about contributing to the documentation or other parts of this website, read Contribute to Kubernetes documentation. If you specifically want to help with the official Kubernetes blogs, read Contributing to Kubernetes blogs.You can also read the CNCF page about contributing to Kubernetes.
# TokenRequest

TokenRequestTokenRequest requests a token for a given service account.apiVersion: authentication.k8s.io/v1import "k8s.io/api/authentication/v1"TokenRequestTokenRequest requests a token for a given service account.apiVersion: authentication.k8s.io/v1kind: TokenRequestmetadata (ObjectMeta)Standard object's metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadataspec (TokenRequestSpec), requiredSpec holds information about the request being evaluatedstatus (TokenRequestStatus)Status is filled in by the server and indicates whether the token can be authenticated.TokenRequestSpecTokenRequestSpec contains client provided parameters of a token request.audiences ([]string), requiredAtomic: will be replaced during a mergeAudiences are the intended audiences of the token. A recipient of a token must identify themself with an identifier in the list of audiences of the token, and otherwise should reject the token. A token issued for multiple audiences may be used to authenticate against any of the audiences listed but implies a high degree of trust between the target audiences.boundObjectRef (BoundObjectReference)BoundObjectRef is a reference to an object that the token will be bound to. The token will only be valid for as long as the bound object exists. NOTE: The API server's TokenReview endpoint will validate the BoundObjectRef, but other audiences may not. Keep ExpirationSeconds small if you want prompt revocation.BoundObjectReference is a reference to an object that a token is bound to.boundObjectRef.apiVersion (string)API version of the referent.boundObjectRef.kind (string)Kind of the referent. Valid kinds are 'Pod' and 'Secret'.boundObjectRef.name (string)Name of the referent.boundObjectRef.uid (string)UID of the referent.expirationSeconds (int64)ExpirationSeconds is the requested duration of validity of the request. The token issuer may return a token with a different validity duration so a client needs to check the 'expiration' field in a response.TokenRequestStatusTokenRequestStatus is the result of a token request.expirationTimestamp (Time), requiredExpirationTimestamp is the time of expiration of the returned token.Time is a wrapper around time.Time which supports correct marshaling to YAML and JSON. Wrappers are provided for many of the factory methods that the time package offers.token (string), requiredToken is the opaque bearer token.Operationscreate create token of a ServiceAccountHTTP RequestPOST /api/v1/namespaces/{namespace}/serviceaccounts/{name}/tokenParametersname (in path): string, requiredname of the TokenRequestnamespace (in path): string, requirednamespacebody: TokenRequest, requireddryRun (in query): stringdryRunfieldManager (in query): stringfieldManagerfieldValidation (in query): stringfieldValidationpretty (in query): stringprettyResponse200 (TokenRequest): OK201 (TokenRequest): Created202 (TokenRequest): Accepted401: UnauthorizedThis page is automatically generated.If you plan to report an issue with this page, mention that the page is auto-generated in your issue description. The fix may need to happen elsewhere in the Kubernetes project.
# LocalSubjectAccessReview

LocalSubjectAccessReviewLocalSubjectAccessReview checks whether or not a user or group can perform an action in a given namespace.apiVersion: authorization.k8s.io/v1import "k8s.io/api/authorization/v1"LocalSubjectAccessReviewLocalSubjectAccessReview checks whether or not a user or group can perform an action in a given namespace. Having a namespace scoped resource makes it much easier to grant namespace scoped policy that includes permissions checking.apiVersion: authorization.k8s.io/v1kind: LocalSubjectAccessReviewmetadata (ObjectMeta)Standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadataspec (SubjectAccessReviewSpec), requiredSpec holds information about the request being evaluated. spec.namespace must be equal to the namespace you made the request against. If empty, it is defaulted.status (SubjectAccessReviewStatus)Status is filled in by the server and indicates whether the request is allowed or notOperationscreate create a LocalSubjectAccessReviewHTTP RequestPOST /apis/authorization.k8s.io/v1/namespaces/{namespace}/localsubjectaccessreviewsParametersnamespace (in path): string, requirednamespacebody: LocalSubjectAccessReview, requireddryRun (in query): stringdryRunfieldManager (in query): stringfieldManagerfieldValidation (in query): stringfieldValidationpretty (in query): stringprettyResponse200 (LocalSubjectAccessReview): OK201 (LocalSubjectAccessReview): Created202 (LocalSubjectAccessReview): Accepted401: UnauthorizedThis page is automatically generated.If you plan to report an issue with this page, mention that the page is auto-generated in your issue description. The fix may need to happen elsewhere in the Kubernetes project.
# Accessing Clusters

Accessing ClustersThis topic discusses multiple ways to interact with clusters.Accessing for the first time with kubectlWhen accessing the Kubernetes API for the first time, we suggest using the Kubernetes CLI, kubectl.To access a cluster, you need to know the location of the cluster and have credentials to access it. Typically, this is automatically set-up when you work through a Getting started guide, or someone else set up the cluster and provided you with credentials and a location.Check the location and credentials that kubectl knows about with this command:kubectl config view Many of the examples provide an introduction to using kubectl, and complete documentation is found in the kubectl reference.Directly accessing the REST APIKubectl handles locating and authenticating to the apiserver. If you want to directly access the REST API with an http client like curl or wget, or a browser, there are several ways to locate and authenticate:Run kubectl in proxy mode.Recommended approach.Uses stored apiserver location.Verifies identity of apiserver using self-signed cert. No MITM possible.Authenticates to apiserver.In future, may do intelligent client-side load-balancing and failover.Provide the location and credentials directly to the http client.Alternate approach.Works with some types of client code that are confused by using a proxy.Need to import a root cert into your browser to protect against MITM.Using kubectl proxyThe following command runs kubectl in a mode where it acts as a reverse proxy. It handles locating the apiserver and authenticating. Run it like this:kubectl proxy --port=8080 See kubectl proxy for more details.Then you can explore the API with curl, wget, or a browser, replacing localhost with [::1] for IPv6, like so:curl http://localhost:8080/api/ The output is similar to this:{ "kind": "APIVersions", "versions": [ "v1" ], "serverAddressByClientCIDRs": [ { "clientCIDR": "0.0.0.0/0", "serverAddress": "10.0.1.149:443" } ] } Without kubectl proxyUse kubectl apply and kubectl describe secret... to create a token for the default service account with grep/cut:First, create the Secret, requesting a token for the default ServiceAccount:kubectl apply -f - <<EOF apiVersion: v1 kind: Secret metadata: name: default-token annotations: kubernetes.io/service-account.name: default type: kubernetes.io/service-account-token EOF
# Config and Storage Resources

Config and Storage ResourcesConfigMapConfigMap holds configuration data for pods to consume.SecretSecret holds secret data of a certain type.CSIDriverCSIDriver captures information about a Container Storage Interface (CSI) volume driver deployed on the cluster.CSINodeCSINode holds information about all CSI drivers installed on a node.CSIStorageCapacityCSIStorageCapacity stores the result of one CSI GetCapacity call.PersistentVolumeClaimPersistentVolumeClaim is a user's request for and claim to a persistent volume.PersistentVolumePersistentVolume (PV) is a storage resource provisioned by an administrator.StorageClassStorageClass describes the parameters for a class of storage for which PersistentVolumes can be dynamically provisioned.StorageVersionMigration v1alpha1StorageVersionMigration represents a migration of stored data to the latest storage version.VolumeVolume represents a named volume in a pod that may be accessed by any container in the pod.VolumeAttachmentVolumeAttachment captures the intent to attach or detach the specified volume to/from the specified node.VolumeAttributesClassVolumeAttributesClass represents a specification of mutable volume attributes defined by the CSI driver.This page is automatically generated.If you plan to report an issue with this page, mention that the page is auto-generated in your issue description. The fix may need to happen elsewhere in the Kubernetes project.
# Use Cilium for NetworkPolicy

Use Cilium for NetworkPolicyThis page shows how to use Cilium for NetworkPolicy.For background on Cilium, read the Introduction to Cilium.Before you beginYou need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. It is recommended to run this tutorial on a cluster with at least two nodes that are not acting as control plane hosts. If you do not already have a cluster, you can create one by using minikube or you can use one of these Kubernetes playgrounds:iximiuz LabsKillercodaKodeKloudPlay with KubernetesTo check the version, enter kubectl version.Deploying Cilium on Minikube for Basic TestingTo get familiar with Cilium easily you can follow the Cilium Kubernetes Getting Started Guide to perform a basic DaemonSet installation of Cilium in minikube.To start minikube, minimal version required is >= v1.5.2, run the with the following arguments:minikube version minikube version: v1.5.2 minikube start --network-plugin=cni For minikube you can install Cilium using its CLI tool. To do so, first download the latest version of the CLI with the following command:curl -LO https://github.com/cilium/cilium-cli/releases/latest/download/cilium-linux-amd64.tar.gz Then extract the downloaded file to your /usr/local/bin directory with the following command:sudo tar xzvfC cilium-linux-amd64.tar.gz /usr/local/bin rm cilium-linux-amd64.tar.gz After running the above commands, you can now install Cilium with the following command:cilium install Cilium will then automatically detect the cluster configuration and create and install the appropriate components for a successful installation. The components are:Certificate Authority (CA) in Secret cilium-ca and certificates for Hubble (Cilium's observability layer).Service accounts.Cluster roles.ConfigMap.Agent DaemonSet and an Operator Deployment.After the installation, you can view the overall status of the Cilium deployment with the cilium status command. See the expected output of the status command here.The remainder of the Getting Started Guide explains how to enforce both L3/L4 (i.e., IP address + port) security policies, as well as L7 (e.g., HTTP) security policies using an example application.Deploying Cilium for Production UseFor detailed instructions around deploying Cilium for production, see: Cilium Kubernetes Installation Guide This documentation includes detailed requirements, instructions and example production DaemonSet files.Understanding Cilium componentsDeploying a cluster with Cilium adds Pods to the kube-system namespace. To see this list of Pods run:kubectl get pods --namespace=kube-system -l k8s-app=cilium You'll see a list of Pods similar to this:NAME READY STATUS RESTARTS AGE cilium-kkdhz 1/1 Running 0 3m23s ... A cilium Pod runs on each node in your cluster and enforces network policy on the traffic to/from Pods on that node using Linux BPF.What's nextOnce your cluster is running, you can follow the Declare Network Policy to try out Kubernetes NetworkPolicy with Cilium. Have fun, and if you have questions, contact us using the Cilium Slack Channel.
# Learn Kubernetes Basics

Learn Kubernetes BasicsObjectivesThis tutorial provides a walkthrough of the basics of the Kubernetes cluster orchestration system. Each module contains some background information on major Kubernetes features and concepts, and a tutorial for you to follow along.Using the tutorials, you can learn to:Deploy a containerized application on a cluster.Scale the deployment.Update the containerized application with a new software version.Debug the containerized application.What can Kubernetes do for you?With modern web services, users expect applications to be available 24/7, and developers expect to deploy new versions of those applications several times a day. Containerization helps package software to serve these goals, enabling applications to be released and updated without downtime. Kubernetes helps you make sure those containerized applications run where and when you want, and helps them find the resources and tools they need to work. Kubernetes is a production-ready, open source platform designed with Google's accumulated experience in container orchestration, combined with best-of-breed ideas from the community.Kubernetes Basics Modules1. Create a Kubernetes cluster2. Deploy an app3. Explore your app4. Expose your app publicly5. Scale up your app6. Update your appWhat's nextTutorial Using Minikube to Create a Cluster
# Kubernetes Components

Kubernetes ComponentsAn overview of the key components that make up a Kubernetes cluster.This page provides a high-level overview of the essential components that make up a Kubernetes cluster.The components of a Kubernetes clusterCore ComponentsA Kubernetes cluster consists of a control plane and one or more worker nodes. Here's a brief overview of the main components:Control Plane ComponentsManage the overall state of the cluster:kube-apiserverThe core component server that exposes the Kubernetes HTTP API.etcdConsistent and highly-available key value store for all API server data.kube-schedulerLooks for Pods not yet bound to a node, and assigns each Pod to a suitable node.kube-controller-managerRuns controllers to implement Kubernetes API behavior.cloud-controller-manager (optional)Integrates with underlying cloud provider(s).Node ComponentsRun on every node, maintaining running pods and providing the Kubernetes runtime environment:kubeletEnsures that Pods are running, including their containers.kube-proxy (optional)Maintains network rules on nodes to implement Services.Container runtimeSoftware responsible for running containers. Read Container Runtimes to learn more.🛇 This item links to a third party project or product that is not part of Kubernetes itself. More informationYour cluster may require additional software on each node; for example, you might also run systemd on a Linux node to supervise local components.AddonsAddons extend the functionality of Kubernetes. A few important examples include:DNSFor cluster-wide DNS resolution.Web UI (Dashboard)For cluster management via a web interface.Container Resource MonitoringFor collecting and storing container metrics.Cluster-level LoggingFor saving container logs to a central log store.Flexibility in ArchitectureKubernetes allows for flexibility in how these components are deployed and managed. The architecture can be adapted to various needs, from small development environments to large-scale production deployments.For more detailed information about each component and various ways to configure your cluster architecture, see the Cluster Architecture page.Items on this page refer to third party products or projects that provide functionality required by Kubernetes. The Kubernetes project authors aren't responsible for those third-party products or projects. See the CNCF website guidelines for more details.You should read the content guide before proposing a change that adds an extra third-party link.
# Delete a StatefulSet

Delete a StatefulSetThis task shows you how to delete a StatefulSet.Before you beginThis task assumes you have an application running on your cluster represented by a StatefulSet.Deleting a StatefulSetYou can delete a StatefulSet in the same way you delete other resources in Kubernetes: use the kubectl delete command, and specify the StatefulSet either by file or by name.kubectl delete -f <file.yaml> kubectl delete statefulsets <statefulset-name> You may need to delete the associated headless service separately after the StatefulSet itself is deleted.kubectl delete service <service-name> When deleting a StatefulSet through kubectl, the StatefulSet scales down to 0. All Pods that are part of this workload are also deleted. If you want to delete only the StatefulSet and not the Pods, use --cascade=orphan. For example:kubectl delete -f <file.yaml> --cascade=orphan By passing --cascade=orphan to kubectl delete, the Pods managed by the StatefulSet are left behind even after the StatefulSet object itself is deleted. If the pods have a label app.kubernetes.io/name=MyApp, you can then delete them as follows:kubectl delete pods -l app.kubernetes.io/name=MyApp Persistent VolumesDeleting the Pods in a StatefulSet will not delete the associated volumes. This is to ensure that you have the chance to copy data off the volume before deleting it. Deleting the PVC after the pods have terminated might trigger deletion of the backing Persistent Volumes depending on the storage class and reclaim policy. You should never assume ability to access a volume after claim deletion.Note:Use caution when deleting a PVC, as it may lead to data loss.Complete deletion of a StatefulSetTo delete everything in a StatefulSet, including the associated pods, you can run a series of commands similar to the following:grace=$(kubectl get pods <stateful-set-pod> --template '{{.spec.terminationGracePeriodSeconds}}') kubectl delete statefulset -l app.kubernetes.io/name=MyApp sleep $grace kubectl delete pvc -l app.kubernetes.io/name=MyApp In the example above, the Pods have the label app.kubernetes.io/name=MyApp; substitute your own label as appropriate.Force deletion of StatefulSet podsIf you find that some pods in your StatefulSet are stuck in the 'Terminating' or 'Unknown' states for an extended period of time, you may need to manually intervene to forcefully delete the pods from the apiserver. This is a potentially dangerous task. Refer to Force Delete StatefulSet Pods for details.What's nextLearn more about force deleting StatefulSet Pods.
# Metrics for Kubernetes Object States

Metrics for Kubernetes Object Stateskube-state-metrics, an add-on agent to generate and expose cluster-level metrics.The state of Kubernetes objects in the Kubernetes API can be exposed as metrics. An add-on agent called kube-state-metrics can connect to the Kubernetes API server and expose a HTTP endpoint with metrics generated from the state of individual objects in the cluster. It exposes various information about the state of objects like labels and annotations, startup and termination times, status or the phase the object currently is in. For example, containers running in pods create a kube_pod_container_info metric. This includes the name of the container, the name of the pod it is part of, the namespace the pod is running in, the name of the container image, the ID of the image, the image name from the spec of the container, the ID of the running container and the ID of the pod as labels.🛇 This item links to a third party project or product that is not part of Kubernetes itself. More informationAn external component that is able and capable to scrape the endpoint of kube-state-metrics (for example via Prometheus) can now be used to enable the following use cases.Example: using metrics from kube-state-metrics to query the cluster stateMetric series generated by kube-state-metrics are helpful to gather further insights into the cluster, as they can be used for querying.If you use Prometheus or another tool that uses the same query language, the following PromQL query returns the number of pods that are not ready:count(kube_pod_status_ready{condition="false"}) by (namespace, pod) Example: alerting based on from kube-state-metricsMetrics generated from kube-state-metrics also allow for alerting on issues in the cluster.If you use Prometheus or a similar tool that uses the same alert rule language, the following alert will fire if there are pods that have been in a Terminating state for more than 5 minutes:groups: - name: Pod state rules: - alert: PodsBlockedInTerminatingState expr: count(kube_pod_deletion_timestamp) by (namespace, pod) * count(kube_pod_status_reason{reason="NodeLost"} == 0) by (namespace, pod) > 0 for: 5m labels: severity: page annotations: summary: Pod {{$labels.namespace}}/{{$labels.pod}} blocked in Terminating state. Items on this page refer to third party products or projects that provide functionality required by Kubernetes. The Kubernetes project authors aren't responsible for those third-party products or projects. See the CNCF website guidelines for more details.You should read the content guide before proposing a change that adds an extra third-party link.
# Learn Kubernetes Basics

This is the multi-page printable view of this section. Click here to print.Return to the regular view of this page.Learn Kubernetes Basics1: Create a Cluster1.1: Using Minikube to Create a Cluster2: Deploy an App2.1: Using kubectl to Create a Deployment3: Explore Your App3.1: Viewing Pods and Nodes4: Expose Your App Publicly4.1: Using a Service to Expose Your App5: Scale Your App5.1: Running Multiple Instances of Your App6: Update Your App6.1: Performing a Rolling UpdateObjectivesThis tutorial provides a walkthrough of the basics of the Kubernetes cluster orchestration system. Each module contains some background information on major Kubernetes features and concepts, and a tutorial for you to follow along.Using the tutorials, you can learn to:Deploy a containerized application on a cluster.Scale the deployment.Update the containerized application with a new software version.Debug the containerized application.What can Kubernetes do for you?With modern web services, users expect applications to be available 24/7, and developers expect to deploy new versions of those applications several times a day. Containerization helps package software to serve these goals, enabling applications to be released and updated without downtime. Kubernetes helps you make sure those containerized applications run where and when you want, and helps them find the resources and tools they need to work. Kubernetes is a production-ready, open source platform designed with Google's accumulated experience in container orchestration, combined with best-of-breed ideas from the community.Kubernetes Basics Modules1. Create a Kubernetes cluster2. Deploy an app3. Explore your app4. Expose your app publicly5. Scale up your app6. Update your appWhat's
# Tutorials

This is the multi-page printable view of this section. Click here to print.Return to the regular view of this page.Tutorials1: Hello Minikube2: Learn Kubernetes Basics2.1: Create a Cluster2.1.1: Using Minikube to Create a Cluster2.2: Deploy an App2.2.1: Using kubectl to Create a Deployment2.3: Explore Your App2.3.1: Viewing Pods and Nodes2.4: Expose Your App Publicly2.4.1: Using a Service to Expose Your App2.5: Scale Your App2.5.1: Running Multiple Instances of Your App2.6: Update Your App2.6.1: Performing a Rolling Update3: Configuration3.1: Updating Configuration via a ConfigMap3.2: Configuring Redis using a ConfigMap3.3: Adopting Sidecar Containers4: Security4.1: Apply Pod Security Standards at the Cluster Level4.2: Apply Pod Security Standards at the Namespace Level4.3: Restrict a Container's Access to Resources with AppArmor4.4: Restrict a Container's Syscalls with seccomp5: Stateless Applications5.1: Exposing an External IP Address to Access an Application in a Cluster5.2: Example: Deploying PHP Guestbook application with Redis6: Stateful Applications6.1: StatefulSet Basics6.2: Example: Deploying WordPress and MySQL with Persistent Volumes6.3: Example: Deploying Cassandra with a StatefulSet6.4: Running ZooKeeper, A Distributed System Coordinator7: Cluster Management7.1: Running Kubelet in Standalone Mode7.2: Configuring swap memory on Kubernetes nodes7.3: Install Drivers and Allocate Devices with DRA7.4: Namespaces Walkthrough8: Services8.1: Connecting Applications with Services8.2: Using Source IP8.3: Explore Termination Behavior for Pods And Their EndpointsThis section of the Kubernetes documentation contains tutorials. A tutorial shows how to accomplish a goal that is larger than a single task. Typically a tutorial has several sections, each of which has a sequence of steps. Before walking through each tutorial, you may want to bookmark the Standardized Glossary page for later references.BasicsKubernetes Basics is an in-depth interactive tutorial that helps you understand the Kubernetes system and try out some basic Kubernetes features.Introduction to Kubernetes (edX)Hello MinikubeConfigurationConfiguring Redis Using a ConfigMapAuthoring PodsAdopting Sidecar ContainersStateless ApplicationsExposing an External IP Address to Access an Application in a ClusterExample: Deploying PHP Guestbook application with RedisStateful ApplicationsStatefulSet BasicsExample: WordPress and MySQL with Persistent VolumesExample: Deploying Cassandra with Stateful SetsRunning ZooKeeper, A CP Distributed SystemServicesConnecting Applications with ServicesUsing Source IPSecurityApply Pod Security Standards at Cluster levelApply Pod Security Standards at Namespace levelRestrict a Container's Access to Resources with AppArmorSeccompCluster ManagementConfiguring Swap Memory on Kubernetes NodesRunning Kubelet in Standalone ModeInstall Drivers and Allocate Devices with DRAWhat's