jiebi/CodeConvo huggingface dataset:
<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. */}} <del> {{ $sidebarCacheLimit := cond (isset .Site.Params.ui "sidebar_cache_limit") .Site.Params.ui.sidebar_cache_limit 2000 }} {{ $shouldDelayActive := ge (len .Site.Pages) $sidebarCacheLimit }} </del> <ins> {{ $sidebarCacheLimit := cond (isset .Site.Params.ui "sidebar_cache_limit") .Site.Params.ui.sidebar_cache_limit 2000 -}} {{ $shouldDelayActive := ge (len .Site.Pages) $sidebarCacheLimit -}} </ins> <div id="td-sidebar-menu" class="td-sidebar__inner{{ if $shouldDelayActive }} d-none{{ end }}"> <del> {{ if not .Site.Params.ui.sidebar_search_disable }} </del> <ins> {{ if not .Site.Params.ui.sidebar_search_disable -}} </ins> <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> <del> {{ else }} </del> <ins> {{ else -}} </ins> <div id="content-mobile"> <form class="td-sidebar__search d-flex align-items-center"> {{ partial "search-input.html" . }}
</form> </div> <div id="content-desktop"></div> <del> {{ end }} </del> <ins> {{ end -}} </ins> <nav class="collapse td-sidebar-nav{{ if .Site.Params.ui.sidebar_menu_foldable }} foldable-nav{{ end }}" id="td-section-nav"> <!-- {{ if  (gt (len .Site.Home.Translations) 0) }} <div class="nav-item dropdown d-block d-lg-none">
<!-- 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>
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.
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)节。 本主题内容已移至:
`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 的重要性。
<!--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>}}
<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>
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
[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,