<button id="desktopShowVideoButton" onclick="kub.showVideo()">Watch Video</button>

  Attend KubeCon NA virtually on November 17-20, 2020   Attend KubeCon North America on October 11-15, 2021

  Attend KubeCon EU virtually on May 4 – 7, 2021   Revisit KubeCon EU 2021


{{< blocks/kubernetes-features >}} <del> {{< blocks/case-studies >}} </del>  No newline at end of file <ins> {{< blocks/case-studies >}} </ins>


`ContainerDevices` do expose the topology information declaring to which NUMA cells the device is affine. The NUMA cells are identified using a opaque integer ID, which value is consistent to what device <del> plugins report [when they register themselves to the kubelet](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-integration-with-the-topology-manager). </del> <ins> plugins report [when they register themselves to the kubelet](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-integration-with-the-topology-manager). </ins> The gRPC service is served over a unix socket at `/var/lib/kubelet/pod-resources/kubelet.sock`.


of cluster (node) autoscaling may cause voluntary disruptions to defragment and compact nodes. Your cluster administrator or hosting provider should have documented what level of voluntary disruptions, if any, to expect. Certain configuration options, such as <del> [using PriorityClasses](https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/) </del> <ins> [using PriorityClasses](/docs/concepts/configuration/pod-priority-preemption/) </ins> in your pod spec can also cause voluntary (and involuntary) disruptions.


resources. The scheduler then ranks each valid Node and binds the Pod to a suitable Node. Multiple different schedulers may be used within a cluster; kube-scheduler is the reference implementation. <del> See [scheduling](https://kubernetes.io/docs/concepts/scheduling-eviction/) </del> <ins> See [scheduling](/docs/concepts/scheduling-eviction/) </ins> for more information about scheduling and the kube-scheduler component. ```


## {{% heading "whatsnext" %}} <del> * Read the [kube-scheduler reference](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/) </del> <ins> * Read the [kube-scheduler reference](/docs/reference/command-line-tools-reference/kube-scheduler/) </ins> * Learn about [scheduling](/docs/concepts/scheduling-eviction/kube-scheduler/) * Read the [kube-scheduler configuration (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) reference


Generates keys and certificate signing requests (CSRs) for all the certificates required to run the control plane. This command also generates partial kubeconfig files with private key data in the  "users > user > client-key-data" field, and for each kubeconfig file an accompanying ".csr" file is created. <del> This command is designed for use in [Kubeadm External CA Mode](https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/#external-ca-mode). It generates CSRs which you can then submit to your external certificate authority for signing. </del> <ins> This command is designed for use in [Kubeadm External CA Mode](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/#external-ca-mode). It generates CSRs which you can then submit to your external certificate authority for signing. </ins> The PEM encoded signed certificates should then be saved alongside the key files, using ".crt" as the file extension, or in the case of kubeconfig files, the PEM encoded signed certificate should be base64 encoded and added to the kubeconfig file in the "users > user > client-certificate-data" field.


PodSecurityPolicy in the **policy/v1beta1** API version will no longer be served in v1.25, and the PodSecurityPolicy admission controller will be removed. PodSecurityPolicy replacements are still under discussion, but current use can be migrated to <del> [3rd-party admission webhooks](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) now. </del> <ins> [3rd-party admission webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/) now. </ins> #### RuntimeClass {#runtimeclass-v125}


* start and configure additional etcd instance * configure the {{< glossary_tooltip term_id="kube-apiserver" text="API server" >}} to use it for storing events <del> See [Operating etcd clusters for Kubernetes](https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/) and [Set up a High Availability etcd cluster with kubeadm](docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) </del> <ins> See [Operating etcd clusters for Kubernetes](/docs/tasks/administer-cluster/configure-upgrade-etcd/) and [Set up a High Availability etcd cluster with kubeadm](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) </ins> for details on configuring and managing etcd for a large cluster. ## Addon resources


security mechanisms to make sure that users and workloads can get access to the resources they need, while keeping workloads, and the cluster itself, secure. You can set limits on the resources that users and workloads can access <del> by managing [policies](https://kubernetes.io/docs/concepts/policy/) and </del> <ins> by managing [policies](/docs/concepts/policy/) and </ins> [container resources](/docs/concepts/configuration/manage-resources-containers/). Before building a Kubernetes production environment on your own, consider


deployment methods. - Configure user management by determining your [Authentication](/docs/reference/access-authn-authz/authentication/) and <del> [Authorization](docs/reference/access-authn-authz/authorization/) methods. </del> <ins> [Authorization](/docs/reference/access-authn-authz/authorization/) methods. </ins> - Prepare for application workloads by setting up <del> [resource limits](docs/tasks/administer-cluster/manage-resources/), </del> <ins> [resource limits](/docs/tasks/administer-cluster/manage-resources/), </ins> [DNS autoscaling](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/) and [service accounts](/docs/reference/access-authn-authz/service-accounts-admin/).


certificates by requesting them from the `certificates.k8s.io` API. One known limitation is that the CSRs (Certificate Signing Requests) for these certificates cannot be automatically approved by the default signer in the kube-controller-manager - <del> [`kubernetes.io/kubelet-serving`](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers). </del> <ins> [`kubernetes.io/kubelet-serving`](/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers). </ins> This will require action from the user or a third party controller. These CSRs can be viewed using:


 ## `LoggingConfiguration`     {#LoggingConfiguration} **Appears in:** - [KubeletConfiguration](#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) LoggingConfiguration contains logging options Refer [Logs Options](https://github.com/kubernetes/component-base/blob/master/logs/options.go) for more information.

Field	Description

format [Required]
 string 	  Format Flag specifies the structure of log messages. default value of format is `text`

sanitization [Required]
 bool 	  [Experimental] When enabled prevents logging of fields tagged as sensitive (passwords, keys, tokens). Runtime log sanitization may introduce significant computation overhead and therefore should not be enabled in production.`)</td> </tr> </tbody> </table> </ins> ## `KubeletConfiguration`     {#kubelet-config-k8s-io-v1beta1-KubeletConfiguration}


status to master if node status does not change. Kubelet will ignore this frequency and post node status immediately if any change is detected. It is only used when node lease feature is enabled. nodeStatusReportFrequency's  default value is 1m. But if nodeStatusUpdateFrequency is set explicitly,   default value is 5m. But if nodeStatusUpdateFrequency is set explicitly,  nodeStatusReportFrequency's default value will be set to nodeStatusUpdateFrequency for backward compatibility.  Default: "1m"	   Default: "5m"


Requires the CPUManager feature gate to be enabled. Dynamic Kubelet Config (beta): This field should not be updated without a full node reboot. It is safest to keep this value the same as the local config.  Default: "none"	   Default: "None"


memoryManagerPolicy
 string 	  MemoryManagerPolicy is the name of the policy to use by memory manager. Requires the MemoryManager feature gate to be enabled. Dynamic Kubelet Config (beta): This field should not be updated without a full node reboot. It is safest to keep this value the same as the local config. Default: "none"

topologyManagerPolicy
 string


ShutdownGracePeriod specifies the total duration that the node should delay the shutdown and total grace period for pod termination during a node shutdown.  Default: "30s"	   Default: "0s"


 ShutdownGracePeriodCriticalPods specifies the duration used to terminate critical pods during a node shutdown. This should be less than ShutdownGracePeriod. For example, if ShutdownGracePeriod=30s, and ShutdownGracePeriodCriticalPods=10s, during a node shutdown the first 20 seconds would be reserved for gracefully terminating normal pods, and the last 10 seconds would be reserved for terminating critical pods.  Default: "10s"	   Default: "0s"

reservedMemory
 []MemoryReservation 	  ReservedMemory specifies a comma-separated list of memory reservations for NUMA nodes. The parameter makes sense only in the context of the memory manager feature. The memory manager will not allocate reserved memory for container workloads. For example, if you have a NUMA0 with 10Gi of memory and the ReservedMemory was specified to reserve 1Gi of memory at NUMA0, the memory manager will assume that only 9Gi is available for allocation. You can specify a different amount of NUMA node and memory types. You can omit this parameter at all, but you should be aware that the amount of reserved memory from all NUMA nodes should be equal to the amount of memory specified by the node allocatable features(https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable). If at least one node allocatable parameter has a non-zero value, you will need to specify at least one NUMA node. Also, avoid specifying: 1. Duplicates, the same NUMA node, and memory type, but with a different value. 2. zero limits for any memory type. 3. NUMAs nodes IDs that do not exist under the machine. 4. memory types except for memory and hugepages-<size> Default: nil

enableProfilingHandler
 bool 	  enableProfilingHandler enables profiling via web interface host:port/debug/pprof/ Default: true

enableDebugFlagsHandler
 bool 	  enableDebugFlagsHandler enables flags endpoint via web interface host:port/debug/flags/v Default: true


<del> ## `ResourceChangeDetectionStrategy`     {#kubelet-config-k8s-io-v1beta1-ResourceChangeDetectionStrategy} (Alias of `string`) **Appears in:** - [KubeletConfiguration](#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) ResourceChangeDetectionStrategy denotes a mode in which internal managers (secret, configmap) are discovering object changes. ## `LoggingConfiguration`     {#LoggingConfiguration} </del> <ins> ## `MemoryReservation`     {#kubelet-config-k8s-io-v1beta1-MemoryReservation} </ins>


- [KubeletConfiguration](#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)  LoggingConfiguration contains logging options Refer [Logs Options](https://github.com/kubernetes/component-base/blob/master/logs/options.go) for more information.   MemoryReservation specifies the memory reservation of different types for each NUMA node

Field	Description


format [Required]
 string
numaNode [Required]
 int32  	   Format Flag specifies the structure of log messages. default value of format is `text`	   No description provided.

sanitization [Required]
 bool
limits [Required]
 core/v1.ResourceList  	   [Experimental] When enabled prevents logging of fields tagged as sensitive (passwords, keys, tokens). Runtime log sanitization may introduce significant computation overhead and therefore should not be enabled in production.`)</td> </del> <ins> <span class="text-muted">No description provided.</span> </td> </ins> </tr> </tbody> </table> <ins> ## `ResourceChangeDetectionStrategy`     {#kubelet-config-k8s-io-v1beta1-ResourceChangeDetectionStrategy} (Alias of `string`) **Appears in:** - [KubeletConfiguration](#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) ResourceChangeDetectionStrategy denotes a mode in which internal managers (secret, configmap) are discovering object changes.


{{ $show := cond (or (lt $ulNr $ulShow) $activePath (and (not $shouldDelayActive) (eq $s.Parent $p.Parent)) (and (not $shouldDelayActive) (eq $s.Parent $p)) (and (not $shouldDelayActive) ($p.IsDescendant $s.Parent))) true false -}} {{ $mid := printf "m-%s" ($s.RelPermalink | anchorize) -}} {{ $pages_tmp := where (union $s.Pages $s.Sections).ByWeight ".Params.toc_hide" "!=" true -}} <ins> {{/* We get untranslated subpages below to make sure we build all levels of the sidenav in localizationed docs sets */}} {{ with site.Params.language_alternatives -}} {{ range . }} {{ with (where $.section.Translations ".Lang" . ) -}} {{ $p := index . 0 -}} {{ $pages_tmp = where ( $pages_tmp | lang.Merge (union $p.Pages $p.Sections)) ".Params.toc_hide" "!=" true -}} {{ end -}} {{ end -}} {{ end -}} </ins> {{ $pages := $pages_tmp | first $sidebarMenuTruncate -}} {{ $withChild := gt (len $pages) 0 -}} {{ $manualLink := cond (isset $s.Params "manuallink") $s.Params.manualLink ( cond (isset $s.Params "manuallinkrelref") (relref $s $s.Params.manualLinkRelref) $s.RelPermalink) -}}


<del> --- reviewers: - rickypai - thockin title: Adding entries to Pod /etc/hosts with HostAliases content_type: concept weight: 60 min-kubernetes-server-version: 1.7 --- <!-- overview --> Adding entries to a Pod's `/etc/hosts` file provides Pod-level override of hostname resolution when DNS and other options are not applicable. You can add these custom entries with the HostAliases field in PodSpec. Modification not using HostAliases is not suggested because the file is managed by the kubelet and can be overwritten on during Pod creation/restart. <!-- body --> ## Default hosts file content Start an Nginx Pod which is assigned a Pod IP: ```shell kubectl run nginx --image nginx ``` ``` pod/nginx created ``` Examine a Pod IP: ```shell kubectl get pods --output=wide ``` ``` NAME     READY     STATUS    RESTARTS   AGE    IP           NODE nginx    1/1       Running   0          13s    10.200.0.4   worker0 ``` The hosts file content would look like this: ```shell kubectl exec nginx -- cat /etc/hosts ``` ``` # Kubernetes-managed hosts file. 127.0.0.1	localhost ::1	localhost ip6-localhost ip6-loopback fe00::0	ip6-localnet fe00::0	ip6-mcastprefix fe00::1	ip6-allnodes fe00::2	ip6-allrouters 10.200.0.4	nginx ``` By default, the `hosts` file only includes IPv4 and IPv6 boilerplates like `localhost` and its own hostname. ## Adding additional entries with hostAliases In addition to the default boilerplate, you can add additional entries to the `hosts` file. For example: to resolve `foo.local`, `bar.local` to `127.0.0.1` and `foo.remote`, `bar.remote` to `10.1.2.3`, you can configure HostAliases for a Pod under `.spec.hostAliases`: {{< codenew file="service/networking/hostaliases-pod.yaml" >}} You can start a Pod with that configuration by running: ```shell kubectl apply -f https://k8s.io/examples/service/networking/hostaliases-pod.yaml ``` ``` pod/hostaliases-pod created ``` Examine a Pod's details to see its IPv4 address and its status: ```shell kubectl get pod --output=wide ``` ``` NAME                           READY     STATUS      RESTARTS   AGE       IP              NODE hostaliases-pod                0/1       Completed   0          6s        10.200.0.5      worker0 ``` The `hosts` file content looks like this: ```shell kubectl logs hostaliases-pod ``` ``` # Kubernetes-managed hosts file. 127.0.0.1	localhost ::1	localhost ip6-localhost ip6-loopback fe00::0	ip6-localnet fe00::0	ip6-mcastprefix fe00::1	ip6-allnodes fe00::2	ip6-allrouters 10.200.0.5	hostaliases-pod # Entries added by HostAliases. 127.0.0.1	foo.local	bar.local 10.1.2.3	foo.remote	bar.remote ``` with the additional entries specified at the bottom. ## Why does the kubelet manage the hosts file? {#why-does-kubelet-manage-the-hosts-file} The kubelet [manages](https://github.com/kubernetes/kubernetes/issues/14633) the `hosts` file for each container of the Pod to prevent Docker from [modifying](https://github.com/moby/moby/issues/17190) the file after the containers have already been started. {{< caution >}} Avoid making manual changes to the hosts file inside a container. If you make manual changes to the hosts file, those changes are lost when the container exits. {{< /caution >}} </del>


<ins> --- reviewers: - rickypai - thockin title: Adding entries to Pod /etc/hosts with HostAliases content_type: task weight: 60 min-kubernetes-server-version: 1.7 --- <!-- overview --> Adding entries to a Pod's `/etc/hosts` file provides Pod-level override of hostname resolution when DNS and other options are not applicable. You can add these custom entries with the HostAliases field in PodSpec. Modification not using HostAliases is not suggested because the file is managed by the kubelet and can be overwritten on during Pod creation/restart. <!-- steps --> ## Default hosts file content Start an Nginx Pod which is assigned a Pod IP: ```shell kubectl run nginx --image nginx ``` ``` pod/nginx created ``` Examine a Pod IP: ```shell kubectl get pods --output=wide ``` ``` NAME     READY     STATUS    RESTARTS   AGE    IP           NODE nginx    1/1       Running   0          13s    10.200.0.4   worker0 ``` The hosts file content would look like this: ```shell kubectl exec nginx -- cat /etc/hosts ``` ``` # Kubernetes-managed hosts file. 127.0.0.1	localhost ::1	localhost ip6-localhost ip6-loopback fe00::0	ip6-localnet fe00::0	ip6-mcastprefix fe00::1	ip6-allnodes fe00::2	ip6-allrouters 10.200.0.4	nginx ``` By default, the `hosts` file only includes IPv4 and IPv6 boilerplates like `localhost` and its own hostname. ## Adding additional entries with hostAliases In addition to the default boilerplate, you can add additional entries to the `hosts` file. For example: to resolve `foo.local`, `bar.local` to `127.0.0.1` and `foo.remote`, `bar.remote` to `10.1.2.3`, you can configure HostAliases for a Pod under `.spec.hostAliases`: {{< codenew file="service/networking/hostaliases-pod.yaml" >}} You can start a Pod with that configuration by running: ```shell kubectl apply -f https://k8s.io/examples/service/networking/hostaliases-pod.yaml ``` ``` pod/hostaliases-pod created ``` Examine a Pod's details to see its IPv4 address and its status: ```shell kubectl get pod --output=wide ``` ``` NAME                           READY     STATUS      RESTARTS   AGE       IP              NODE hostaliases-pod                0/1       Completed   0          6s        10.200.0.5      worker0 ``` The `hosts` file content looks like this: ```shell kubectl logs hostaliases-pod ``` ``` # Kubernetes-managed hosts file. 127.0.0.1	localhost ::1	localhost ip6-localhost ip6-loopback fe00::0	ip6-localnet fe00::0	ip6-mcastprefix fe00::1	ip6-allnodes fe00::2	ip6-allrouters 10.200.0.5	hostaliases-pod # Entries added by HostAliases. 127.0.0.1	foo.local	bar.local 10.1.2.3	foo.remote	bar.remote ``` with the additional entries specified at the bottom. ## Why does the kubelet manage the hosts file? {#why-does-kubelet-manage-the-hosts-file} The kubelet [manages](https://github.com/kubernetes/kubernetes/issues/14633) the `hosts` file for each container of the Pod to prevent Docker from [modifying](https://github.com/moby/moby/issues/17190) the file after the containers have already been started. {{< caution >}} Avoid making manual changes to the hosts file inside a container. If you make manual changes to the hosts file, those changes are lost when the container exits. {{< /caution >}} </ins>


/docs/concepts/scheduling-eviction/eviction-policy/     /docs/concepts/scheduling-eviction/node-pressure-eviction/ 301 /docs/concepts/service-catalog/     /docs/concepts/extend-kubernetes/service-catalog/ 301 /docs/concepts/services-networking/networkpolicies/     /docs/concepts/services-networking/network-policies/ 301 <ins> /docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases/     /docs/tasks/network/customize-hosts-file-for-pods/ 301 </ins> /docs/concepts/storage/etcd-store-api-object/     /docs/tasks/administer-cluster/configure-upgrade-etcd/ 301 /docs/concepts/storage/volumes/emptyDirapiVersion/     /docs/concepts/storage/volumes/#emptydir/ 301 /docs/concepts/tools/kubectl/object-management-overview/     /docs/concepts/overview/object-management-kubectl/overview/ 301


* [AppArmor](/docs/tutorials/clusters/apparmor/): Use program profiles to restrict the capabilities of individual programs. <del> * [Seccomp](https://en.wikipedia.org/wiki/Seccomp): Filter a process's system calls. </del> <ins> * [Seccomp](/docs/tutorials/clusters/seccomp/): Filter a process's system calls. </ins> * AllowPrivilegeEscalation: Controls whether a process can gain more privileges than its parent process. This bool directly controls whether the [`no_new_privs`](https://www.kernel.org/doc/Documentation/prctl/no_new_privs.txt) flag gets set on the container process. AllowPrivilegeEscalation is true always when the container is: 1) run as Privileged OR 2) has `CAP_SYS_ADMIN`.


### Stable Storage <del> Kubernetes creates one [PersistentVolume](/docs/concepts/storage/persistent-volumes/) for each VolumeClaimTemplate. In the nginx example above, each Pod will receive a single PersistentVolume with a StorageClass of `my-storage-class` and 1 Gib of provisioned storage. If no StorageClass </del> <ins> For each VolumeClaimTemplate entry defined in a StatefulSet, each Pod receives one PersistentVolumeClaim. In the nginx example above, each Podreceives a single PersistentVolume with a StorageClass of `my-storage-class` and 1 Gib of provisioned storage. If no StorageClass </ins> is specified, then the default StorageClass will be used. When a Pod is (re)scheduled onto a node, its `volumeMounts` mount the PersistentVolumes associated with its PersistentVolume Claims. Note that, the PersistentVolumes associated with the


{{/* We cache this partial for bigger sites and set the active class client side. */}}  {{ $sidebarCacheLimit := cond (isset .Site.Params.ui "sidebar_cache_limit") .Site.Params.ui.sidebar_cache_limit 2000 }} {{ $shouldDelayActive := ge (len .Site.Pages) $sidebarCacheLimit }}   {{ $sidebarCacheLimit := cond (isset .Site.Params.ui "sidebar_cache_limit") .Site.Params.ui.sidebar_cache_limit 2000 -}} {{ $shouldDelayActive := ge (len .Site.Pages) $sidebarCacheLimit -}}
  {{ if not .Site.Params.ui.sidebar_search_disable }}   {{ if not .Site.Params.ui.sidebar_search_disable -}}  <form class="td-sidebar__search d-flex align-items-center"> {{ partial "search-input.html" . }} <button class="btn btn-link td-sidebar__toggle d-md-none p-0 ml-3 fas fa-bars" type="button" data-toggle="collapse" data-target="#td-section-nav" aria-controls="td-docs-nav" aria-expanded="false" aria-label="Toggle section navigation"> </button> </form>  {{ else }}   {{ else -}}
 <form class="td-sidebar__search d-flex align-items-center"> {{ partial "search-input.html" . }}


</form>

  {{ end }}   {{ end -}}


 {{ end }} -->   {{ $ulNr := 0 }} {{ $ulShow := cond (isset .Site.Params.ui "ul_show") .Site.Params.ui.ul_show 1 }} {{ $sidebarMenuTruncate := cond (isset .Site.Params.ui "sidebar_menu_truncate") .Site.Params.ui.sidebar_menu_truncate 50 }} {{ $currentLang := .Site.Language }}   {{ $ulNr := 0 -}} {{ $ulShow := cond (isset .Site.Params.ui "ul_show") .Site.Params.ui.ul_show 1 -}} {{ $sidebarMenuTruncate := cond (isset .Site.Params.ui "sidebar_menu_truncate") .Site.Params.ui.sidebar_menu_truncate 50 -}} {{ $currentLang := .Site.Language -}}
 {{ template "section-tree-nav-section" (dict "page" . "section" .FirstSection "shouldDelayActive" $shouldDelayActive "sidebarMenuTruncate" $sidebarMenuTruncate "ulNr" $ulNr "ulShow" (add $ulShow 1) "currentLang" $currentLang)  }}

  {{ define "section-tree-nav-section" }} {{ $s := .section }} {{ $p := .page }} {{ $shouldDelayActive := .shouldDelayActive }} {{ $sidebarMenuTruncate := .sidebarMenuTruncate }} {{ $treeRoot := cond (eq .ulNr 0) true false }} {{ $ulNr := .ulNr }} {{ $ulShow := .ulShow }} {{ $active := and (not $shouldDelayActive) (eq $s $p) }} {{ $activePath := and (not $shouldDelayActive) ($p.IsDescendant $s) }} {{ $show := cond (or (lt $ulNr $ulShow) $activePath (and (not $shouldDelayActive) (eq $s.Parent $p.Parent)) (and (not $shouldDelayActive) (eq $s.Parent $p)) (and (not $shouldDelayActive) ($p.IsDescendant $s.Parent))) true false }} {{ $mid := printf "m-%s" ($s.RelPermalink | anchorize) }} {{ $pages_tmp := where (union $s.Pages $s.Sections).ByWeight ".Params.toc_hide" "!=" true }} {{ $pages := $pages_tmp | first $sidebarMenuTruncate }} {{ $withChild := gt (len $pages) 0 }} {{ $manualLink := cond (isset $s.Params "manuallink") $s.Params.manualLink ( cond (isset $s.Params "manuallinkrelref") (relref $s $s.Params.manualLinkRelref) $s.RelPermalink) }} {{ $manualLinkTitle := cond (isset $s.Params "manuallinktitle") $s.Params.manualLinkTitle $s.Title }}   {{ define "section-tree-nav-section" -}} {{ $s := .section -}} {{ $p := .page -}} {{ $shouldDelayActive := .shouldDelayActive -}} {{ $sidebarMenuTruncate := .sidebarMenuTruncate -}} {{ $treeRoot := cond (eq .ulNr 0) true false -}} {{ $ulNr := .ulNr -}} {{ $ulShow := .ulShow -}} {{ $active := and (not $shouldDelayActive) (eq $s $p) -}} {{ $activePath := and (not $shouldDelayActive) ($p.IsDescendant $s) -}} {{ $show := cond (or (lt $ulNr $ulShow) $activePath (and (not $shouldDelayActive) (eq $s.Parent $p.Parent)) (and (not $shouldDelayActive) (eq $s.Parent $p)) (and (not $shouldDelayActive) ($p.IsDescendant $s.Parent))) true false -}} {{ $mid := printf "m-%s" ($s.RelPermalink | anchorize) -}} {{ $pages_tmp := where (union $s.Pages $s.Sections).ByWeight ".Params.toc_hide" "!=" true -}} {{ $pages := $pages_tmp | first $sidebarMenuTruncate -}} {{ $withChild := gt (len $pages) 0 -}} {{ $manualLink := cond (isset $s.Params "manuallink") $s.Params.manualLink ( cond (isset $s.Params "manuallinkrelref") (relref $s $s.Params.manualLinkRelref) $s.RelPermalink) -}} {{ $manualLinkTitle := cond (isset $s.Params "manuallinktitle") $s.Params.manualLinkTitle $s.Title -}}
  {{ if (and $p.Site.Params.ui.sidebar_menu_foldable (ge $ulNr 1)) }}   {{ if (and $p.Site.Params.ui.sidebar_menu_foldable (ge $ulNr 1)) -}}  <input type="checkbox" id="{{ $mid }}-check"{{ if $activePath}} checked{{ end }}/> {{ with $s.Params.Icon}}{{ end }}{{ $s.LinkTitle }}  {{ else }}   {{ else -}}  {{ if not $treeRoot }} {{ with $s.Params.Icon}}{{ end }}{{ $s.LinkTitle }}  {{ end }} {{ end }} {{if $withChild }} {{ $ulNr := add $ulNr 1 }}   {{ end -}} {{ end -}} {{ if $withChild -}} {{ $ulNr := add $ulNr 1 -}}
  {{ $pages := where (union $s.Pages $s.Sections).ByWeight ".Params.toc_hide" "!=" true }} {{ with site.Params.language_alternatives }}   {{ $pages := where (union $s.Pages $s.Sections).ByWeight ".Params.toc_hide" "!=" true -}} {{ with site.Params.language_alternatives -}}  {{ range . }}  {{ with (where $.section.Translations ".Lang" . ) }} {{ $p := index . 0 }} {{ $pages =  $pages | lang.Merge (union $p.Pages $p.Sections) }} {{ end }} {{ end }} {{ end }} {{ $pages := $pages | first 50 }} {{ range $pages }} {{ if (not (and (eq $s $p.Site.Home) (eq .Params.toc_root true)) ) }} {{ $mid := printf "m-%s" (.RelPermalink | anchorize) }} {{ $active := eq . $p }} {{ $isForeignLanguage := (ne (string .Lang) (string $.currentLang)) }} {{ if (and $isForeignLanguage  ($p.IsDescendant $s)) }}   {{ with (where $.section.Translations ".Lang" . ) -}} {{ $p := index . 0 -}} {{ $pages =  $pages | lang.Merge (union $p.Pages $p.Sections) -}} {{ end -}} {{ end -}} {{ end -}} {{ $pages := $pages | first 50 -}} {{ range $pages -}} {{ if (not (and (eq $s $p.Site.Home) (eq .Params.toc_root true)) ) -}} {{ $mid := printf "m-%s" (.RelPermalink | anchorize) -}} {{ $active := eq . $p -}} {{ $isForeignLanguage := (ne (string .Lang) (string $.currentLang)) -}} {{ if (and $isForeignLanguage  ($p.IsDescendant $s)) -}}    {{ .LinkTitle }}{{ if $isForeignLanguage }} ({{ .Lang | upper }}){{ end }}   {{ .LinkTitle }}{{ if $isForeignLanguage }} ({{ .Lang | upper }}){{ end -}}    {{ else }}   {{ else -}}  {{ template "section-tree-nav-section" (dict "page" $p "section" . "currentLang" $.currentLang "shouldDelayActive" $shouldDelayActive "sidebarMenuTruncate" $sidebarMenuTruncate "ulNr" $ulNr "ulShow" $ulShow) }}  {{ end }} {{ end }} {{ end }}   {{- end }} {{- end }} {{- end }}
  {{ end }}   {{- end }}
  {{ end }}   {{- end }}


<!-- overview --> <img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px">This page shows how to install the `kubeadm` toolbox. <del> For information how to create a cluster with kubeadm once you have performed this installation process, see the [Using kubeadm to Create a Cluster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) page. </del> <ins> For information on how to create a cluster with kubeadm once you have performed this installation process, see the [Using kubeadm to Create a Cluster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) page. </ins>


<!-- overview --> <del> {{< feature-state for_k8s_version="v1.16" state="beta" >}} </del> <ins> {{< feature-state for_k8s_version="v1.22" state="stable" >}} </ins> ## Introduction


and direct the network traffic to the cluster nodes: 1. Make sure that <del> the `ServiceAccountTokenVolumeProjection` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled. You can enable [service account token volume protection](/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection) by providing the following flags to the kube-apiserver: ``` --service-account-issuer=api --service-account-signing-key-file=/etc/kubernetes/pki/sa.key --api-audiences=system:konnectivity-server ``` </del> <ins> [Service Account Token Volume Projection](/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection) feature enabled in your cluster. It is enabled by default since Kubernetes v1.20. </ins> 1. Create an egress configuration file such as `admin/konnectivity/egress-selector-configuration.yaml`. 1. Set the `--egress-selector-config-file` flag of the API Server to the path of your API Server egress configuration file.


} body { <del> display: grid; grid-column-template: auto; </del> header + .td-outer { min-height: 50vh; height: auto;


There are two types of provisioners for vSphere storage classes: <del> - [CSI provisioner](#csi-provisioner): `csi.vsphere.vmware.com` </del> <ins> - [CSI provisioner](#vsphere-provisioner-csi): `csi.vsphere.vmware.com` </ins> - [vCP provisioner](#vcp-provisioner): `kubernetes.io/vsphere-volume` In-tree provisioners are [deprecated](/blog/2019/12/09/kubernetes-1-17-feature-csi-migration-beta/#why-are-we-migrating-in-tree-plugins-to-csi). For more information on the CSI provisioner, see [Kubernetes vSphere CSI Driver](https://vsphere-csi-driver.sigs.k8s.io/) and [vSphereVolume CSI migration](/docs/concepts/storage/volumes/#csi-migration-5). #### CSI Provisioner {#vsphere-provisioner-csi} <del> The vSphere CSI StorageClass provisioner works with Tanzu Kubernetes clusters. For an example, refer to the [vSphere CSI repository](https://raw.githubusercontent.com/kubernetes-sigs/vsphere-csi-driver/master/example/vanilla-k8s-file-driver/example-sc.yaml). </del> <ins> The vSphere CSI StorageClass provisioner works with Tanzu Kubernetes clusters. For an example, refer to the [vSphere CSI repository](https://github.com/kubernetes-sigs/vsphere-csi-driver/blob/master/example/vanilla-k8s-RWM-filesystem-volumes/example-sc.yaml). </ins> #### vCP Provisioner


Used on: Namespaces <del> When the `NamespaceDefaultLabelName` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled, the Kubernetes API server sets this label on all namespaces. The label value is set to the name of the namespace. </del> <ins> The Kubernetes API server (part of the {{< glossary_tooltip text="control plane" term_id="control-plane" >}}) sets this label on all namespaces. The label value is set to the name of the namespace. You can't change this label's value. </ins> This is useful if you want to target a specific namespace with a label {{< glossary_tooltip text="selector" term_id="selector" >}}.


- Using PowerShell to automate the verification using the `-eq` operator to get a `True` or `False` result: ```powershell <del> $($(CertUtil -hashfile .kubectl.exe SHA256)[1] -replace " ", "") -eq $(type .kubectl.exe.sha256) </del> <ins> $(Get-FileHash -Algorithm SHA256 .kubectl.exe).Hash -eq $(Get-Content .kubectl.exe.sha256) </ins> ``` 1. Append or prepend the `kubectl` binary folder to your `PATH` environment variable.


## Accessing services running on the cluster <del> The previous section describes how to connect to the Kubernetes API server. For information about connecting to other services running on a Kubernetes cluster, see [Access Cluster Services.](/docs/tasks/access-application-cluster/access-cluster/) </del> <ins> The previous section describes how to connect to the Kubernetes API server. For information about connecting to other services running on a Kubernetes cluster, see [Access Cluster Services.](/docs/tasks/administer-cluster/access-cluster-services/) </ins> ## Requesting redirects


[downward API](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/). User defined environment variables from the Pod definition are also available to the Container, <del> as are any environment variables specified statically in the Docker image. </del> <ins> as are any environment variables specified statically in the container image. </ins> ### Cluster information A list of all services that were running when a Container was created is available to that Container as environment variables. This list is limited to services within the same namespace as the new Container's Pod and Kubernetes control plane services. <del> Those environment variables match the syntax of Docker links. </del> For a service named *foo* that maps to a Container named *bar*, the following variables are defined:


what that means, check out the blog post [Don't Panic: Kubernetes and Docker](/blog/2020/12/02/dont-panic-kubernetes-and-docker/). <ins> Also, you can read [check whether Dockershim deprecation affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/) to check whether it does. </ins> ### Why is dockershim being deprecated? Maintaining dockershim has become a heavy burden on the Kubernetes maintainers.


are being moved to the [Tasks](/docs/tasks/), [Tutorials](/docs/tutorials/), and [Concepts](/docs/concepts) sections. The content in this topic has moved to: --> <del> Kubernetes文档中[使用手册](/zh/docs/user-guide/)部分中的主题被移动到 </del> <ins> Kubernetes文档中[用户指南](/zh/docs/user-guide/)部分中的主题被移动到 </ins> [任务](/zh/docs/tasks/)、[教程](/zh/docs/tutorials/)和[概念](/zh/docs/concepts)节。 本主题内容已移至:


<ins> --- title: Podのオーバーヘッド content_type: concept weight: 30 --- <!-- overview --> {{< feature-state for_k8s_version="v1.18" state="beta" >}} PodをNode上で実行する時に、Pod自身は大量のシステムリソースを消費します。これらのリソースは、Pod内のコンテナ(群)を実行するために必要なリソースとして追加されます。Podのオーバーヘッドは、コンテナの要求と制限に加えて、Podのインフラストラクチャで消費されるリソースを計算するための機能です。 <!-- body --> Kubernetesでは、Podの[RuntimeClass](/docs/concepts/containers/runtime-class/)に関連するオーバーヘッドに応じて、[アドミッション](/ja/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks)時にPodのオーバーヘッドが設定されます。 Podのオーバーヘッドを有効にした場合、Podのスケジューリング時にコンテナのリソース要求の合計に加えて、オーバーヘッドも考慮されます。同様に、Kubeletは、Podのcgroupのサイズ決定時およびPodの退役の順位付け時に、Podのオーバーヘッドを含めます。 ## Podのオーバーヘッドの有効化　{#set-up} クラスター全体で`PodOverhead`の[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)が有効になっていること（1.18時点ではデフォルトでオンになっています）と、`overhead`フィールドを定義する`RuntimeClass`が利用されていることを確認する必要があります。 ## 使用例 Podのオーバーヘッド機能を使用するためには、`overhead`フィールドが定義されたRuntimeClassが必要です。例として、仮想マシンとゲストOSにPodあたり約120MiBを使用する仮想化コンテナランタイムで、次のようなRuntimeClassを定義できます。 ```yaml --- kind: RuntimeClass apiVersion: node.k8s.io/v1 metadata: name: kata-fc handler: kata-fc overhead: podFixed: memory: "120Mi" cpu: "250m" ``` `kata-fc`RuntimeClassハンドラーを指定して作成されたワークロードは、リソースクォータの計算や、Nodeのスケジューリング、およびPodのcgroupのサイズ決定にメモリーとCPUのオーバーヘッドが考慮されます。 次のtest-podのワークロードの例を実行するとします。 ```yaml apiVersion: v1 kind: Pod metadata: name: test-pod spec: runtimeClassName: kata-fc containers: - name: busybox-ctr image: busybox stdin: true tty: true resources: limits: cpu: 500m memory: 100Mi - name: nginx-ctr image: nginx resources: limits: cpu: 1500m memory: 100Mi ``` アドミッション時、RuntimeClass[アドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/)は、RuntimeClass内に記述された`オーバーヘッド`を含むようにワークロードのPodSpecを更新します。もし既にPodSpec内にこのフィールドが定義済みの場合、そのPodは拒否されます。この例では、RuntimeClassの名前しか指定されていないため、アドミッションコントローラーは`オーバーヘッド`を含むようにPodを変更します。 RuntimeClassのアドミッションコントローラーの後、更新されたPodSpecを確認できます。 ```bash kubectl get pod test-pod -o jsonpath='{.spec.overhead}' ``` 出力は次の通りです: ``` map[cpu:250m memory:120Mi] ``` ResourceQuotaが定義されている場合、コンテナ要求の合計と`オーバーヘッド`フィールドがカウントされます。 kube-schedulerが新しいPodを実行すべきNodeを決定する際、スケジューラーはそのPodの`オーバーヘッド`と、そのPodに対するコンテナ要求の合計を考慮します。この例だと、スケジューラーは、要求とオーバーヘッドを追加し、2.25CPUと320MiBのメモリを持つNodeを探します。 PodがNodeにスケジュールされると、そのNodeのkubeletはPodのために新しい{{< glossary_tooltip text="cgroup" term_id="cgroup" >}}を生成します。基盤となるコンテナランタイムがコンテナを作成するのは、このPod内です。 リソースにコンテナごとの制限が定義されている場合(制限が定義されているGuaranteed QoSまたはBustrable QoS)、kubeletはそのリソース(CPUはcpu.cfs_quota_us、メモリはmemory.limit_in_bytes)に関連するPodのcgroupの上限を設定します。この上限は、コンテナの制限とPodSpecで定義された`オーバーヘッド`の合計に基づきます。 CPUについては、PodがGuaranteedまたはBurstable QoSの場合、kubeletはコンテナの要求の合計とPodSpecに定義された`オーバーヘッド`に基づいて`cpu.share`を設定します。 次の例より、ワークロードに対するコンテナの要求を確認できます。 ```bash kubectl get pod test-pod -o jsonpath='{.spec.containers[*].resources.limits}' ``` コンテナの要求の合計は、CPUは2000m、メモリーは200MiBです。 ``` map[cpu: 500m memory:100Mi] map[cpu:1500m memory:100Mi] ``` Nodeで観測される値と比較してみましょう。 ```bash kubectl describe node | grep test-pod -B2 ``` 出力では、2250mのCPUと320MiBのメモリーが要求されており、Podのオーバーヘッドが含まれていることが分かります。 ``` Namespace                   Name                CPU Requests  CPU Limits   Memory Requests  Memory Limits  AGE ---------                   ----                ------------  ----------   ---------------  -------------  --- default                     test-pod            2250m (56%)   2250m (56%)  320Mi (1%)       320Mi (1%)     36m ``` ## Podのcgroupの制限を確認 ワークロードで実行中のNode上にある、Podのメモリーのcgroupを確認します。次に示す例では、CRI互換のコンテナランタイムのCLIを提供するNodeで[`crictl`](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md)を使用しています。これはPodのオーバーヘッドの動作を示すための高度な例であり、ユーザーがNode上で直接cgroupsを確認する必要はありません。 まず、特定のNodeで、Podの識別子を決定します。 ```bash # PodがスケジュールされているNodeで実行 POD_ID="$(sudo crictl pods --name test-pod -q)" ``` ここから、Podのcgroupのパスが決定します。 ```bash # PodがスケジュールされているNodeで実行 sudo crictl inspectp -o=json $POD_ID | grep cgroupsPath ``` 結果のcgroupパスにはPodの`ポーズ中`コンテナも含まれます。Podレベルのcgroupは１つ上のディレクトリです。 ``` "cgroupsPath": "/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/7ccf55aee35dd16aca4189c952d83487297f3cd760f1bbf09620e206e7d0c27a" ``` 今回のケースでは、Podのcgroupパスは、`kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2`となります。メモリーのPodレベルのcgroupの設定を確認しましょう。 ```bash # PodがスケジュールされているNodeで実行 # また、Podに割り当てられたcgroupと同じ名前に変更 cat /sys/fs/cgroup/memory/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/memory.limit_in_bytes ``` 予想通り320MiBです。 ``` 335544320 ``` ### Observability Podのオーバヘッドが利用されているタイミングを特定し、定義されたオーバーヘッドで実行されているワークロードの安定性を観察するため、[kube-state-metrics](https://github.com/kubernetes/kube-state-metrics)には`kube_pod_overhead`というメトリクスが用意されています。この機能はv1.9のkube-state-metricsでは利用できませんが、次のリリースで期待されています。それまでは、kube-state-metricsをソースからビルドする必要があります。 ## {{% heading "whatsnext" %}} * [RuntimeClass](/ja/docs/concepts/containers/runtime-class/) * [Podのオーバーヘッドの設計](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead) </ins>


`Guaranteed` pods are guaranteed only when requests and limits are specified for all the containers and they are equal. These pods will never be evicted because of another pod's resource consumption. If a system daemon (such as `kubelet`, <del> `docker`, and `journald`) is consuming more resources than were reserved via </del> <ins> and `journald`) is consuming more resources than were reserved via </ins> `system-reserved` or `kube-reserved` allocations, and the node only has `Guaranteed` or `Burstable` pods using less resources than requests left on it, then the kubelet must choose to evict one of these pods to preserve node stability


--> 仅当 `Guaranteed` Pod 中所有容器都被指定了请求和限制并且二者相等时，才保证 Pod 不被驱逐。 这些 Pod 永远不会因为另一个 Pod 的资源消耗而被驱逐。 <del> 如果系统守护进程（例如 `kubelet`、`docker` 和 `journald`） </del> <ins> 如果系统守护进程（例如 `kubelet` 和 `journald`） </ins> 消耗的资源比通过 `system-reserved` 或 `kube-reserved` 分配保留的资源多， 并且该节点只有 `Guaranteed` 或 `Burstable` Pod 使用的资源少于其上剩余的请求， 那么 kubelet 必须选择驱逐这些 Pod 中的一个以保持节点稳定性并减少资源匮乏对其他 Pod 的影响。


title: Pod 优先级（Pod Priority） id: pod-priority date: 2019-01-31 <del> full_link: /zh/docs/concepts/configuration/pod-priority-preemption/#pod-priority </del> <ins> full_link: /zh/docs/concepts/scheduling-eviction/pod-priority-preemption/#pod-priority </ins> short_description: > Pod 优先级表示一个 Pod 相对于其他 Pod 的重要性。


title: Pod Priority id: pod-priority date: 2019-01-31 <del> full_link: /docs/concepts/configuration/pod-priority-preemption/#pod-priority </del> <ins> full_link: /docs/concepts/scheduling-eviction/pod-priority-preemption/#pod-priority </ins> short_description: > Pod Priority indicates the importance of a Pod relative to other Pods.


<!--more--> <!-- <del> [Pod Priority](/docs/concepts/configuration/pod-priority-preemption/#pod-priority) gives the ability to set scheduling priority of a Pod to be higher and lower than other Pods — an important feature for production clusters workload. </del> <ins> [Pod Priority](/docs/concepts/scheduling-eviction/pod-priority-preemption/#pod-priority) gives the ability to set scheduling priority of a Pod to be higher and lower than other Pods — an important feature for production clusters workload. </ins> --> <del> [Pod 优先级](/zh/docs/concepts/configuration/pod-priority-preemption/#pod-priority) </del> <ins> [Pod 优先级](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/#pod-priority) </ins> 允许用户为 Pod 设置高于或低于其他 Pod 的优先级 -- 这对于生产集群 工作负载而言是一个重要的特性。


The [`fejta-bot`](https://github.com/fejta-bot) bot marks issues as stale after 90 days of inactivity. After 30 more days it marks issues as rotten and closes them.  PR wranglers should close issues after 14-30 days of inactivity. {{< /note >}} <ins> ## PR Wrangler shadow program In late 2021, SIG Docs introduced the PR Wrangler Shadow Program. The program was introduced to help new contributors understand the PR wrangling process. ### Become a shadow - If you are interested in shadowing as a PR wrangler, please visit the [PR Wranglers Wiki page](https://github.com/kubernetes/website/wiki/PR-Wranglers) to see the PR wrangling schedule for this year and sign up. - Kubernetes org members can edit the [PR Wranglers Wiki page](https://github.com/kubernetes/website/wiki/PR-Wranglers) and sign up to shadow an existing PR Wrangler for a week. - Others can reach out on the [#sig-docs Slack channel](https://kubernetes.slack.com/messages/sig-docs) for requesting to shadow an assigned PR Wrangler for a specific week. Feel free to reach out to Brad Topol (`@bradtopol`) or one of the [SIG Docs co-chairs/leads](https://github.com/kubernetes/community/tree/master/sig-docs#leadership). - Once you've signed up to shadow a PR Wrangler, introduce yourself to the PR Wrangler on the [Kubernetes Slack](slack.k8s.io). </ins>  No newline at end of file


{{< warning >}} <del> Only use kubeconfig files from trusted sources. Using a specially-crafted kubeconfig file could result in malicious code execution or file exposure. </del> <ins> Only use kubeconfig files from trusted sources. Using a specially-crafted kubeconfig file could result in malicious code execution or file exposure. </ins> If you must use an untrusted kubeconfig file, inspect it carefully first, much as you would a shell script. {{< /warning>}}


Create a directory named `config-exercise`. In your `config-exercise` directory, create a file named `config-demo` with this content: <del> ```shell </del> <ins> ```yaml </ins> apiVersion: v1 kind: Config preferences: {}


### Linux ```shell <del> export KUBECONFIG_SAVED=$KUBECONFIG </del> <ins> export KUBECONFIG_SAVED="$KUBECONFIG" </ins> ``` ### Windows PowerShell


### Linux ```shell <del> export KUBECONFIG=$KUBECONFIG:config-demo:config-demo-2 </del> <ins> export KUBECONFIG="${KUBECONFIG}:config-demo:config-demo-2" </ins> ``` ### Windows PowerShell


### Linux ```shell <del> export KUBECONFIG=$KUBECONFIG:$HOME/.kube/config </del> <ins> export KUBECONFIG="${KUBECONFIG}:${HOME}/.kube/config" </ins> ``` ### Windows Powershell


### Linux ```shell <del> export KUBECONFIG=$KUBECONFIG_SAVED </del> <ins> export KUBECONFIG="$KUBECONFIG_SAVED" </ins> ``` ### Windows PowerShell


<ins> --- title: スケジューリングポリシー content_type: concept sitemap: priority: 0.2 # スケジューリングポリシーは廃止されました。 --- <!-- overview --> バージョンv1.23より前のKubernetesでは、スケジューリングポリシーを使用して、*predicates*と*priorities*の処理を指定することができました。例えば、`kube-scheduler --policy-config-file <filename>`または`kube-scheduler --policy-configmap <ConfigMap>`を実行すると、スケジューリングポリシーを設定することが可能です。 このスケジューリングポリシーは、バージョンv1.23以降のKubernetesではサポートされていません。関連するフラグである、`policy-config-file`、`policy-configmap`、`policy-configmap-namespace`、`use-legacy-policy-config`も同様にサポートされていません。 代わりに、[スケジューラー設定](/ja/docs/reference/scheduling/config/)を使用してください。 ## {{% heading "whatsnext" %}} * [スケジューリング](/ja/docs/concepts/scheduling-eviction/kube-scheduler/)について学ぶ * [kube-scheduler設定](/ja/docs/reference/scheduling/config/)について学ぶ * [kube-scheduler設定リファレンス(v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/)について読む </ins>


# Array of authenticated usernames to exempt. usernames: [] # Array of runtime class names to exempt. <del> runtimeClassNames: [] </del> <ins> runtimeClasses: [] </ins> # Array of namespaces to exempt. namespaces: [] ```


the YAML: `192.0.2.42:9376` (TCP). {{< note >}} <del> The Kubernetes API server does not allow proxying to endpoints that are not mapped to pods. Actions such as `kubectl proxy <service-name>` where the service has no selector will fail due to this constraint. This prevents the Kubernetes API server from being used as a proxy to endpoints the caller may not be authorized to access. </del> <ins> The Kubernetes API server does not allow proxying to endpoints that are not mapped to pods. Actions such as `kubectl proxy <service-name>` where the service has no selector will fail due to this constraint. This prevents the Kubernetes API server from being used as a proxy to endpoints the caller may not be authorized to access. </ins> {{< /note >}} An ExternalName Service is a special case of Service that does not have


Later in this page you can read about various kube-proxy implementations work. Overall, you should note that, when running `kube-proxy`, kernel level rules may be <del> modified (for example, iptables rules might get created), which won't get cleaned up, </del> <ins> modified (for example, iptables rules might get created), which won't get cleaned up, </ins> in some cases until you reboot.  Thus, running kube-proxy is something that should only be done by an administrator which understands the consequences of having a low level, privileged network proxying service on a computer.  Although the `kube-proxy`


- The ConfigMap parameters for the kube-proxy cannot all be validated and verified on startup.  For example, if your operating system doesn't allow you to run iptables commands, the standard kernel kube-proxy implementation will not work.  Likewise, if you have an operating system which doesn't support `netsh`, it will not run in Windows userspace mode. ### User space proxy mode {#proxy-mode-userspace} <ins> {{< feature-state for_k8s_version="v1.23" state="deprecated" >}} </ins> In this (legacy) mode, kube-proxy watches the Kubernetes control plane for the addition and removal of Service and Endpoint objects. For each Service it opens a


other versions of Kubernetes, check the documentation for that release. By default, `spec.loadBalancerClass` is `nil` and a `LoadBalancer` type of Service uses the cloud provider's default load balancer implementation if the cluster is configured with <del> a cloud provider using the `--cloud-provider` component flag. </del> <ins> a cloud provider using the `--cloud-provider` component flag. </ins> If `spec.loadBalancerClass` is specified, it is assumed that a load balancer implementation that matches the specified class is watching for Services. Any default load balancer implementation (for example, the one provided by the cloud provider) will ignore Services that have this field set. `spec.loadBalancerClass` can be set on a Service of type `LoadBalancer` only. <del> Once set, it cannot be changed. </del> <ins> Once set, it cannot be changed. </ins> The value of `spec.loadBalancerClass` must be a label-style identifier, with an optional prefix such as "`internal-vip`" or "`example.com/internal-vip`". Unprefixed names are reserved for end-users.


service.beta.kubernetes.io/aws-load-balancer-security-groups: "sg-53fae93f" # A list of existing security groups to be configured on the ELB created. Unlike the annotation <del> # service.beta.kubernetes.io/aws-load-balancer-extra-security-groups, this replaces all other security groups previously assigned to the ELB and also overrides the creation </del> <ins> # service.beta.kubernetes.io/aws-load-balancer-extra-security-groups, this replaces all other security groups previously assigned to the ELB and also overrides the creation </ins> # of a uniquely generated security group for this ELB. # The first security group ID on this list is used as a source to permit incoming traffic to target worker nodes (service traffic and health checks). # If multiple ELBs are configured with the same security group ID, only a single permit line will be added to the worker node security groups, that means if you delete any


service.beta.kubernetes.io/aws-load-balancer-extra-security-groups: "sg-53fae93f,sg-42efd82e" #  A list of additional security groups to be added to the created ELB, this leaves the uniquely generated security group in place, this ensures that every ELB # has a unique security group ID and a matching permit line to allow traffic to the target worker nodes (service traffic and health checks). <del> # Security groups defined here can be shared between services. </del> <ins> # Security groups defined here can be shared between services. </ins> service.beta.kubernetes.io/aws-load-balancer-target-node-labels: "ingress-gw,gw-name=public-api" # A comma separated list of key-value pairs which are used


<ins> --- title: Podのセキュリティアドミッション content_type: concept weight: 20 min-kubernetes-server-version: v1.22 --- <!-- overview --> {{< feature-state for_k8s_version="v1.23" state="beta" >}} Kubernetesの[Podセキュリティの標準](/ja/docs/concepts/security/pod-security-standards/)はPodに対して異なる分離レベルを定義します。 これらの標準によって、Podの動作をどのように制限したいかを、明確かつ一貫した方法で定義することができます。 ベータ版機能として、Kubernetesは[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/)の後継である組み込みの _Pod Security_ {{< glossary_tooltip text="アドミッションコントローラー" term_id="admission-controller" >}}を提供しています。 Podセキュリティの制限は、Pod作成時に{{< glossary_tooltip text="名前空間" term_id="namespace" >}}レベルで適用されます。 {{< note >}} PodSecurityPolicy APIは非推奨であり、v1.25でKubernetesから[削除](/docs/reference/using-api/deprecation-guide/#v1-25)される予定です。 {{< /note >}} <!-- body --> ## `PodSecurity`アドミッションプラグインの有効化 {#enabling-the-podsecurity-admission-plugin} v1.23において、`PodSecurity`の[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)はベータ版の機能で、デフォルトで有効化されています。 v1.22において、`PodSecurity`の[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)はアルファ版の機能で、組み込みのアドミッションプラグインを使用するには、`kube-apiserver`で有効にする必要があります。 ```shell --feature-gates="...,PodSecurity=true" ``` ## 代替案:`PodSecurity`アドミッションwebhookのインストール {#webhook} クラスターがv1.22より古い、あるいは`PodSecurity`機能を有効にできないなどの理由で、ビルトインの`PodSecurity`アドミッションプラグインが使えない環境では、`PodSecurity`はアドミッションロジックはベータ版の[validating admission webhook](https://git.k8s.io/pod-security-admission/webhook)としても提供されています。 ビルド前のコンテナイメージ、証明書生成スクリプト、マニフェストの例は、[https://git.k8s.io/pod-security-admission/webhook](https://git.k8s.io/pod-security-admission/webhook)で入手可能です。 インストール方法: ```shell git clone git@github.com:kubernetes/pod-security-admission.git cd pod-security-admission/webhook make certs kubectl apply -k . ``` {{< note >}} 生成された証明書の有効期限は2年間です。有効期限が切れる前に、証明書を再生成するか、内蔵のアドミッションプラグインを使用してWebhookを削除してください。 {{< /note >}} ## Podのセキュリティレベル {#pod-security-levels} Podのセキュリティアドミッションは、Podの[Security Context](/docs/tasks/configure-pod-container/security-context/)とその他の関連フィールドに、[Podセキュリティの標準](/ja/docs/concepts/security/pod-security-standards)で定義された3つのレベル、`privileged`、`baseline`、`restricted`に従って要件を設定するものです。 これらの要件の詳細については、[Podセキュリティの標準](/ja/docs/concepts/security/pod-security-standards)のページを参照してください。 ## Podの名前空間に対するセキュリティアドミッションラベル {#pod-security-admission-labels-for-namespaces} この機能を有効にするか、Webhookをインストールすると、名前空間を設定して、各名前空間でPodセキュリティに使用したいadmission controlモードを定義できます。 Kubernetesは、名前空間に使用したい定義済みのPodセキュリティの標準レベルのいずれかを適用するために設定できる{{< glossary_tooltip term_id="label" text="ラベル" >}}のセットを用意しています。 選択したラベルは、以下のように違反の可能性が検出された場合に{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}が取るアクションを定義します。 {{< table caption="Podのセキュリティアドミッションのモード" >}} モード | 説明 :---------|:------------ **enforce** | ポリシーに違反した場合、Podは拒否されます。 **audit** | ポリシー違反は、[監査ログ](/ja/docs/tasks/debug-application-cluster/audit/)に記録されるイベントに監査アノテーションを追加するトリガーとなりますが、それ以外は許可されます。 **warn** | ポリシーに違反した場合は、ユーザーへの警告がトリガーされますが、それ以外は許可されます。 {{< /table >}} 名前空間は、任意のまたはすべてのモードを設定することができ、異なるモードに対して異なるレベルを設定することもできます。 各モードには、使用するポリシーを決定する2つのラベルがあります。 ```yaml # モードごとのレベルラベルは、そのモードに適用するポリシーレベルを示す。 # # MODEは`enforce`、`audit`、`warn`のいずれかでなければならない。 # LEVELは`privileged`、`baseline`、`restricted`のいずれかでなければならない。 pod-security.kubernetes.io/<MODE>: <LEVEL> # オプション: モードごとのバージョンラベルは、Kubernetesのマイナーバージョンに同梱される # バージョンにポリシーを固定するために使用できる（例えばv{{< skew latestVersion >}}など）。 # # MODEは`enforce`、`audit`、`warn`のいずれかでなければならない。 # VERSIONは有効なKubernetesのマイナーバージョンか`latest`でなければならない。 pod-security.kubernetes.io/<MODE>-version: <VERSION> ``` [名前空間ラベルでのPodセキュリティの標準の適用](/docs/tasks/configure-pod-container/enforce-standards-namespace-labels)で使用例を確認できます。 ## WorkloadのリソースとPodテンプレート {#workload-resources-and-pod-templates} Podは、{{< glossary_tooltip term_id="deployment" >}}や{{< glossary_tooltip term_id="job">}}のような[ワークロードオブジェクト](/ja/docs/concepts/workloads/controllers/)を作成することによって、しばしば間接的に生成されます。 ワークロードオブジェクトは_Pod template_を定義し、ワークロードリソースの{{< glossary_tooltip term_id="controller" text="コントローラー" >}}はそのテンプレートに基づきPodを作成します。 違反の早期発見を支援するために、auditモードとwarningモードは、ワークロードリソースに適用されます。 ただし、enforceモードはワークロードリソースには**適用されず**、結果としてのPodオブジェクトにのみ適用されます。 ## 適用除外(Exemption) {#exemptions} Podセキュリティの施行から _exemptions_ を定義することで、特定の名前空間に関連するポリシーのために禁止されていたPodの作成を許可することができます。 Exemptionは[アドミッションコントローラーの設定](/docs/tasks/configure-pod-container/enforce-standards-admission-controller/#configure-the-admission-controller)で静的に設定することができます。 Exemptionは明示的に列挙する必要があります。 Exemptionを満たしたリクエストは、アドミッションコントローラーによって _無視_ されます(`enforce`、`audit`、`warn`のすべての動作がスキップされます)。Exemptionの次元は以下の通りです。 - **Usernames:** 認証されていない(あるいは偽装された)ユーザー名を持つユーザーからの要求は無視されます。 - **RuntimeClassNames:** Podと[ワークロードリソース](#workload-resources-and-pod-templates)で指定された除外ランタイムクラス名は、無視されます。 - **Namespaces:** 除外された名前空間のPodと[ワークロードリソース](#workload-resources-and-pod-templates)は、無視されます。 {{< caution >}} ほとんどのPodは、[ワークロードリソース](#workload-resources-and-pod-templates)に対応してコントローラーが作成します。つまり、エンドユーザーを適用除外にするのはPodを直接作成する場合のみで、ワークロードリソースを作成する場合は適用除外になりません。 コントローラーサービスアカウント(`system:serviceaccount:kube-system:replicaset-controller`など)は通常、除外してはいけません。そうした場合、対応するワークロードリソースを作成できるすべてのユーザーを暗黙的に除外してしまうためです。 {{< /caution >}} 以下のPodフィールドに対する更新は、ポリシーチェックの対象外となります。つまり、Podの更新要求がこれらのフィールドを変更するだけであれば、Podが現在のポリシーレベルに違反していても拒否されることはありません。 - すべてのメタデータの更新(seccompまたはAppArmorアノテーションへの変更を**除く**) - `seccomp.security.alpha.kubernetes.io/pod`(非推奨) - `container.seccomp.security.alpha.kubernetes.io/*`(非推奨) - `container.apparmor.security.beta.kubernetes.io/*` - `.spec.activeDeadlineSeconds`に対する有効な更新 - `.spec.tolerations`に対する有効な更新 ## {{% heading "whatsnext" %}} - [Podセキュリティの標準](/ja/docs/concepts/security/pod-security-standards) - [Podセキュリティの標準の適用](/docs/setup/best-practices/enforcing-pod-security-standards) - [ビルトインのアドミッションコントローラーの設定によるPodセキュリティの標準の適用](/docs/tasks/configure-pod-container/enforce-standards-admission-controller) - [名前空間ラベルでのPodセキュリティの標準の適用](/docs/tasks/configure-pod-container/enforce-standards-namespace-labels) - [PodSecurityPolicyからビルトインのPodSecurityアドミッションコントローラーへの移行](/docs/tasks/configure-pod-container/migrate-from-psp) </ins>


[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) on the [API server](/docs/reference/command-line-tools-reference/kube-apiserver/) and the [controller manager](/docs/reference/command-line-tools-reference/kube-controller-manager/). <del> It is enabled by default. </del> When enabled, the control plane tracks new Jobs using the behavior described below. Jobs created before the feature was enabled are unaffected. As a user,


title: "弃用 Dockershim 的常见问题" date: 2020-12-02 slug: dockershim-faq <del> aliases: [ '/dockershim' ] </del> <ins> aliases: [ '/zh/dockershim' ] </ins> --- <!-- layout: blog


criSocket: "/var/run/dockershim.sock"   taints:     - key: "kubeadmNode"        value: "master"         value: "someValue"        effect: "NoSchedule"   kubeletExtraArgs:     v: 4


tlsBootstrapToken is a token used for TLS bootstrapping.  If bootstrapToken is set, this field is defaulted to .bootstrapToken.token, but can be overridden. If file is set, this field must be set in case the KubeConfigFile does not   If bootstrapToken is set, this field is defaulted to .bootstrapToken.token, but can be overridden. If file is set, this field must be set in case the KubeConfigFile does not  contain any other authentication information.


string
criSocket is used to retrieve container runtime information. This information will
criSocket is used to retrieve container runtime information. This information will  be annotated to the Node API object, for later re-use.


taints specifies the taints the Node API object should be registered with.  If this field is unset, i.e. nil, in the kubeadm init process it will be defaulted to 'node-role.kubernetes.io/master=""'. If you don't want to taint your control-plane node, set this field to an empty list, i.e. taints: [] in the YAML file. This field is   If this field is unset, i.e. nil, in the kubeadm init process it will be defaulted with a control-plane taint for control-plane nodes. If you don't want to taint your control-plane node, set this field to an empty list, i.e. taints: [], in the YAML file. This field is  solely used for Node registration.


criSocket: "/var/run/dockershim.sock"   taints:   - key: "kubeadmNode"      value: "master"       value: "someValue"      effect: "NoSchedule"   kubeletExtraArgs:     v: 4


tains specifies the taints the Node API object should be registered with.  If this field is unset, i.e. nil, in the kubeadm init process it will be defaulted to taints: ["node-role.kubernetes.io/master:""]. If you don't want to taint your control-plane node, set this field to an empty slice,   If this field is unset, i.e. nil, in the kubeadm init process it will be defaulted with a control-plane taint for control-plane nodes. If you don't want to taint your control-plane node, set this field to an empty list,  i.e. taints: [] in the YAML file. This field is solely used for Node registration.


To apply Pod Security Standards to specific namespaces, refer to [Apply Pod Security Standards at the namespace level](/docs/tutorials/security/ns-level-pss). <ins> If you are running a version of Kubernetes other than v{{< skew currentVersion >}}, check the documentation for that version. </ins> ## {{% heading "prerequisites" %}} Install the following on your workstation:


1. Create a cluster with no Pod Security Standards applied: ```shell <del> kind create cluster --name psa-wo-cluster-pss --image kindest/node:v1.23.0 </del> <ins> kind create cluster --name psa-wo-cluster-pss --image kindest/node:v1.24.0 </ins> ``` The output is similar to this: ``` Creating cluster "psa-wo-cluster-pss" ... <del> ✓ Ensuring node image (kindest/node:v1.23.0) 🖼 </del> <ins> ✓ Ensuring node image (kindest/node:v1.24.0) 🖼 </ins> ✓ Preparing nodes 📦 ✓ Writing configuration 📜 ✓ Starting control-plane 🕹


these Pod Security Standards: ```shell <del> kind create cluster --name psa-with-cluster-pss --image kindest/node:v1.23.0 --config /tmp/pss/cluster-config.yaml </del> <ins> kind create cluster --name psa-with-cluster-pss --image kindest/node:v1.24.0 --config /tmp/pss/cluster-config.yaml </ins> ``` The output is similar to this: ``` Creating cluster "psa-with-cluster-pss" ... <del> ✓ Ensuring node image (kindest/node:v1.23.0) 🖼 </del> <ins> ✓ Ensuring node image (kindest/node:v1.24.0) 🖼 </ins> ✓ Preparing nodes 📦 ✓ Writing configuration 📜 ✓ Starting control-plane 🕹


See [Certificate Signing Requests](/docs/reference/access-authn-authz/certificate-signing-requests/) for more information on the permissions required to perform different actions on CertificateSigningRequest resources. <del> ### CertificateSubjectRestrictions {#certificatesubjectrestrictions} </del> <ins> ### CertificateSubjectRestriction {#certificatesubjectrestriction} </ins> This admission controller observes creation of CertificateSigningRequest resources that have a `spec.signerName` of `kubernetes.io/kube-apiserver-client`. It rejects any request that specifies a 'group' (or 'organization attribute')


* [Removing Dockershim from kubelet](https://github.com/kubernetes/enhancements/issues/2221): the Container Runtime Interface (CRI) for Docker (i.e. Dockershim) is currently a built-in container runtime in the kubelet code base. It was deprecated in v1.20. As of v1.24, the kubelet will no longer have dockershim. Check out this blog on [what you need to do be ready for v1.24](/blog/2022/03/31/ready-for-dockershim-removal/). * [Storage capacity tracking for pod scheduling](https://github.com/kubernetes/enhancements/issues/1472): The CSIStorageCapacity API supports exposing currently available storage capacity via CSIStorageCapacity objects and enhances scheduling of pods that use CSI volumes with late binding. In v1.24, the CSIStorageCapacity API will be stable. The API graduating to stable initates the deprecation of the v1beta1 CSIStorageCapacity API. Refer to the [Storage Capacity Constraints for Pod Scheduling KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/1472-storage-capacity-tracking) for more information. * [The `master` label is no longer present on kubeadm control plane nodes](https://github.com/kubernetes/kubernetes/pull/107533). For new clusters, the label 'node-role.kubernetes.io/master' will no longer be added to control plane nodes, only the label 'node-role.kubernetes.io/control-plane' will be added. For more information, refer to [KEP-2067: Rename the kubeadm "master" label and taint](https://github.com/kubernetes/enhancements/tree/master/keps/sig-cluster-lifecycle/kubeadm/2067-rename-master-label-taint). <del> * [VolumeSnapshot v1beta1 CRD will be removed](https://github.com/kubernetes/enhancements/issues/177). Volume snapshot and restore functionality for Kubernetes and the [Container Storage Interface](https://github.com/container-storage-interface/spec/blob/master/spec.md) (CSI), which provides standardized APIs design (CRDs) and adds PV snapshot/restore support for CSI volume drivers, entered beta in v1.20. VolumeSnapshot v1beta1 was deprecated in v1.21 and is now unsupported. Refer to [KEP-177: CSI Snapshot](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/177-volume-snapshot#kep-177-csi-snapshot) and [kubernetes-csi/external-snapshotter](https://github.com/kubernetes-csi/external-snapshotter/releases/tag/v4.1.0) for more information. </del> <ins> * [VolumeSnapshot v1beta1 CRD will be removed](https://github.com/kubernetes/enhancements/issues/177). Volume snapshot and restore functionality for Kubernetes and the [Container Storage Interface](https://github.com/container-storage-interface/spec/blob/master/spec.md) (CSI), which provides standardized APIs design (CRDs) and adds PV snapshot/restore support for CSI volume drivers, moved to GA in v1.20. VolumeSnapshot v1beta1 was deprecated in v1.20 and will become unsupported with the v1.24 release. Refer to [KEP-177: CSI Snapshot](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/177-volume-snapshot#kep-177-csi-snapshot) and the [Volume Snapshot GA blog](/blog/2020/12/10/kubernetes-1.20-volume-snapshot-moves-to-ga/) blog article for more information. </ins> ## What to do


requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: <del> - key: topology.kubernetes.io/zone </del> <ins> - key: kubernetes.io/os </ins> operator: In values: <del> - antarctica-east1 - antarctica-west1 </del> <ins> - linux </ins> preferredDuringSchedulingIgnoredDuringExecution: - weight: 1 preference:


requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: <del> - key: kubernetes.io/os </del> <ins> - key: topology.kubernetes.io/zone </ins> operator: In values: <del> - linux </del> <ins> - antarctica-east1 - antarctica-west1 </ins> preferredDuringSchedulingIgnoredDuringExecution: - weight: 1 preference:


<ins> --- layout: blog title: '在 Ingress-NGINX v1.2.0 中提高安全标准' date: 2022-04-28 slug: ingress-nginx-1-2-0 --- <!-- layout: blog title: 'Increasing the security bar in Ingress-NGINX v1.2.0' date: 2022-04-28 slug: ingress-nginx-1-2-0 --> <!-- **Authors:** Ricardo Katz (VMware), James Strong (Chainguard) --> **作者：** Ricardo Katz (VMware), James Strong (Chainguard) <!-- The [Ingress](/docs/concepts/services-networking/ingress/) may be one of the most targeted components of Kubernetes. An Ingress typically defines an HTTP reverse proxy, exposed to the Internet, containing multiple websites, and with some privileged access to Kubernetes API (such as to read Secrets relating to TLS certificates and their private keys). --> [Ingress](/zh-cn/docs/concepts/services-networking/ingress/) 可能是 Kubernetes 最容易受攻击的组件之一。 Ingress 通常定义一个 HTTP 反向代理，暴露在互联网上，包含多个网站，并具有对 Kubernetes API 的一些特权访问（例如读取与 TLS 证书及其私钥相关的 Secret）。 <!-- While it is a risky component in your architecture, it is still the most popular way to properly expose your services. --> 虽然它是架构中的一个风险组件，但它仍然是正常公开服务的最流行方式。 <!-- Ingress-NGINX has been part of security assessments that figured out we have a big problem: we don't do all proper sanitization before turning the configuration into an `nginx.conf` file, which may lead to information disclosure risks. --> Ingress-NGINX 一直是安全评估的重头戏，这类评估会发现我们有着很大的问题： 在将配置转换为 `nginx.conf` 文件之前，我们没有进行所有适当的清理，这可能会导致信息泄露风险。 <!-- While we understand this risk and the real need to fix this, it's not an easy process to do, so we took another approach to reduce (but not remove!) this risk in the current (v1.2.0) release. --> 虽然我们了解此风险以及解决此问题的真正需求，但这并不是一个容易的过程， 因此我们在当前(v1.2.0)版本中采取了另一种方法来减少（但不是消除！）这种风险。 <!-- ## Meet Ingress NGINX v1.2.0 and the chrooted NGINX process --> ## 了解 Ingress NGINX v1.2.0 和 chrooted NGINX 进程 <!-- One of the main challenges is that Ingress-NGINX runs the web proxy server (NGINX) alongside the Ingress controller (the component that has access to Kubernetes API that and that creates the `nginx.conf` file). --> 主要挑战之一是 Ingress-NGINX 运行着 Web 代理服务器（NGINX），并与 Ingress 控制器一起运行 （后者是一个可以访问 Kubernetes API 并创建 `nginx.conf` 的组件）。 <!-- So, NGINX does have the same access to the filesystem of the controller (and Kubernetes service account token, and other configurations from the container). While splitting those components is our end goal, the project needed a fast response; that lead us to the idea of using `chroot()`. --> 因此，NGINX 对控制器的文件系统（和 Kubernetes 服务帐户令牌，以及容器中的其他配置）具有相同的访问权限。 虽然拆分这些组件是我们的最终目标，但该项目需要快速响应；这让我们想到了使用 `chroot()`。 <!-- Let's take a look into what an Ingress-NGINX container looked like before this change: --> 让我们看一下 Ingress-NGINX 容器在此更改之前的样子： ![Ingress NGINX pre chroot](ingress-pre-chroot.png) <!-- As we can see, the same container (not the Pod, the container!) that provides HTTP Proxy is the one that watches Ingress objects and writes the Container Volume --> 正如我们所见，用来提供 HTTP Proxy 的容器（不是 Pod，是容器！）也是是监视 Ingress 对象并将数据写入容器卷的容器。 <!-- Now, meet the new architecture: --> 现在，见识一下新架构： ![Ingress NGINX post chroot](ingress-post-chroot.png) <!-- What does all of this mean? A basic summary is: that we are isolating the NGINX service as a container inside the controller container. --> 这一切意味着什么？一个基本的总结是：我们将 NGINX 服务隔离为控制器容器内的容器。 <!-- While this is not strictly true, to understand what was done here, it's good to understand how Linux containers (and underlying mechanisms such as kernel namespaces) work. You can read about cgroups in the Kubernetes glossary: [`cgroup`](https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-cgroup) and learn more about cgroups interact with namespaces in the NGINX project article [What Are Namespaces and cgroups, and How Do They Work?](https://www.nginx.com/blog/what-are-namespaces-cgroups-how-do-they-work/). (As you read that, bear in mind that Linux kernel namespaces are a different thing from [Kubernetes namespaces](/docs/concepts/overview/working-with-objects/namespaces/)). --> 虽然这并不完全正确，但要了解这里所做的事情，最好了解 Linux 容器（以及内核命名空间等底层机制）是如何工作的。 你可以在 Kubernetes 词汇表中阅读有关 cgroup 的信息：[`cgroup`](/zh-cn/docs/reference/glossary/?fundamental=true#term-cgroup)， 并在 NGINX 项目文章[什么是命名空间和 cgroup，以及它们如何工作？](https://www.nginx.com/blog/what-are-namespaces-cgroups-how-do-they-work/) 中了解有关 cgroup 与命名空间交互的更多信息。（当你阅读时，请记住 Linux 内核命名空间与 [Kubernetes 命名空间](/zh-cn/docs/concepts/overview/working-with-objects/namespaces/)不同）。 <!-- ## Skip the talk, what do I need to use this new approach? --> ## 跳过谈话，我需要什么才能使用这种新方法？ <!-- While this increases the security, we made this feature an opt-in in this release so you can have time to make the right adjustments in your environment(s). This new feature is only available from release v1.2.0 of the Ingress-NGINX controller. --> 虽然这增加了安全性，但我们在这个版本中把这个功能作为一个选项，这样你就可以有时间在你的环境中做出正确的调整。 此新功能仅在 Ingress-NGINX 控制器的 v1.2.0 版本中可用。 <!-- There are two required changes in your deployments to use this feature: * Append the suffix "-chroot" to the container image name. For example: `gcr.io/k8s-staging-ingress-nginx/controller-chroot:v1.2.0` * In your Pod template for the Ingress controller, find where you add the capability `NET_BIND_SERVICE` and add the capability `SYS_CHROOT`. After you edit the manifest, you'll see a snippet like: --> 要使用这个功能，在你的部署中有两个必要的改变： * 将后缀 "-chroot" 添加到容器镜像名称中。例如：`gcr.io/k8s-staging-ingress-nginx/controller-chroot:v1.2.0` * 在你的 Ingress 控制器的 Pod 模板中，找到添加 `NET_BIND_SERVICE` 权能的位置并添加 `SYS_CHROOT` 权能。 编辑清单后，你将看到如下代码段： ```yaml capabilities: drop: - ALL add: - NET_BIND_SERVICE - SYS_CHROOT ``` <!-- If you deploy the controller using the official Helm chart then change the following setting in `values.yaml`: --> 如果你使用官方 Helm Chart 部署控制器，则在 `values.yaml` 中更改以下设置： ```yaml controller: image: chroot: true ``` <!-- Ingress controllers are normally set up cluster-wide (the IngressClass API is cluster scoped). If you manage the Ingress-NGINX controller but you're not the overall cluster operator, then check with your cluster admin about whether you can use the `SYS_CHROOT` capability, **before** you enable it in your deployment. --> Ingress 控制器通常部署在集群作用域（IngressClass API 是集群作用域的）。 如果你管理 Ingress-NGINX 控制器但你不是整个集群的操作员， 请在部署中启用它**之前**与集群管理员确认你是否可以使用 `SYS_CHROOT` 功能。 <!-- ## OK, but how does this increase the security of my Ingress controller? Take the following configuration snippet and imagine, for some reason it was added to your `nginx.conf`: --> ## 好吧，但这如何能提高我的 Ingress 控制器的安全性呢？ 以下面的配置片段为例，想象一下，由于某种原因，它被添加到你的 `nginx.conf` 中： ``` location /randomthing/ { alias /; autoindex on; } ``` <!-- If you deploy this configuration, someone can call `http://website.example/randomthing` and get some listing (and access) to the whole filesystem of the Ingress controller. Now, can you spot the difference between chrooted and non chrooted Nginx on the listings below? --> 如果你部署了这种配置，有人可以调用 `http://website.example/randomthing` 并获取对 Ingress 控制器的整个文件系统的一些列表（和访问权限）。 现在，你能在下面的列表中发现 chroot 处理过和未经 chroot 处理过的 Nginx 之间的区别吗？ | 不额外调用 `chroot()`             | 额外调用 `chroot()` | |----------------------------|--------| | `bin`                      | `bin`  | | `dev`                      | `dev`  | | `etc`                      | `etc`  | | `home`                     |        | | `lib`                      | `lib`  | | `media`                    |        | | `mnt`                      |        | | `opt`                      | `opt`  | | `proc`                     | `proc` | | `root`                     |        | | `run`                      | `run`  | | `sbin`                     |        | | `srv`                      |        | | `sys`                      |        | | `tmp`                      | `tmp`  | | `usr`                      | `usr`  | | `var`                      | `var`  | | `dbg`                      |        | | `nginx-ingress-controller` |        | | `wait-shutdown`            |        | <!-- The one in left side is not chrooted. So NGINX has full access to the filesystem. The one in right side is chrooted, so a new filesystem with only the required files to make NGINX work is created. --> 左侧的那个没有 chroot 处理。所以 NGINX 可以完全访问文件系统。右侧的那个经过 chroot 处理， 因此创建了一个新文件系统，其中只有使 NGINX 工作所需的文件。 <!-- ## What about other security improvements in this release? --> ## 此版本中的其他安全改进如何？ <!-- We know that the new `chroot()` mechanism helps address some portion of the risk, but still, someone can try to inject commands to read, for example, the `nginx.conf` file and extract sensitive information. --> 我们知道新的 `chroot()` 机制有助于解决部分风险，但仍然有人可以尝试注入命令来读取，例如 `nginx.conf` 文件并提取敏感信息。 <!-- So, another change in this release (this is opt-out!) is the _deep inspector_. We know that some directives or regular expressions may be dangerous to NGINX, so the deep inspector checks all fields from an Ingress object (during its reconciliation, and also with a [validating admission webhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook)) to verify if any fields contains these dangerous directives. --> 所以，这个版本的另一个变化（可选择取消）是 **深度探测（Deep Inspector）**。 我们知道某些指令或正则表达式可能对 NGINX 造成危险，因此深度探测器会检查 Ingress 对象中的所有字段 （在其协调期间，并且还使用[验证准入 webhook](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook)) 验证是否有任何字段包含这些危险指令。 <!-- The ingress controller already does this for annotations, and our goal is to move this existing validation to happen inside deep inspection as part of a future release. --> Ingress 控制器已经通过注解做了这个工作，我们的目标是把现有的验证转移到深度探测中，作为未来版本的一部分。 <!-- You can take a look into the existing rules in [https://github.com/kubernetes/ingress-nginx/blob/main/internal/ingress/inspector/rules.go](https://github.com/kubernetes/ingress-nginx/blob/main/internal/ingress/inspector/rules.go). --> 你可以在 [https://github.com/kubernetes/ingress-nginx/blob/main/internal/ingress/inspector/rules.go](https://github.com/kubernetes/ingress-nginx/blob/main/internal/ingress/inspector/rules.go) 中查看现有规则。 <!-- Due to the nature of inspecting and matching all strings within relevant Ingress objects, this new feature may consume a bit more CPU. You can disable it by running the ingress controller with the command line argument `--deep-inspect=false`. --> 由于检查和匹配相关 Ingress 对象中的所有字符串的性质，此新功能可能会消耗更多 CPU。 你可以通过使用命令行参数 `--deep-inspect=false` 运行 Ingress 控制器来禁用它。 <!-- ## What's next? This is not our final goal. Our final goal is to split the control plane and the data plane processes. In fact, doing so will help us also achieve a [Gateway](https://gateway-api.sigs.k8s.io/) API implementation, as we may have a different controller as soon as it "knows" what to provide to the data plane (we need some help here!!) --> ## 下一步是什么? 这不是我们的最终目标。我们的最终目标是拆分控制平面和数据平面进程。 事实上，这样做也将帮助我们实现 [Gateway](https://gateway-api.sigs.k8s.io/) API 实现， 因为一旦它“知道”要提供什么，我们可能会有不同的控制器 数据平面（我们需要一些帮助！！） <!-- Some other projects in Kubernetes already take this approach (like [KPNG](https://github.com/kubernetes-sigs/kpng), the proposed replacement for `kube-proxy`), and we plan to align with them and get the same experience for Ingress-NGINX. --> Kubernetes 中的其他一些项目已经采用了这种方法（如 [KPNG](https://github.com/kubernetes-sigs/kpng)， 建议替换 `kube-proxy`），我们计划与他们保持一致，并为 Ingress-NGINX 获得相同的体验。 <!-- ## Further reading If you want to take a look into how chrooting was done in Ingress NGINX, take a look into [https://github.com/kubernetes/ingress-nginx/pull/8337](https://github.com/kubernetes/ingress-nginx/pull/8337) The release v1.2.0 containing all the changes can be found at [https://github.com/kubernetes/ingress-nginx/releases/tag/controller-v1.2.0](https://github.com/kubernetes/ingress-nginx/releases/tag/controller-v1.2.0) --> ## 延伸阅读 如果你想了解如何在 Ingress NGINX 中完成 chrooting，请查看 [https://github.com/kubernetes/ingress-nginx/pull/8337](https://github.com/kubernetes/ingress-nginx/pull/8337)。 包含所有更改的版本 v1.2.0 可以在以下位置找到 [https://github.com/kubernetes/ingress-nginx/releases/tag/controller-v1.2.0](https://github.com/kubernetes/ingress-nginx/releases/tag/controller-v1.2.0) </ins>


nohup.out # Hugo output <del> public/ resources/ </del> <ins> /public/ /resources/ </ins> .hugo_build.lock # Netlify Functions build output package-lock.json <del> functions/ node_modules/ </del> <ins> /functions/ /node_modules/ </ins> # Generated files when building with make container-build .config/


`annotate`    | kubectl annotate (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags] | Add or update the annotations of one or more resources. `api-resources`    | `kubectl api-resources [flags]` | List the API resources that are available. `api-versions`    | `kubectl api-versions [flags]` | List the API versions that are available.  --> 操作             | 语法      |       描述 -------------------- | -------------------- | -------------------- `alpha`    | `kubectl alpha SUBCOMMAND [flags]` | 列出与 alpha 特性对应的可用命令，这些特性在 Kubernetes 集群中默认情况下是不启用的。 `annotate`    | kubectl annotate (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags] | 添加或更新一个或多个资源的注解。 `api-resources`    | `kubectl api-resources [flags]` | 列出可用的 API 资源。 `api-versions`    | `kubectl api-versions [flags]` | 列出可用的 API 版本。


`cluster-info`    | `kubectl cluster-info [flags]` | Display endpoint information about the master and services in the cluster. `completion`    | `kubectl completion SHELL [options]` | Output shell completion code for the specified shell (bash or zsh). `config`        | `kubectl config SUBCOMMAND [flags]` | Modifies kubeconfig files. See the individual subcommands for details.  --> `apply`            | `kubectl apply -f FILENAME [flags]`| 从文件或 stdin 对资源应用配置更改。 `attach`        | `kubectl attach POD -c CONTAINER [-i] [-t] [flags]` | 挂接到正在运行的容器，查看输出流或与容器（stdin）交互。 `auth`    | `kubectl auth [flags] [options]` | 检查授权。 `autoscale`    | kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU] [flags] | 自动扩缩由副本控制器管理的一组 pod。 `certificate`    | `kubectl certificate SUBCOMMAND [options]` | 修改证书资源。 `cluster-info`    | `kubectl cluster-info [flags]` | 显示有关集群中主服务器和服务的端口信息。 `completion`    | `kubectl completion SHELL [options]` | 为指定的 Shell（Bash 或 Zsh）输出 Shell 补齐代码。 `config`        | `kubectl config SUBCOMMAND [flags]` | 修改 kubeconfig 文件。有关详细信息，请参阅各个子命令。


`delete`        | kubectl delete (-f FILENAME | TYPE [NAME | /NAME | -l label | --all]) [flags] | Delete resources either from a file, stdin, or specifying label selectors, names, resource selectors, or resources. `describe`    | kubectl describe (-f FILENAME | TYPE [NAME_PREFIX | /NAME | -l label]) [flags] | Display the detailed state of one or more resources. `diff`        | `kubectl diff -f FILENAME [flags]`| Diff file or stdin against live configuration.  --> `convert`    | `kubectl convert -f FILENAME [options]` | 在不同的 API 版本之间转换配置文件。配置文件可以是 YAML 或 JSON 格式。注意 - 需要安装 `kubectl-convert` 插件。 `cordon`    | `kubectl cordon NODE [options]` | 将节点标记为不可调度。 `cp`    | `kubectl cp <file-spec-src> <file-spec-dest> [options]` | 从容器复制文件、目录或将文件、目录复制到容器。 `create`        | `kubectl create -f FILENAME [flags]` | 从文件或 stdin 创建一个或多个资源。 `delete`        |  kubectl delete (-f FILENAME | TYPE [NAME | /NAME | -l label | --all]) [flags] |  基于文件、标准输入或通过指定标签选择器、名称、资源选择器或资源本身，删除资源。 `describe`    | kubectl describe (-f FILENAME | TYPE [NAME_PREFIX | /NAME | -l label]) [flags] | 显示一个或多个资源的详细状态。 `diff`        | `kubectl diff -f FILENAME [flags]`| 在当前起作用的配置和文件或标准输之间作对比 (**BETA**)


`expose`        | kubectl expose (-f FILENAME | TYPE NAME | TYPE/NAME) [--port=port] [--protocol=TCP|UDP] [--target-port=number-or-name] [--name=name] [--external-ip=external-ip-of-service] [--type=type] [flags] | Expose a replication controller, service, or pod as a new Kubernetes service. `get`        | kubectl get (-f FILENAME | TYPE [NAME | /NAME | -l label]) [--watch] [--sort-by=FIELD] [[-o | --output]=OUTPUT_FORMAT] [flags] | List one or more resources. `kustomize`    | `kubectl kustomize <dir> [flags] [options]` | List a set of API resources generated from instructions in a kustomization.yaml file. The argument must be the path to the directory containing the file, or a git repository URL with a path suffix specifying same with respect to the repository root.  --> `drain`    | `kubectl drain NODE [options]` | 腾空节点以准备维护。 `edit`        | kubectl edit (-f FILENAME | TYPE NAME | TYPE/NAME) [flags] | 使用默认编辑器编辑和更新服务器上一个或多个资源的定义。 `exec`        | `kubectl exec POD [-c CONTAINER] [-i] [-t] [flags] [-- COMMAND [args...]]` | 对 Pod 中的容器执行命令。 `explain`    | `kubectl explain  [--recursive=false] [flags]` | 获取多种资源的文档。例如 Pod、Node、Service 等。 `expose`        | kubectl expose (-f FILENAME | TYPE NAME | TYPE/NAME) [--port=port] [--protocol=TCP|UDP] [--target-port=number-or-name] [--name=name] [--external-ip=external-ip-of-service] [--type=type] [flags] | 将副本控制器、服务或 Pod 作为新的 Kubernetes 服务暴露。 `get`        | kubectl get (-f FILENAME | TYPE [NAME | /NAME | -l label]) [--watch] [--sort-by=FIELD] [[-o | --output]=OUTPUT_FORMAT] [flags] | 列出一个或多个资源。 `kustomize`    | kubectl kustomize <dir> [flags] [options]` </code> | 列出从 kustomization.yaml 文件中的指令生成的一组 API 资源。参数必须是包含文件的目录的路径，或者是 git 存储库 URL，其路径后缀相对于存储库根目录指定了相同的路径。 <!-- </del> `label`        | kubectl label (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags] | Add or update the labels of one or more resources. `logs`        | `kubectl logs POD [-c CONTAINER] [--follow] [flags]` | Print the logs for a container in a pod. `options`    | `kubectl options` | List of global command-line options, which apply to all commands.


`replace`        | `kubectl replace -f FILENAME` | Replace a resource from a file or stdin. `rollout`    | `kubectl rollout SUBCOMMAND [options]` | Manage the rollout of a resource. Valid resource types include: deployments, daemonsets and statefulsets. `run`        | kubectl run NAME --image=image [--env="key=value"] [--port=port] [--dry-run=server|client|none] [--overrides=inline-json] [flags] | Run a specified image on the cluster.  `scale`        | kubectl scale (-f FILENAME | TYPE NAME | TYPE/NAME) --replicas=COUNT [--resource-version=version] [--current-replicas=count] [flags] | Update the size of the specified replication controller. `set`    | `kubectl set SUBCOMMAND [options]` | Configure application resources. `taint`    | `kubectl taint NODE NAME KEY_1=VAL_1:TAINT_EFFECT_1 ... KEY_N=VAL_N:TAINT_EFFECT_N [options]` | Update the taints on one or more nodes. `top`    | `kubectl top [flags] [options]` | Display Resource (CPU/Memory/Storage) usage. `uncordon`    | `kubectl uncordon NODE [options]` | Mark node as schedulable. `version`        | `kubectl version [--client] [flags]` | Display the Kubernetes version running on the client and server. `wait`    | kubectl wait ([-f FILENAME] | resource.group/resource.name | resource.group [(-l label | --all)]) [--for=delete|--for condition=available] [options] | Experimental: Wait for a specific condition on one or many resources.  -->  操作             | 语法      |       描述 -------------------- | -------------------- | -------------------- `alpha`    | `kubectl alpha SUBCOMMAND [flags]` | 列出与 alpha 特性对应的可用命令，这些特性在 Kubernetes 集群中默认情况下是不启用的。 `annotate`    | kubectl annotate (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags] | 添加或更新一个或多个资源的注解。 `api-resources`    | `kubectl api-resources [flags]` | 列出可用的 API 资源。 `api-versions`    | `kubectl api-versions [flags]` | 列出可用的 API 版本。 `apply`            | `kubectl apply -f FILENAME [flags]`| 从文件或 stdin 对资源应用配置更改。 `attach`        | `kubectl attach POD -c CONTAINER [-i] [-t] [flags]` | 挂接到正在运行的容器，查看输出流或与容器（stdin）交互。 `auth`    | `kubectl auth [flags] [options]` | 检查授权。 `autoscale`    | kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU] [flags] | 自动扩缩由副本控制器管理的一组 pod。 `certificate`    | `kubectl certificate SUBCOMMAND [options]` | 修改证书资源。 `cluster-info`    | `kubectl cluster-info [flags]` | 显示有关集群中主服务器和服务的端口信息。 `completion`    | `kubectl completion SHELL [options]` | 为指定的 Shell（Bash 或 Zsh）输出 Shell 补齐代码。 `config`        | `kubectl config SUBCOMMAND [flags]` | 修改 kubeconfig 文件。有关详细信息，请参阅各个子命令。 `convert`    | `kubectl convert -f FILENAME [options]` | 在不同的 API 版本之间转换配置文件。配置文件可以是 YAML 或 JSON 格式。注意 - 需要安装 `kubectl-convert` 插件。 `cordon`    | `kubectl cordon NODE [options]` | 将节点标记为不可调度。 `cp`    | `kubectl cp <file-spec-src> <file-spec-dest> [options]` | 从容器复制文件、目录或将文件、目录复制到容器。 `create`        | `kubectl create -f FILENAME [flags]` | 从文件或 stdin 创建一个或多个资源。 `delete`        |  kubectl delete (-f FILENAME | TYPE [NAME | /NAME | -l label | --all]) [flags] |  基于文件、标准输入或通过指定标签选择器、名称、资源选择器或资源本身，删除资源。 `describe`    | kubectl describe (-f FILENAME | TYPE [NAME_PREFIX | /NAME | -l label]) [flags] | 显示一个或多个资源的详细状态。 `diff`        | `kubectl diff -f FILENAME [flags]`| 在当前起作用的配置和文件或标准输之间作对比 (**BETA**) `drain`    | `kubectl drain NODE [options]` | 腾空节点以准备维护。 `edit`        | kubectl edit (-f FILENAME | TYPE NAME | TYPE/NAME) [flags] | 使用默认编辑器编辑和更新服务器上一个或多个资源的定义。 `exec`        | `kubectl exec POD [-c CONTAINER] [-i] [-t] [flags] [-- COMMAND [args...]]` | 对 Pod 中的容器执行命令。 `explain`    | `kubectl explain  [--recursive=false] [flags]` | 获取多种资源的文档。例如 Pod、Node、Service 等。 `expose`        | kubectl expose (-f FILENAME | TYPE NAME | TYPE/NAME) [--port=port] [--protocol=TCP|UDP] [--target-port=number-or-name] [--name=name] [--external-ip=external-ip-of-service] [--type=type] [flags] | 将副本控制器、服务或 Pod 作为新的 Kubernetes 服务暴露。 `get`        | kubectl get (-f FILENAME | TYPE [NAME | /NAME | -l label]) [--watch] [--sort-by=FIELD] [[-o | --output]=OUTPUT_FORMAT] [flags] | 列出一个或多个资源。 `kustomize`    | kubectl kustomize <dir> [flags] [options]` </code> | 列出从 kustomization.yaml 文件中的指令生成的一组 API 资源。参数必须是包含文件的目录的路径，或者是 git 存储库 URL，其路径后缀相对于存储库根目录指定了相同的路径。 </ins> `label`        | <code>kubectl label (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags]</code> | 添加或更新一个或多个资源的标签。 `logs`        | `kubectl logs POD [-c CONTAINER] [--follow] [flags]` |  打印 Pod 中容器的日志。 `options`    | `kubectl options` | 全局命令行选项列表，这些选项适用于所有命令。


`replace`        | `kubectl replace -f FILENAME` |  基于文件或标准输入替换资源。 `rollout`    | `kubectl rollout SUBCOMMAND [options]` | 管理资源的上线。有效的资源类型包括：Deployment、 DaemonSet 和 StatefulSet。 `run`        | kubectl run NAME --image=image [--env="key=value"] [--port=port] [--dry-run=server | client | none] [--overrides=inline-json] [flags] | 在集群上运行指定的镜像。    `scale`        | kubectl scale (-f FILENAME | TYPE NAME | TYPE/NAME) --replicas=COUNT [--resource-version=version] [--current-replicas=count] [flags] | 更新指定副本控制器的大小。 `set`    | `kubectl set SUBCOMMAND [options]` | 配置应用资源。 `taint`    | `kubectl taint NODE NAME KEY_1=VAL_1:TAINT_EFFECT_1 ... KEY_N=VAL_N:TAINT_EFFECT_N [options]` | 更新一个或多个节点上的污点。


Patch your Deployment again with this new patch: ```shell <del> kubectl patch deployment retainkeys-demo --type merge --patch-file patch-file-retainkeys.yaml </del> <ins> kubectl patch deployment retainkeys-demo --type strategic --patch-file patch-file-retainkeys.yaml </ins> ``` Examine the content of the Deployment:


See [Enforcing Pod Security at the Namespace Level](/docs/concepts/security/pod-security-admission) for more information. <ins> ### rbac.authorization.kubernetes.io/autoupdate Example: `rbac.authorization.kubernetes.io/autoupdate: "false"` Used on: ClusterRole, ClusterRoleBinding, Role, RoleBinding When this annotation is set to `"true"` on default RBAC objects created by the kube-apiserver, they are automatically updated at server start to add missing permissions and subjects (extra permissions and subjects are left in place). To prevent autoupdating a particular role or rolebinding, set this annotation to `"false"`. If you create your own RBAC objects and set this annotation to `"false"`, `kubectl auth reconcile` (which allows reconciling arbitrary RBAC objects in a {{< glossary_tooltip text="manifest" term_id="manifest" >}}) respects this annotation and does not automatically add missing permissions and subjects. </ins> ### kubernetes.io/psp (deprecated) {#kubernetes-io-psp} Example: `kubernetes.io/psp: restricted`


### Submitting Documentation Pull Requests <del> If you're fixing an issue in the existing documentation, you should submit a PR against the main branch.  Follow [these instructions to create a documentation pull request against the kubernetes.io repository](http://kubernetes.io/docs/home/contribute/create-pull-request/). </del> <ins> If you're fixing an issue in the existing documentation, you should submit a PR against the main branch.  Follow [these instructions to create a documentation pull request against the kubernetes.io repository](https://kubernetes.io/docs/contribute/new-content/open-a-pr/). </ins> For more information, see [contributing to Kubernetes docs](https://kubernetes.io/docs/contribute/).


[plugin](/docs/concepts/storage/volumes/#types-of-volumes). The following broad classes of Kubernetes volume plugins are supported on Windows: <del> * [`FlexVolume plugins`](/docs/concepts/storage/volumes/#flexVolume) </del> <ins> * [`FlexVolume plugins`](/docs/concepts/storage/volumes/#flexvolume-deprecated) </ins> * Please note that FlexVolumes have been deprecated as of 1.23 * [`CSI Plugins`](/docs/concepts/storage/volumes/#csi)


## What is a Pod? {{< note >}} <del> While Kubernetes supports more {{< glossary_tooltip text="container runtimes" term_id="container-runtime" >}} than just Docker, [Docker](https://www.docker.com/) is the most commonly known runtime, and it helps to describe Pods using some terminology from Docker. </del> <ins> You need to install a [container runtime](/docs/setup/production-environment/container-runtimes/) into each node in the cluster so that Pods can run there. </ins> {{< /note >}} The shared context of a Pod is a set of Linux namespaces, cgroups, and


{{< note >}} If you use a Docker credentials store, you won't see that `auth` entry but a `credsStore` entry with the name of the store as value. <ins> In that case, you can create a secret directly. See [Create a Secret by providing credentials on the command line](#create-a-secret-by-providing-credentials-on-the-command-line). </ins> {{< /note >}} ## Create a Secret based on existing credentials {#registry-secret-existing-credentials}


<ins> --- title: रेप्लिकासेट (ReplicaSet) id: replica-set date: 2018-04-12 full_link: /docs/concepts/workloads/controllers/replicaset/ short_description: > रेप्लिकासेट यह सुनिश्चित करता है कि किसी एक अवसर पर निर्दिष्ट संख्या में पॉड प्रतिकृतियां चल रही हैं। aka: tags: - fundamental - core-object - workload --- एक रेप्लिकासेट (का उद्देश्य) किसी भी समय चल रहे रेप्लिका पॉड्स का एक समूह बनाए रखना है। <!--more--> वर्कलोड ऑब्जेक्ट्स, जैसे {{< glossary_tooltip text="डिप्लॉयमेंट" term_id="deployment" >}}, रेप्लिकासेट्स के विनिर्देश के आधार पर आपके क्लस्टर पर कॉन्फ़िगर की गई संख्या में {{< glossary_tooltip term_id="pod" text="पॉड्स" >}} चल रहे है ये सुनिश्चित करते हैं। </ins>


durable external storage, or provide ephemeral storage, or they might offer a read-only interface to information using a filesystem paradigm. <del> Kubernetes also includes support for [FlexVolume](/docs/concepts/storage/volumes/#flexvolume) plugins, </del> <ins> Kubernetes also includes support for [FlexVolume](/docs/concepts/storage/volumes/#flexvolume-deprecated) plugins, </ins> 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


* [`gcePersistentDisk`](#gcepersistentdisk) * [`vsphereVolume`](#vspherevolume) <del> ### flexVolume (deprecated) </del> <ins> ### flexVolume (deprecated)   {#flexvolume} </ins> {{< feature-state for_k8s_version="v1.23" state="deprecated" >}}


[plugin](/docs/concepts/storage/volumes/#types-of-volumes). The following broad classes of Kubernetes volume plugins are supported on Windows: <del> * [`FlexVolume plugins`](/docs/concepts/storage/volumes/#flexvolume-deprecated) </del> <ins> * [`FlexVolume plugins`](/docs/concepts/storage/volumes/#flexvolume) </ins> * Please note that FlexVolumes have been deprecated as of 1.23 * [`CSI Plugins`](/docs/concepts/storage/volumes/#csi)


Details of the metric data that Kubernetes components export. --- <del> ## Metrics (v1.26) <!-- (auto-generated 2022 Nov 09) --> <!-- (auto-generated v1.26) --> </del> <ins> ## Metrics (auto-generated 2022 Nov 01) </ins> This page details the metrics that different Kubernetes components export. You can query the metrics endpoint for these components using an HTTP scrape, and fetch the current metrics data in Prometheus format.