## Version skew policy {#version-skew-policy} <del> The `kubeadm` tool of version v{{< skew latestVersion >}} may deploy clusters with a control plane of version v{{< skew latestVersion >}} or v{{< skew prevMinorVersion >}}. `kubeadm` v{{< skew latestVersion >}} can also upgrade an existing kubeadm-created cluster of version v{{< skew prevMinorVersion >}}. </del> <ins> While kubeadm allows version skew against some components that it manages, it is recommended that you match the kubeadm version with the versions of the control plane components, kube-proxy and kubelet. </ins> <del> Due to that we can't see into the future, kubeadm CLI v{{< skew latestVersion >}} may or may not be able to deploy v{{< skew nextMinorVersion >}} clusters. </del> <ins> ### kubeadm's skew against the Kubernetes version </ins> <del> These resources provide more information on supported version skew between kubelets and the control plane, and other Kubernetes components: </del> <ins> kubeadm can be used with Kubernetes components that are the same version as kubeadm or one version older. The Kubernetes version can be specified to kubeadm by using the `--kubernetes-version` flag of `kubeadm init` or the [`ClusterConfiguration.kubernetesVersion`](/docs/reference/config-api/kubeadm-config.v1beta3/) field when using `--config`. This option will control the versions of kube-apiserver, kube-controller-manager, kube-scheduler and kube-proxy. </ins> <del> * Kubernetes [version and version-skew policy](/docs/setup/release/version-skew-policy/) * Kubeadm-specific [installation guide](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-kubeadm-kubelet-and-kubectl) </del> <ins> Example: * kubeadm is at {{< skew latestVersion >}} * `kubernetesVersion` must be at {{< skew latestVersion >}} or {{< skew prevMinorVersion >}} ### kubeadm's skew against the kubelet Similarly to the Kubernetes version, kubeadm can be used with a kubelet version that is the same version as kubeadm or one version older. Example: * kubeadm is at {{< skew latestVersion >}} * kubelet on the host must be at {{< skew latestVersion >}} or {{< skew prevMinorVersion >}} ### kubeadm's skew against kubeadm There are certain limitations on how kubeadm commands can operate on existing nodes or whole clusters managed by kubeadm. If new nodes are joined to the cluster, the kubeadm binary used for `kubeadm join` must match the last version of kubeadm used to either create the cluster with `kubeadm init` or to upgrade the same node with `kubeadm upgrade`. Similar rules apply to the rest of the kubeadm commands with the exception of `kubeadm upgrade`. Example for `kubeadm join`: * kubeadm version {{< skew latestVersion >}} was used to create a cluster with `kubeadm init` * Joining nodes must use a kubeadm binary that is at version {{< skew latestVersion >}} Nodes that are being upgraded must use a version of kubeadm that is the same MINOR version or one MINOR version newer than the version of kubeadm used for managing the node. Example for `kubeadm upgrade`: * kubeadm version {{< skew prevMinorVersion >}} was used to create or upgrade the node * The version of kubeadm used for upgrading the node must be at {{< skew prevMinorVersion >}} or {{< skew latestVersion >}} To learn more about the version skew between the different Kubernetes component see the [Version Skew Policy](https://kubernetes.io/releases/version-skew-policy/). </ins> ## Limitations {#limitations}


<ins> --- title: Tutoriais main_menu: true no_list: true weight: 60 content_type: concept --- <!-- overview --> Essa seção da documentação contém tutoriais (em inglês). Um tutorial mostra como realizar um objetivo mais complexo que uma simples [tarefa](/docs/tasks/). Eles podem ser divididos em diversas seções, cada uma com uma sequência de passos e etapas a serem seguidos. Antes de iniciar um tutorial, é interessante que vocẽ salve a página de [Glossário](/pt/docs/reference/glossary/) para futuras referências. <!-- body --> ## Básicos * [Kubernetes básico](/docs/tutorials/kubernetes-basics/) é um tutorial interativo que auxilia no entendimento do ecossistema Kubernetes, bem como te permite testar algumas funcionalidades básicas do Kubernetes. * [Introdução ao Kubernetes (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x#) é um curso gratuíto da edX que te guia no entendimento do Kubernetes, seus conceitos, bem como na execução de tarefas mais simples. * [Hello Minikube](/docs/tutorials/hello-minikube/) é um "Hello World" que te permite testar rapidamente o Kubernetes em sua estação com o uso do Minikube ## Configuração * [Configurando o Redis usando um ConfigMap](/docs/tutorials/configuration/configure-redis-using-configmap/) ## Aplicações stateless * [Expondo um Endereço de IP externo para acessar uma aplicação no Cluster](/docs/tutorials/stateless-application/expose-external-ip-address/) * [Exemplo: Implantando a aplicação de Livro de Visitas (Guestbook) em  PHP com Redis](/docs/tutorials/stateless-application/guestbook/) ## Aplicações stateful * [Básicos sobre StatefulSet](/docs/tutorials/stateful-application/basic-stateful-set/) * [Exemplo: WordPress e MySQL com Volumes Persistentes](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/) * [Exemplo: Implantando Cassandra com Stateful Sets](/docs/tutorials/stateful-application/cassandra/) * [Executando ZooKeeper no Kubernetes](/docs/tutorials/stateful-application/zookeeper/) ## Pipelines de CI/CD * [Configurando um Pipeline CI/CD com Kubernetes Parte 1: Visão Geral](https://www.linux.com/blog/learn/chapter/Intro-to-Kubernetes/2017/5/set-cicd-pipeline-kubernetes-part-1-overview) * [Configurando um Pipeline CI/CD com um Pod Jenkins no Kubernetes (Parte 2)](https://www.linux.com/blog/learn/chapter/Intro-to-Kubernetes/2017/6/set-cicd-pipeline-jenkins-pod-kubernetes-part-2) * [Executando e escalando um aplicativo distribuído de palavras cruzadas com CI/CD no Kubernetes (Parte 3)](https://www.linux.com/blog/learn/chapter/intro-to-kubernetes/2017/6/run-and-scale-distributed-crossword-puzzle-app-cicd-kubernetes-part-3) * [Configurando um CI/CD para um aplicativo distribuído de palavras cruzadas no Kubernetes (Parte 4)](https://www.linux.com/blog/learn/chapter/intro-to-kubernetes/2017/6/set-cicd-distributed-crossword-puzzle-app-kubernetes-part-4) ## Clusters * [AppArmor](/docs/tutorials/clusters/apparmor/) ## Serviços / "Services" * [Usando IP de origem](/docs/tutorials/services/source-ip/) ## {{% heading "whatsnext" %}} Se você desejar escrever um tutorial, veja a página [Utilizando templates](/docs/home/contribute/page-templates/) para informações sobre o tipo de página e o formato a ser utilizado. </ins>


The value for this annotation must be **true** to take effect. This annotation indicates that pods running as this service account may only reference Secret API objects specified in the service account's `secrets` field. <ins> ### node.kubernetes.io/exclude-from-external-load-balancer Example: `node.kubernetes.io/exclude-from-external-load-balancer` Used on: Node Kubernetes automatically enables the `ServiceNodeExclusion` feature gate on the clusters it creates. With this feature gate enabled on a cluster, you can add labels to particular worker nodes to exclude them from the list of backend servers. The following command can be used to exclude a worker node from the list of backend servers in a backend set- `kubectl label nodes <node-name> node.kubernetes.io/exclude-from-external-load-balancers=true` </ins> ### controller.kubernetes.io/pod-deletion-cost {#pod-deletion-cost} Example: `controller.kubernetes.io/pod-deletion-cost: "10"`


| Scala                | [github.com/hagay3/skuber](https://github.com/hagay3/skuber) | | Scala                | [github.com/joan38/kubernetes-client](https://github.com/joan38/kubernetes-client) | | Swift                | [github.com/swiftkube/client](https://github.com/swiftkube/client) | <del> | DotNet               | [github.com/tonnyeremin/kubernetes_gen](https://github.com/tonnyeremin/kubernetes_gen) | | DotNet (RestSharp)   | [github.com/masroorhasan/Kubernetes.DotNet](https://github.com/masroorhasan/Kubernetes.DotNet) | | Elixir               | [github.com/obmarg/kazan](https://github.com/obmarg/kazan/) | | Elixir               | [github.com/coryodaniel/k8s](https://github.com/coryodaniel/k8s) | </del>


## Letting iptables see bridged traffic <ins> Make sure that the `br_netfilter` module is loaded. This can be done by running `lsmod | grep br_netfilter`. To load it explicitly call `sudo modprobe br_netfilter`. </ins> As a requirement for your Linux Node's iptables to correctly see bridged traffic, you should ensure `net.bridge.bridge-nf-call-iptables` is set to 1 in your `sysctl` config, e.g. ```bash


The Master is responsible for managing the cluster. The master coordinates all activities in your cluster, such as scheduling applications, maintaining applications' desired state, scaling applications, and rolling out new updates.

A node is a VM or a physical computer that serves as a worker machine in a Kubernetes cluster. Each node has a Kubelet, which is an agent for managing the node and communicating with the Kubernetes master. The node should also have tools for handling container operations, such as Docker or rtk. A Kubernetes cluster that handles production traffic should have a minimum of three nodes.

A node is a VM or a physical computer that serves as a worker machine in a Kubernetes cluster. Each node has a Kubelet, which is an agent for managing the node and communicating with the Kubernetes master. The node should also have tools for handling container operations, such as Docker or rkt. A Kubernetes cluster that handles production traffic should have a minimum of three nodes.


1. Run the following: <del> ```sh ./etcd --listen-client-urls=http://$PRIVATE_IP:2379 --advertise-client-urls=http://$PRIVATE_IP:2379 ``` </del> <ins> ```sh etcd --listen-client-urls=http://$PRIVATE_IP:2379  --advertise-client-urls=http://$PRIVATE_IP:2379 ``` </ins> <del> 2. Start Kubernetes API server with the flag `--etcd-servers=$PRIVATE_IP:2379`. </del> <ins> 2. Start the Kubernetes API server with the flag `--etcd-servers=$PRIVATE_IP:2379`. </ins> <del> Replace `PRIVATE_IP` with your etcd client IP. </del> <ins> Make sure `PRIVATE_IP` is set to your etcd client IP. </ins> ### Multi-node etcd cluster <del> For durability and high availability, run etcd as a multi-node cluster in production and back it up periodically. A five-member cluster is recommended in production. For more information, see [FAQ Documentation](https://github.com/coreos/etcd/blob/master/Documentation/faq.md#what-is-failure-tolerance). </del> <ins> For durability and high availability, run etcd as a multi-node cluster in production and back it up periodically. A five-member cluster is recommended in production. For more information, see [FAQ documentation](https://etcd.io/docs/current/faq/#what-is-failure-tolerance). </ins> <del> Configure an etcd cluster either by static member information or by dynamic discovery. For more information on clustering, see [etcd Clustering Documentation](https://github.com/coreos/etcd/blob/master/Documentation/op-guide/clustering.md). </del> <ins> Configure an etcd cluster either by static member information or by dynamic discovery. For more information on clustering, see [etcd clustering documentation](https://etcd.io/docs/current/op-guide/clustering/). </ins> <del> For an example, consider a five-member etcd cluster running with the following client URLs: `http://$IP1:2379`, `http://$IP2:2379`, `http://$IP3:2379`, `http://$IP4:2379`, and `http://$IP5:2379`. To start a Kubernetes API server: </del> <ins> For an example, consider a five-member etcd cluster running with the following client URLs: `http://$IP1:2379`, `http://$IP2:2379`, `http://$IP3:2379`, `http://$IP4:2379`, and `http://$IP5:2379`. To start a Kubernetes API server: </ins> 1. Run the following: <del> ```sh ./etcd --listen-client-urls=http://$IP1:2379, http://$IP2:2379, http://$IP3:2379, http://$IP4:2379, http://$IP5:2379 --advertise-client-urls=http://$IP1:2379, http://$IP2:2379, http://$IP3:2379, http://$IP4:2379, http://$IP5:2379 ``` </del> <ins> ```shell etcd --listen-client-urls=http://$IP1:2379,http://$IP2:2379,http://$IP3:2379,http://$IP4:2379,http://$IP5:2379 --advertise-client-urls=http://$IP1:2379,http://$IP2:2379,http://$IP3:2379,http://$IP4:2379,http://$IP5:2379 ``` </ins> <del> 2. Start Kubernetes API servers with the flag `--etcd-servers=$IP1:2379, $IP2:2379, $IP3:2379, $IP4:2379, $IP5:2379`. </del> <ins> 2. Start the Kubernetes API servers with the flag `--etcd-servers=$IP1:2379,$IP2:2379,$IP3:2379,$IP4:2379,$IP5:2379`. </ins> <del> Replace `IP` with your client IP addresses. </del> <ins> Make sure the `IP<n>` variables are set to your client IP addresses. </ins> <del> ###  Multi-node etcd cluster with load balancer </del> <ins> ### Multi-node etcd cluster with load balancer </ins> To run a load balancing etcd cluster:


<!--script src="https://unpkg.com/split.js/dist/split.min.js"></script--> <script src="/js/split-1.6.0.js" intregrity="sha384-0blL3GqHy6+9fw0cyY2Aoiwg4onHAtslAs4OkqZY7UQBrR65/K4gI+hxLdWDrjpz"></script> <ins> <!--Script for dismissing banners/notices--> <script defer src="{{ "js/dismiss_banner.js" | relURL }}"></script> </ins> {{- if or (.HasShortcode "table")  (.HasShortcode "feature-gate-table") -}} <script defer src="{{ "js/sortable-table.js" | relURL }}"></script> {{- end -}}


- `Count`: Podがデフォルトの方法で処理されるべきであることを示します。`.spec.backoffLimit`のカウンターが加算されます。 {{< note >}} <del> `PodFailurePolicy`を使用すると、Jobコントローラは`Failed`フェーズのPodのみにマッチします。削除タイムスタンプを持つPodで、終了フェーズ(`Failed`または`Succeeded`)にないものは、まだ終了中と見なされます。これは、終了中Podは終了フェーズに達するまで[追跡ファイナライザー](#job-tracking-with-finalizers)を保持することを意味します。Kubernetes 1.27以降、Kubeletは削除されたPodを終了フェーズに遷移させます(参照:[Podのフェーズ](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase))。これにより、削除されたPodはJobコントローラーによってファイナライザーが削除されます。 </del> <ins> `PodFailurePolicy`を使用すると、Jobコントローラーは`Failed`フェーズのPodのみにマッチします。削除タイムスタンプを持つPodで、終了フェーズ(`Failed`または`Succeeded`)にないものは、まだ終了中と見なされます。これは、終了中Podは終了フェーズに達するまで[追跡ファイナライザー](#job-tracking-with-finalizers)を保持することを意味します。Kubernetes 1.27以降、Kubeletは削除されたPodを終了フェーズに遷移させます(参照:[Podのフェーズ](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase))。これにより、削除されたPodはJobコントローラーによってファイナライザーが削除されます。 </ins> {{< /note >}} ## Jobの終了とクリーンアップ  {#job-termination-and-cleanup}


} ``` <ins> ## Create Pod that uses the container runtime default seccomp profile Most container runtimes provide a sane set of default syscalls that are allowed or not. You can adopt these defaults for your workload by setting the seccomp type in the security context of a pod or container to `RuntimeDefault`. {{< note >}} If you have the `SeccompDefault` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) enabled, then Pods use the `RuntimeDefault` seccomp profile whenever no other seccomp profile is specified. Otherwise, the default is `Unconfined`. {{< /note >}} Here's a manifest for a Pod that requests the `RuntimeDefault` seccomp profile for all its containers: {{< codenew file="pods/security/seccomp/ga/default-pod.yaml" >}} Create that Pod: ```shell kubectl apply -f https://k8s.io/examples/pods/security/seccomp/ga/default-pod.yaml ``` ```shell kubectl get pod default-pod ``` The Pod should be showing as having started successfully: ``` NAME        READY   STATUS    RESTARTS   AGE default-pod 1/1     Running   0          20s ``` Finally, now that you saw that work OK, clean up: ```shell kubectl delete pod default-pod --wait --now ``` </ins> ## Create a Pod with a seccomp profile for syscall auditing To start off, apply the `audit.json` profile, which will log all syscalls of the


[the design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md). ### Summary API Source <del> The [Kubelet](/docs/reference/command-line-tools-reference/kubelet/) gathers stats at node, volume, pod and container level, and omits them in the [Summary API](https://github.com/kubernetes/kubernetes/blob/7d309e0104fedb57280b261e5677d919cb2a0e2d/staging/src/k8s.io/kubelet/pkg/apis/stats/v1alpha1/types.go) </del> <ins> The [Kubelet](/docs/reference/command-line-tools-reference/kubelet/) gathers stats at node, volume, pod and container level, and emits their statistics in the [Summary API](https://github.com/kubernetes/kubernetes/blob/7d309e0104fedb57280b261e5677d919cb2a0e2d/staging/src/k8s.io/kubelet/pkg/apis/stats/v1alpha1/types.go) </ins> for consumers to read. Pre-1.23, these resources have been primarily gathered from [cAdvisor](https://github.com/google/cadvisor). However, in 1.23 with the


<ins> --- title: "从 dockershim 迁移" weight: 10 content_type: task --- <!-- title: "Migrating from dockershim" weight: 10 content_type: task --> <!-- overview --> <!-- This section presents information you need to know when migrating from dockershim to other container runtimes. --> 本节提供从 dockershim 迁移到其他容器运行时的必备知识。 <!-- Since the announcement of [dockershim deprecation](/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation) in Kubernetes 1.20, there were questions on how this will affect various workloads and Kubernetes installations. You can find this blog post useful to understand the problem better: [Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/) --> 自从 Kubernetes 1.20 宣布 [弃用 dockershim](/zh/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation)， 各类疑问随之而来：这对各类工作负载和 Kubernetes 部署会产生什么影响。 你会发现这篇博文对于更好地理解此问题非常有用： [弃用 Dockershim 常见问题](/zh/blog/2020/12/02/dockershim-faq/) <!-- It is recommended to migrate from dockershim to alternative container runtimes. Check out [container runtimes](/docs/setup/production-environment/container-runtimes/) section to know your options. Make sure to [report issues](https://github.com/kubernetes/kubernetes/issues) you encountered with the migration. So the issue can be fixed in a timely manner and your cluster would be ready for dockershim removal. --> 建议从 dockershim 迁移到其他替代的容器运行时。 请参阅[容器运行时](/zh/docs/setup/production-environment/container-runtimes/) 一节以了解可用的备选项。 当在迁移过程中遇到麻烦，请[上报问题](https://github.com/kubernetes/kubernetes/issues)。 那么问题就可以及时修复，你的集群也可以进入移除 dockershim 前的就绪状态。 </ins>


<ins> --- layout: blog title: "dl.k8s.io 采用内容分发网络（CDN）" date: 2023-06-09 slug: dl-adopt-cdn --- <!-- layout: blog title: "dl.k8s.io to adopt a Content Delivery Network" date: 2023-06-09 slug: dl-adopt-cdn --> <!-- **Authors**: Arnaud Meukam (VMware), Hannah Aubry (Fast Forward), Frederico Muñoz (SAS Institute) --> **作者**：Arnaud Meukam (VMware), Hannah Aubry (Fast Forward), Frederico Muñoz (SAS Institute) **译者**：[Xin Li](https://github.com/my-git9) (Daocloud) <!-- We're happy to announce that dl.k8s.io, home of the official Kubernetes binaries, will soon be powered by [Fastly](https://www.fastly.com). Fastly is known for its high-performance content delivery network (CDN) designed to deliver content quickly and reliably around the world. With its powerful network, Fastly will help us deliver official Kubernetes binaries to users faster and more reliably than ever before. --> 我们很高兴地宣布，官方 Kubernetes 二进制文件的主页 dl.k8s.io 很快将由 [Fastly](https://www.fastly.com) 提供支持。 Fastly 以其高性能内容分发网络（CDN）而闻名， 该网络旨在全球范围内快速可靠地分发内容。凭借其强大的网络，Fastly 将帮助我们实现比以往更快、更可靠地向用户分发官方 Kubernetes 二进制文件。 <!-- The decision to use Fastly was made after an extensive evaluation process in which we carefully evaluated several potential content delivery network providers. Ultimately, we chose Fastly because of their commitment to the open internet and proven track record of delivering fast and secure digital experiences to some of the most known open source projects (through their [Fast Forward](https://www.fastly.com/fast-forward) program). --> 使用 Fastly 是在经过广泛的评估过程后做出的决定， 在该过程中我们仔细评估了几个潜在的内容分发网络提供商。最终，我们选择 Fastly 是因为他们对开放互联网的承诺以及在为一些著名的开源项目（通过他们的 [Fast Forward](https://www.fastly.com/fast-forward) 计划）提供快速和安全的数字体验方面的良好记录。 <!-- ## What you need to know about this change - On Monday, July 24th, the IP addresses and backend storage associated with the dl.k8s.io domain name will change. - The change will not impact the vast majority of users since the domain name will remain the same. - If you restrict access to specific IP ranges, access to the dl.k8s.io domain could stop working. --> ## 关于本次更改你需要了解的信息 - 7 月 24 日星期一，与 dl.k8s.io 域名关联的 IP 地址和后端存储将发生变化。 - 由于域名将保持不变，因此更改不会影响绝大多数用户。 - 如果你限制对特定 IP 范围的访问，则对 dl.k8s.io 域的访问可能会停止工作。 <!-- If you think you may be impacted or want to know more about this change, please keep reading. --> 如果你认为你可能会受到影响或想了解有关此次更改的更多信息，请继续阅读。 <!-- ## Why are we making this change The official Kubernetes binaries site, dl.k8s.io, is used by thousands of users all over the world, and currently serves _more than 5 petabytes of binaries each month_. This change will allow us to improve access to those resources by leveraging a world-wide CDN. --> ## 我们为什么要进行此更改 官方 Kubernetes 二进制文件网站 dl.k8s.io 被全世界成千上万的用户使用， 目前**每月提供超过 5 PB 的二进制文件服务**。本次更改将通过充分利用全球 CDN 来改善对这些资源的访问。 <!-- ## Does this affect dl.k8s.io only, or are other domains also affected? Only dl.k8s.io will be affected by this change. --> ## 这只影响 dl.k8s.io，还是其他域也受到影响？ 只有 dl.k8s.io 会受到本次变更的影响。 <!-- ## My company specifies the domain names that we are allowed to be accessed. Will this change affect the domain name? No, the domain name (`dl.k8s.io`) will remain the same: no change will be necessary, and access to the Kubernetes release binaries site should not be affected. --> ## 我公司规定了允许我们访问的域名，此更改会影响域名吗？ 不，域名（`dl.k8s.io`）将保持不变：无需更改，不会影响对 Kubernetes 发布二进制文件站点的访问。 <!-- ## My company uses some form of IP filtering. Will this change affect access to the site? If IP-based filtering is in place, it’s possible that access to the site will be affected when the new IP addresses become active. --> ## 我的公司使用某种形式的 IP 过滤，此更改会影响对站点的访问吗？ 如果已经存在基于 IP 的过滤，则当新 IP 地址变为活动状态时，对站点的访问可能会受到影响。 <!-- ## If my company doesn’t use IP addresses to restrict network traffic, do we need to do anything? No, the switch to the CDN should be transparent. --> ## 如果我的公司不使用 IP 地址来限制网络流量，我们需要做些什么吗？ 不，切换到 CDN 的过程应该是透明的。 <!-- ## Will there be a dual running period? **No, it is a cutover.** You can, however, test your networks right now to check if they can route to the new public IP addresses from Fastly.  You should add the new IPs to your network's `allowlist` before July 24th. Once the transfer is complete, ensure your networks use the new IP addresses to connect to the `dl.k8s.io` service. --> ## 会有双运行期吗？ **不，这是切换。**但是，你现在可以测试你的网络，检查它们是否可以从 Fastly 路由到新的公共 IP 地址。 你应该在 7 月 24 日之前将新 IP 添加到你网络的 `allowlist`（白名单）中。 切换完成后，确保你的网络使用新的 IP 地址连接到 `dl.k8s.io` 服务。 <!-- ## What are the new IP addresses? If you need to manage an allow list for downloads, you can get the ranges to match from the Fastly API, in JSON: [public IP address ranges](https://api.fastly.com/public-ip-list).  You don't need any credentials to download that list of ranges. --> ## 新 IP 地址是什么？ 如果你需要管理下载允许列表，你可以从 Fastly API 中获取需要匹配的范围， JSON 格式地址：[公共 IP 地址范围](https://api.fastly.com/public-ip-list)。 你不需要任何凭据即可下载该范围列表。 <!-- ## What next steps would you recommend? If you have IP-based filtering in place, we recommend the following course of action **before July, 24th**: --> ## 推荐哪些后续操作？ 如果你已经有了基于 IP 的过滤，我们建议你**在 7 月 24 日**之前采取以下行动： <!-- - Add the new IP addresses to your allowlist. - Conduct tests with your networks/firewall to ensure your networks can route to the new IP addresses. After the change is made, we recommend double-checking that HTTP calls are accessing dl.k8s.io with the new IP addresses. --> - 将新的 IP 地址添加到你的白名单。 - 对你的网络/防火墙进行测试，以确保你的网络可以路由到新的 IP 地址。 进行更改后，我们建议仔细检查 HTTP 调用是否正在使用新 IP 地址访问 dl.k8s.io。 <!-- ## What should I do if I detect some abnormality after the cutover date? If you encounter any weirdness during binaries download, please [open an issue](https://github.com/kubernetes/k8s.io/issues/new/choose). --> ## 切换后发现异常怎么办？ 如果你在二进制文件下载过程中遇到任何异常， 请[提交 Issue](https://github.com/kubernetes/k8s.io/issues/new/choose)。 </ins>


{{< glossary_tooltip text="PersistentVolumeClaim" term_id="persistent-volume-claim" >}} is being created from a VolumeSnapshot. <del> Refer to [Converting the volume mode of a Snapshot](/docs/concepts/storage/volume-snapshots/#convert-volume-mode) </del> <ins> Refer to [Converting the volume mode of a Snapshot](/docs/concepts/storage/volume-snapshots/#convert-volume-mode) </ins> and the [Kubernetes CSI Developer Documentation](https://kubernetes-csi.github.io/docs/) for more information. ## Annotations used for audit


#### Creating a Secret with a Docker config <ins> You need to know the username, registry password and client email address for authenticating to the registry, as well as its hostname. </ins> Run the following command, substituting the appropriate uppercase values: ```shell


## IBM Cloud Kubernetes Service ### Compute nodes <del> By using the IBM Cloud Kubernetes Service provider, you can create clusters with a mixture of virtual and physical (bare metal) nodes in a single zone or across multiple zones in a region. For more information, see [Planning your cluster and worker node setup](https://cloud.ibm.com/docs/containers?topic=containers-plan_clusters#plan_clusters). </del> <ins> By using the IBM Cloud Kubernetes Service provider, you can create clusters with a mixture of virtual and physical (bare metal) nodes in a single zone or across multiple zones in a region. For more information, see [Planning your cluster and worker node setup](https://cloud.ibm.com/docs/containers?topic=containers-planning_worker_nodes). </ins> The name of the Kubernetes Node object is the private IP address of the IBM Cloud Kubernetes Service worker node instance.


Auditing allows cluster administrators to answer the following questions: --> <del> Kubernetes**审计（Auditing）**功能提供了与安全相关的、按时间顺序排列的记录集， </del> <ins> Kubernetes **审计（Auditing）** 功能提供了与安全相关的、按时间顺序排列的记录集， </ins> 记录每个用户、使用 Kubernetes API 的应用以及控制面自身引发的活动。 审计功能使得集群管理员能够回答以下问题：


the configurations portable. Service accounts are different from user accounts, which are authenticated <del> human users in the cluster. By default, user accounts don't exist in the Kubernetes API server; instead, the API server treats user identities as opaque </del> <ins> human users in the cluster. By default, user accounts don't exist in the Kubernetes API server; instead, the API server treats user identities as opaque </ins> data. You can authenticate as a user account using multiple methods. Some Kubernetes distributions might add custom extension APIs to represent user accounts in the API server.


<ins> --- title: Tarefas main_menu: true weight: 50 content_type: concept --- <!-- overview --> Essa seção da documentação contém páginas que mostram como executar tarefas individuais. Essas tarefas são organizadas em uma curta sequência de etapas e passos que te auxiliam a entender conceitos básicos. Se você desejar adicionar uma tarefa, verifique como [criar um Pull Request para a documentação](/docs/contribute/new-content/open-a-pr/). </ins>


* [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard) is a dashboard web interface for Kubernetes. <del> * [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s) is a tool for graphically visualizing your containers, pods, services etc. Use it in conjunction with a [Weave Cloud account](https://cloud.weave.works/) or host the UI yourself. </del> <ins> * [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s) is a tool for visualizing your containers, Pods, Services and more. </ins> ## Infrastructure


### hostPath {#hostpath} <ins> {{< warning >}} HostPath volumes present many security risks, and it is a best practice to avoid the use of HostPaths when possible. When a HostPath volume must be used, it should be scoped to only the required file or directory, and mounted as ReadOnly. If restricting HostPath acccess to specific directories through AdmissionPolicy, `volumeMounts` MUST be required to use `readOnly` mounts for the policy to be effective. {{< /warning >}} </ins> A `hostPath` volume mounts a file or directory from the host node's filesystem into your Pod. This is not something that most Pods will need, but it offers a powerful escape hatch for some applications.


sudo sysctl --system ``` <del> Verify that the `br_netfilter`, `overlay` modules are loaded by running below instructions: </del> <ins> Verify that the `br_netfilter`, `overlay` modules are loaded by running the following commands: </ins> ```bash lsmod | grep br_netfilter lsmod | grep overlay ``` <del> Verify that the `net.bridge.bridge-nf-call-iptables`, `net.bridge.bridge-nf-call-ip6tables`, `net.ipv4.ip_forward` system variables are set to 1 in your `sysctl` config by running below instruction: </del> <ins> Verify that the `net.bridge.bridge-nf-call-iptables`, `net.bridge.bridge-nf-call-ip6tables`, and `net.ipv4.ip_forward` system variables are set to `1` in your `sysctl` config by running the following command: </ins> ```bash sysctl net.bridge.bridge-nf-call-iptables net.bridge.bridge-nf-call-ip6tables net.ipv4.ip_forward ``` <del> ## Cgroup drivers </del> <ins> ## cgroup drivers </ins> On Linux, {{< glossary_tooltip text="control groups" term_id="cgroup" >}} are used to constrain resources that are allocated to processes. <del> Both {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} and the </del> <ins> Both the {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} and the </ins> underlying container runtime need to interface with control groups to enforce <del> [resource management for pods and containers](/docs/concepts/configuration/manage-resources-containers/) and set resources such as cpu/memory requests and limits. To interface with control </del> <ins> [resource management for pods and containers](/docs/concepts/configuration/manage-resources-containers/) and set resources such as cpu/memory requests and limits. To interface with control </ins> groups, the kubelet and the container runtime need to use a *cgroup driver*. <del> It's critical that the kubelet and the container runtime uses the same cgroup </del> <ins> It's critical that the kubelet and the container runtime use the same cgroup </ins> driver and are configured the same. There are two cgroup drivers available:


Kubernetes supports many types of volumes. A {{< glossary_tooltip term_id="pod" text="Pod" >}} can use any number of volume types simultaneously. Ephemeral volume types have a lifetime of a pod, but persistent volumes exist beyond <del> the lifetime of a pod. Consequently, a volume outlives any containers that run within the pod, and data is preserved across container restarts. When a pod ceases to exist, Kubernetes destroys ephemeral volumes; however, Kubernetes does not destroy persistent volumes. </del> <ins> the lifetime of a pod. When a pod ceases to exist, Kubernetes destroys ephemeral volumes; however, Kubernetes does not destroy persistent volumes. For any kind of volume in a given pod, data is preserved across container restarts. </ins> At its core, a volume is just a directory, possibly with some data in it, which is accessible to the containers in a pod. How that directory comes to be, the


This includes any Pods created using `kubectl`, or indirectly via a replication controller. It does not include Pods created as a result of the kubelet `--manifest-url` flag, its `--config` flag, or its REST API (these are <del> not common ways to create Pods.) </del> <ins> not common ways to create Pods). The `spec` of a {{< glossary_tooltip text="static Pod" term_id="static-pod" >}} cannot refer to a Secret or any other API objects. </ins> Secrets must be created before they are consumed in Pods as environment variables unless they are marked as optional. References to secrets that do


{{< tabs name="tab-phase" >}} {{< tab name="phase" include="generated/kubeadm_upgrade_node_phase.md" />}} <ins> {{< tab name="preflight" include="generated/kubeadm_upgrade_node_phase_preflight.md" />}} </ins> {{< tab name="control-plane" include="generated/kubeadm_upgrade_node_phase_control-plane.md" />}} {{< tab name="kubelet-config" include="generated/kubeadm_upgrade_node_phase_kubelet-config.md" />}} {{< /tabs >}}


<ins> --- title: 在 macOS 系统上安装和设置 kubectl content_type: task weight: 10 card: name: tasks weight: 20 title: 在 macOS 系统上安装 kubectl --- <!-- --- reviewers: - mikedanese title: Install and Set Up kubectl on macOS content_type: task weight: 10 card: name: tasks weight: 20 title: Install kubectl on macOS --- --> ## {{% heading "prerequisites" %}} <!-- You must use a kubectl version that is within one minor version difference of your cluster. For example, a v1.2 client should work with v1.1, v1.2, and v1.3 master. Using the latest version of kubectl helps avoid unforeseen issues. --> kubectl 版本和集群之间的差异必须在一个小版本号之内。 例如：v1.2 版本的客户端只能与 v1.1、v1.2 和 v1.3 版本的集群一起工作。 用最新版本的 kubectl 有助于避免不可预见的问题。 <!-- ## Install kubectl on macOS --> ## 在 macOS 系统上安装 kubectl {#install-kubectl-on-macos} <!-- The following methods exist for installing kubectl on macOS: --> 在 macOS 系统上安装 kubectl 有如下方法： - [{{% heading "prerequisites" %}}](#{{% heading "prerequisites" %}}) - [在 macOS 系统上安装 kubectl](#install-kubectl-on-macos) - [用 curl 在 macOS 系统上安装 kubectl](#install-kubectl-binary-with-curl-on-macos) - [用 Homebrew 在 macOS 系统上安装](#install-with-homebrew-on-macos) - [用 Macports 在 macOS 上安装](#install-with-macports-on-macos) - [作为谷歌云 SDK 的一部分，在 macOS 上安装](#install-on-macos-as-part-of-the-google-cloud-sdk) - [验证 kubectl 配置](#verify-kubectl-configuration) - [可选的 kubectl 配置](#optional-kubectl-configurations) - [启用 shell 自动补全功能](#enable-shell-autocompletion) - [{{% heading "whatsnext" %}}](#{{% heading "whatsnext" %}}) <!-- ### Install kubectl binary with curl on macOS {#install-kubectl-binary-with-curl-on-macos} --> ### 用 curl 在 macOS 系统上安装 kubectl {#install-kubectl-binary-with-curl-on-macos} <!-- 1. Download the latest release: --> 1. 下载最新的发行版： ```bash curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl" ``` {{< note >}} <!-- To download a specific version, replace the `$(curl -L -s https://dl.k8s.io/release/stable.txt)` portion of the command with the specific version. For example, to download version {{< param "fullversion" >}} on macOS, type: --> 如果需要下载某个指定的版本，用该指定版本号替换掉命令的这个部分：`$(curl -L -s https://dl.k8s.io/release/stable.txt)`。 例如：要在 macOS 系统中下载 {{< param "fullversion" >}} 版本，则输入： ```bash curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl ``` {{< /note >}} <!-- 1. Validate the binary (optional) Download the kubectl checksum file: --> 1. 验证可执行文件（可选操作） 下载 kubectl 的校验和文件： ```bash curl -LO "https://dl.k8s.io/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl.sha256" ``` <!-- Validate the kubectl binary against the checksum file: --> 根据校验和文件，验证 kubectl： ```bash echo "$(<kubectl.sha256)  kubectl" | shasum -a 256 --check ``` <!-- If valid, the output is: --> 验证通过时，输出如下： ```console kubectl: OK ``` <!-- If the check fails, `shasum` exits with nonzero status and prints output similar to: --> 验证失败时，`shasum` 将以非零值退出，并打印如下输出： ``` kubectl: FAILED shasum: WARNING: 1 computed checksum did NOT match ``` {{< note >}} <!-- Download the same version of the binary and checksum. --> 下载的 kubectl 与校验和文件版本要相同。 {{< /note >}} <!-- 1. Make the kubectl binary executable. --> 1. 将 kubectl 置为可执行文件： ```bash chmod +x ./kubectl ``` <!-- 1. Move the kubectl binary to a file location on your system `PATH`. --> 1. 将可执行文件 kubectl 移动到系统可寻址路径 `PATH` 内的一个位置： ```bash sudo mv ./kubectl /usr/local/bin/kubectl sudo chown root: /usr/local/bin/kubectl ``` <!-- 1. Test to ensure the version you installed is up-to-date: --> 1. 测试一下，确保你安装的是最新的版本： ```bash kubectl version --client ``` <!-- ### Install with Homebrew on macOS {#install-with-homebrew-on-macos} --> ### 用 Homebrew 在 macOS 系统上安装 {#install-with-homebrew-on-macos} <!-- If you are on macOS and using [Homebrew](https://brew.sh/) package manager, you can install kubectl with Homebrew. --> 如果你是 macOS 系统，且用的是 [Homebrew](https://brew.sh/) 包管理工具， 则可以用 Homebrew 安装 kubectl。 <!-- 1. Run the installation command: --> 1. 运行安装命令： ```bash brew install kubectl ``` 或 ```bash brew install kubernetes-cli ``` <!-- 1. Test to ensure the version you installed is up-to-date: --> 1. 测试一下，确保你安装的是最新的版本： ```bash kubectl version --client ``` <!-- ### Install with Macports on macOS {#install-with-macports-on-macos} --> ### 用 Macports 在 macOS 上安装 {#install-with-macports-on-macos} <!-- If you are on macOS and using [Macports](https://macports.org/) package manager, you can install kubectl with Macports. --> 如果你用的是 macOS，且用 [Macports](https://macports.org/) 包管理工具，则你可以用 Macports 安装kubectl。 <!-- 1. Run the installation command: --> 1. 运行安装命令： ```bash sudo port selfupdate sudo port install kubectl ``` <!-- 1. Test to ensure the version you installed is up-to-date: --> 1. 测试一下，确保你安装的是最新的版本： ```bash kubectl version --client ``` <!-- ### Install on macOS as part of the Google Cloud SDK {#install-on-macos-as-part-of-the-google-cloud-sdk} --> ### 作为谷歌云 SDK 的一部分，在 macOS 上安装 {#install-on-macos-as-part-of-the-google-cloud-sdk} {{< include "included/install-kubectl-gcloud.md" >}} <!-- ## Verify kubectl configuration {#verify-kubectl-configuration} --> ## 验证 kubectl 配置 {#verify-kubectl-configuration} {{< include "included/verify-kubectl.md" >}} <!-- ## Optional kubectl configurations {#optional-kubectl-configurations} ### Enable shell autocompletion {#enable-shell-autocompletion} --> ## 可选的 kubectl 配置 {#optional-kubectl-configurations} ### 启用 shell 自动补全功能 {#enable-shell-autocompletion} <!-- kubectl provides autocompletion support for Bash and Zsh, which can save you a lot of typing. Below are the procedures to set up autocompletion for Bash and Zsh. --> kubectl 为 Bash 和 Zsh 提供自动补全功能，这可以节省许多输入的麻烦。 下面是为 Bash 和 Zsh 设置自动补全功能的操作步骤。 {{< tabs name="kubectl_autocompletion" >}} {{< tab name="Bash" include="included/optional-kubectl-configs-bash-mac.md" />}} {{< tab name="Zsh" include="included/optional-kubectl-configs-zsh.md" />}} {{< /tabs >}} ## {{% heading "whatsnext" %}} {{< include "included/kubectl-whats-next.md" >}} </ins>  No newline at end of file


{{< tab name="certificate-key" include="generated/kubeadm_alpha_certs_certificate-key.md" />}} {{< /tabs >}} <ins> ## kubeadm alpha certs generate-csr {#cmd-certs-generate-csr} This command can be used to generate certificate signing requests (CSRs) which can be submitted to a certificate authority (CA) for signing. {{< tabs name="tab-certs-generate-csr" >}} {{< tab name="certificate-generate-csr" include="generated/kubeadm_alpha_certs_generate-csr.md" />}} {{< /tabs >}} </ins> ## kubeadm alpha certs check-expiration {#cmd-certs-check-expiration} This command checks expiration for the certificates in the local PKI managed by kubeadm.


You can ignore this warning. You are only checking the version of `kubectl` that you have installed. {{< /note >}} Or use this for detailed view of version: ```cmd <del> kubectl version --client --output=yaml </del> <ins> kubectl version --client --output=yaml </ins> ``` ### Install using native package management


kind [Required]
  meta/v1.GroupVersionKind   meta/v1.GroupVersionKind
Kind is the fully-qualified type of object being submitted (for example, v1.Pod or autoscaling.v1.Scale)

resource [Required]
  meta/v1.GroupVersionResource   meta/v1.GroupVersionResource
Resource is the fully-qualified resource being requested (for example, v1.pods)


- [Kubernetes Python client library](https://github.com/kubernetes-client/python) - [Kubernetes Java client library](https://github.com/kubernetes-client/java) - [Kubernetes JavaScript client library](https://github.com/kubernetes-client/javascript) <ins> - [Kubernetes C# client library](https://github.com/kubernetes-client/csharp) - [Kubernetes Haskell client library](https://github.com/kubernetes-client/haskell) </ins> ## CLIリファレンス * [kubectl](/ja/docs/reference/kubectl/) - コマンドの実行やKubernetesクラスターの管理に使う主要なCLIツールです。 <del> * [JSONPath](/ja/docs/reference/kubectl/jsonpath/) - kubectlで[JSONPath記法](https://goessner.net/articles/JsonPath/)を使うための構文ガイドです。 </del> <ins> * [JSONPath](/ja/docs/reference/kubectl/jsonpath/) - kubectlで[JSONPath記法](https://goessner.net/articles/JsonPath/)を使うための構文ガイドです。 </ins> * [kubeadm](/ja/docs/reference/setup-tools/kubeadm/) - セキュアなKubernetesクラスターを簡単にプロビジョニングするためのCLIツールです。 ## コンポーネントリファレンス


Hit enter for command prompt <del> / # wget -s --timeout=1 nginx </del> <ins> / # wget --spider --timeout=1 nginx </ins> Connecting to nginx (10.100.0.16:80) / # ```


`zk-2` is scheduled. ```shell <del> kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data </del> <ins> kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data </ins> ``` ```


* Learn more about [container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/). <ins> * Learn more about [sidecar containers](/docs/concepts/workloads/pods/sidecar-containers/). </ins> * For detailed information about Pod and container status in the API, see the API reference documentation covering [`status`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodStatus) for Pod.


} } <ins> /* Announcements */ </ins> #announcement { > * { color: inherit;


This means that the Pods running on a node are visible on the API server, but cannot be controlled from there. <ins> {{< note >}} The `spec` of a static Pod cannot refer to other API objects (e.g., {{< glossary_tooltip text="ServiceAccount" term_id="service-account" >}}, {{< glossary_tooltip text="ConfigMap" term_id="configmap" >}}, {{< glossary_tooltip text="Secret" term_id="secret" >}}, etc). {{< /note >}} </ins> ## Container probes A _probe_ is a diagnostic performed periodically by the kubelet on a container. To perform a diagnostic, the kubelet can invoke different actions:


resource requests and limits for an init container are handled differently, as documented in [Resource sharing within containers](#resource-sharing-within-containers). <del> Also, init containers do not support `lifecycle`, `livenessProbe`, `readinessProbe`, or `startupProbe` because they must run to completion before the Pod can be ready. </del> <ins> Regular init containers (in other words: excluding sidecar containers) do not support the `lifecycle`, `livenessProbe`, `readinessProbe`, or `startupProbe` fields. Init containers must run to completion before the Pod can be ready; sidecar containers continue running during a Pod's lifetime, and _do_ support some probes. See [sidecar container](/docs/concepts/workloads/pods/sidecar-containers/) for further details about sidecar containers. </ins> If you specify multiple init containers for a Pod, kubelet runs each init container sequentially. Each init container must succeed before the next can run. When all of the init containers have run to completion, kubelet initializes the application containers for the Pod and runs them as usual. <ins> ### Differences from sidecar containers Init containers run and complete their tasks before the main application container starts. Unlike [sidecar containers](/docs/concepts/workloads/pods/sidecar-containers), init containers are not continuously running alongside the main containers. Init containers run to completion sequentially, and the main container does not start until all the init containers have successfully completed. init containers do not support `lifecycle`, `livenessProbe`, `readinessProbe`, or `startupProbe` whereas sidecar containers support all these [probes](/docs/concepts/workloads/pods/pod-lifecycle/#types-of-probe) to control their lifecycle. Init containers share the same resources (CPU, memory, network) with the main application containers but do not interact directly with them. They can, however, use shared volumes for data exchange. </ins> ## Using init containers Because init containers have separate images from app containers, they


design that links a {{< glossary_tooltip term_id="controller" >}} to one or more custom resources. --> <del> [operator 模式](/zh-cn/docs/concepts/extend-kubernetes/operator/) 是一种系统设计, </del> <ins> [operator 模式](/zh-cn/docs/concepts/extend-kubernetes/operator/) 是一种系统设计， </ins> 将 {{< glossary_tooltip term_id="controller" >}} 关联到一个或多个自定义资源。 <!--more-->


instead. {{< /note >}} <ins> {{< note >}} The `spec` of a static Pod cannot refer to other API objects (e.g., {{< glossary_tooltip text="ServiceAccount" term_id="service-account" >}}, {{< glossary_tooltip text="ConfigMap" term_id="configmap" >}}, {{< glossary_tooltip text="Secret" term_id="secret" >}}, etc). {{< /note >}} </ins> ## {{% heading "prerequisites" %}} {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}


## {{% heading "whatsnext" %}} <ins> * Tutorial to _[deploy your first app on Kubernetes with kubectl](/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/)_. </ins> * Learn more about [Deployment objects](/docs/concepts/workloads/controllers/deployment/). * Learn more about [Deploying applications](/docs/tasks/run-application/run-stateless-application-deployment/). * Learn more about [Service objects](/docs/concepts/services-networking/service/).


requestResource
  meta/v1.GroupVersionResource   meta/v1.GroupVersionResource
RequestResource is the fully-qualified resource of the original API request (for example, v1.pods).


<ins> --- title: "后续内容" description: "安装 kubectl 之后，还可以做些什么？" headless: true --- <!-- --- title: "What's next?" description: "What's next after installing kubectl." headless: true --- --> <!-- * [Install Minikube](https://minikube.sigs.k8s.io/docs/start/) * See the [getting started guides](/docs/setup/) for more about creating clusters. * [Learn how to launch and expose your application.](/docs/tasks/access-application-cluster/service-access-application-cluster/) * If you need access to a cluster you didn't create, see the [Sharing Cluster Access document](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/). * Read the [kubectl reference docs](/docs/reference/kubectl/kubectl/) --> * [安装 Minikube](https://minikube.sigs.k8s.io/docs/start/) * 有关创建集群的更多信息，请参阅[入门指南](/zh/docs/setup/). * [学习如何启动并对外公开你的应用程序。](/zh/docs/tasks/access-application-cluster/service-access-application-cluster/) * 如果你需要访问其他人创建的集群，请参阅 [共享集群接入文档](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/). * 阅读 [kubectl 参考文档](/zh/docs/reference/kubectl/kubectl/) </ins>


| | 빈 문자열 (기본값)은 이전 버전과의 호환성을 위한 것으로, hostPath 볼륨은 마운트 하기 전에 아무런 검사도 수행되지 않는다. | | `DirectoryOrCreate` | 만약 주어진 경로에 아무것도 없다면, 필요에 따라 Kubelet이 가지고 있는 동일한 그룹과 소유권, 권한을 0755로 설정한 빈 디렉터리를 생성한다. | | `Directory` | 주어진 경로에 디렉터리가 있어야 함 | <del> | `FileOrCreate` | 만약 주어진 경로에 아무것도 없다면, 필요에 따라 Kubelet이 가지고 있는 동일한 그룹과 소유권, 권한을 0644로 설정한 빈 디렉터리를 생성한다. | </del> <ins> | `FileOrCreate` | 만약 주어진 경로에 아무것도 없다면, 필요에 따라 Kubelet이 가지고 있는 동일한 그룹과 소유권, 권한을 0644로 설정한 빈 파일을 생성한다. | </ins> | `File` | 주어진 경로에 파일이 있어야 함 | | `Socket` | 주어진 경로에 UNIX 소캣이 있어야 함 | | `CharDevice` | 주어진 경로에 문자 디바이스가 있어야 함 |


<ins> --- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-all spec: podSelector: {} policyTypes: - Ingress - Egress </ins>


--- <del> title: v1.19 릴리스 노트 </del> <ins> title: v1.20 릴리스 노트 </ins> weight: 10 card: name: release-notes


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.


drain the node on which the `zk-0` Pod is scheduled. ```shell <del> kubectl drain $(kubectl get pod zk-0 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data </del> <ins> kubectl drain $(kubectl get pod zk-0 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data </ins> ``` ```


The output of a successful command is: <del> deployment.apps/dns-autoscaler created </del> <ins> deployment.apps/kube-dns-autoscaler created </ins> DNS horizontal autoscaling is now enabled. ## Tune DNS autoscaling parameters {#tuning-autoscaling-parameters} <del> Verify that the dns-autoscaler {{< glossary_tooltip text="ConfigMap" term_id="configmap" >}} exists: </del> <ins> Verify that the kube-dns-autoscaler {{< glossary_tooltip text="ConfigMap" term_id="configmap" >}} exists: </ins> ```shell kubectl get configmap --namespace=kube-system


SystemdCgroup = true ``` <ins> If you apply this change make sure to restart containerd again: ```shell sudo systemctl restart containerd ``` </ins> When using kubeadm, manually configure the [cgroup driver for kubelet](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-control-plane-node).


<ins> --- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-all-egress spec: podSelector: {} egress: - {} policyTypes: - Egress </ins>


The [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/) is defined by the states or phases of a Pod. There are five possible Pod phases: Pending, Running, Succeeded, Failed, and Unknown. A high-level description of the Pod state is summarized in the [PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core) `phase` field. --> [Pod 生命周期](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/) 是关于 Pod <del> 处于哪个阶段的概述。包含了下面 5 种可能的阶段: Running、Pending、Succeeded、 </del> <ins> 处于哪个阶段的概述。包含了下面 5 种可能的阶段：Running、Pending、Succeeded、 </ins> Failed、Unknown。关于 Pod 的阶段的更高级描述请查阅 [PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core) `phase` 字段。


1. Download the latest release with the command: <del> ```bash </del> <ins> {{< tabs name="download_binary_linux" >}} {{< tab name="x86-64" codelang="bash" >}} </ins> curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl" <del> ``` </del> <ins> {{< /tab >}} {{< tab name="ARM64" codelang="bash" >}} curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/arm64/kubectl" {{< /tab >}} {{< /tabs >}} </ins> {{< note >}} To download a specific version, replace the `$(curl -L -s https://dl.k8s.io/release/stable.txt)` portion of the command with the specific version. <del> For example, to download version {{< param "fullversion" >}} on Linux, type: </del> <ins> For example, to download version {{< param "fullversion" >}} on Linux x86-64, type: </ins> ```bash curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/linux/amd64/kubectl ``` <ins> And for Linux ARM64, type: ```bash curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/linux/arm64/kubectl ``` </ins> {{< /note >}} 1. Validate the binary (optional) Download the kubectl checksum file: <del> ```bash </del> <ins> {{< tabs name="download_checksum_linux" >}} {{< tab name="x86-64" codelang="bash" >}} </ins> curl -LO "https://dl.k8s.io/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl.sha256" <del> ``` </del> <ins> {{< /tab >}} {{< tab name="ARM64" codelang="bash" >}} curl -LO "https://dl.k8s.io/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/arm64/kubectl.sha256" {{< /tab >}} {{< /tabs >}} </ins> Validate the kubectl binary against the checksum file:


[authorization plugin and policy](/docs/reference/access-authn-authz/authorization/#authorization-modules) in use. <ins> The API credentials are automatically revoked when the Pod is deleted, even if finalizers are in place. In particular, the API credentials are revoked 60 seconds beyond the `.metadata.deletionTimestamp` set on the Pod (the deletion timestamp is typically the time that the **delete** request was accepted plus the Pod's termination grace period). </ins> ### Opt out of API credential automounting If you don't want the {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}


<ins> --- title: Cluster id: cluster date: 2020-08-03 full_link: short_description: > Um conjunto de servidores de processamento, também chamados de nós, que executam aplicações containerizadas. Todo cluster possui ao menos um servidor de processamento (worker node). aka: tags: - fundamental - operation --- Um conjunto de servidores de processamento, chamados {{< glossary_tooltip text="nós" term_id="node" >}}, que executam aplicações containerizadas. Todo cluster possui ao menos um servidor de processamento (_worker node_). <!--more--> O servidor de processamento hospeda os {{< glossary_tooltip text="Pods" term_id="pod" >}} que são componentes de uma aplicação. O {{< glossary_tooltip text="ambiente de gerenciamento" term_id="control-plane" >}} gerencia os nós de processamento e os Pods no cluster. Em ambientes de produção, o ambiente de gerenciamento geralmente executa em múltiplos computadores e um cluster geralmente executa em múltiplos nós (_nodes_) , provendo tolerância a falhas e alta disponibilidade. </ins>


* Cloning support is only available for dynamic provisioners. * CSI drivers may or may not have implemented the volume cloning functionality. * You can only clone a PVC when it exists in the same namespace as the destination PVC (source and destination must be in the same namespace). <del> * Cloning is only supported within the same Storage Class. - Destination volume must be the same storage class as the source - Default storage class can be used and storageClassName omitted in the spec </del> <ins> * Cloning is supported with a different Storage Class. - Destination volume can be the same or a different storage class as the source. - Default storage class can be used and storageClassName omitted in the spec. </ins> * Cloning can only be performed between two volumes that use the same VolumeMode setting (if you request a block mode volume, the source MUST also be block mode)


requestKind
  meta/v1.GroupVersionKind   meta/v1.GroupVersionKind
RequestKind is the fully-qualified type of the original API request (for example, v1.Pod or autoscaling.v1.Scale).


Finally if everything goes well, remove Docker. <del> {{< tabs name="tab-remove-docker-enigine" >}} </del> <ins> {{< tabs name="tab-remove-docker-engine" >}} </ins> {{% tab name="CentOS" %}} ```shell


metadata: name: myapp-pod labels: <del> app: myapp </del> <ins> app.kubernetes.io/name: MyApp </ins> spec: containers: - name: myapp-container


- [コンテナの環境変数](#using-secrets-as-environment-variables)として利用する - Podを生成するために[kubeletがイメージをpullする](#using-imagepullsecrets)ときに使用する <ins> KubernetesのコントロールプレーンでもSecretsは使われています。例えば、[bootstrap token Secrets](#bootstrap-token-secrets)は、ノード登録を自動化するための仕組みです。 </ins> Secretオブジェクトの名称は正当な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names)である必要があります。 シークレットの構成ファイルを作成するときに、`data`および/または`stringData`フィールドを指定できます。`data`フィールドと`stringData`フィールドはオプションです。


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


(backward-compatible) changes to the way the Kubernetes cluster DNS server processes DNS queries, to facilitate the lookup of federated services (which span multiple Kubernetes clusters). <del> See the [Cluster Federation Administrators' Guide](/docs/admin/federation/index.md) for more </del> <ins> See the [Cluster Federation Administrators' Guide](/docs/admin/federation) for more </ins> details on Cluster Federation and multi-site support. ## References


<ins> --- title: スケジューラーの設定 content_type: concept weight: 20 --- {{< feature-state for_k8s_version="v1.19" state="beta" >}} 設定ファイルを作成し、そのパスをコマンドライン引数として渡すことで`kube-scheduler`の振る舞いをカスタマイズすることができます。 <!-- overview --> <!-- body --> スケジューリングプロファイルは、{{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}でスケジューリングの 異なるステージを設定することができます。 各ステージは、拡張点に公開されています。プラグインをそれらの拡張点に1つ以上実装することで、スケジューリングの振る舞いを変更できます。 KubeSchedulerConfiguration([`v1beta2`](/docs/reference/config-api/kube-scheduler-config.v1beta2/)か[`v1beta3`](/docs/reference/config-api/kube-scheduler-config.v1beta3/))構造体を使用して、`kube-scheduler --config <filename>`を実行することで、スケジューリングプロファイルを指定することができます。 最小限の設定は次の通りです。 ```yaml apiVersion: kubescheduler.config.k8s.io/v1beta2 kind: KubeSchedulerConfiguration clientConnection: kubeconfig: /etc/srv/kubernetes/kube-scheduler/kubeconfig ``` ## プロファイル スケジューリングプロファイルは、{{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}でスケジューリングの 異なるステージを設定することができます。 各ステージは[拡張点](#extension-points)に公開されています。 [プラグイン](#scheduling-plugins)をそれらの拡張点に1つ以上実装することで、スケジューリングの振る舞いを変更できます。 単一の`kube-scheduler`インスタンスで[複数のプロファイル](#multiple-profiles)を実行するように設定することも可能です。 ### 拡張点 {#extension-points} スケジューリングは一連のステージで行われ、以下の拡張点に公開されています。 1. `queueSort`: これらのプラグインは、スケジューリングキューにある`pending`状態のPodを ソートするための順序付け関数を提供します。同時に有効化できるプラグインは1つだけです。 1. `preFilter`: これらのプラグインは、フィルタリングをする前にPodやクラスターの情報のチェックや 前処理のために使用されます。これらのプラグインは、設定された順序で呼び出されます。 1. `filter`: これらのプラグインは、スケジューリングポリシーにおけるPredicatesに相当するもので、 Podの実行不可能なNodeをフィルターするために使用されます。 もし全てのNodeがフィルターされてしまった場合、Podはunschedulableとしてマークされます。 1. `postFilter`:これらのプラグインは、Podの実行可能なNodeが見つからなかった場合、 設定された順序で呼び出されます。もし`postFilter`プラグインのいずれかが、Podを __スケジュール可能__ とマークした場合、残りの`postFilter`プラグインは呼び出されません。 1. `preScore`: これは、スコアリング前の作業を行う際に使用できる情報提供のための拡張点です。 1. `score`: これらのプラグインはフィルタリングフェーズを通過してきたそれぞれのNodeに対して スコア付けを行います。その後スケジューラーは、最も高い重み付きスコアの合計を持つノードを選択します。 1. `reserve`: これは、指定されたPodのためにリソースが予約された際に、プラグインに通知する、 情報提供のための拡張点です。また、プラグインは`Reserve`中に失敗した際、または`Reserve`の後に 呼び出される`Unreserve`も実装しています。 1. `permit`: これらのプラグインではPodのバインディングを拒む、または遅延させることができます。 1. `preBind`: これらのプラグインは、Podがバインドされる前に必要な処理を実行できます。 1. `bind`: これらのプラグインはPodをNodeにバインドします。`bind`プラグインは順番に呼び出され、 1つのプラグインがバインドを完了すると、残りのプラグインはスキップされます。`bind`プラグインは 少なくとも1つは必要です。 1. `postBind`: これは、Podがバインドされた後に呼び出される情報提供のための拡張点です。 1. `multiPoint`: このフィールドは設定のみ可能で、プラグインが適用されるすべての拡張点に対して 同時に有効化または無効化することができます。 次の例のように、それぞれの拡張点に対して、特定の[デフォルトプラグイン](#scheduling-plugins)を無効化、または自作のプラグインを有効化することができます。 ```yaml apiVersion: kubescheduler.config.k8s.io/v1beta2 kind: KubeSchedulerConfiguration profiles: - plugins: score: disabled: - name: PodTopologySpread enabled: - name: MyCustomPluginA weight: 2 - name: MyCustomPluginB weight: 1 ``` `disabled`配列の`name`フィールドに`*`を使用することで、その拡張点の全てのデフォルトプラグインを無効化できます。また、必要に応じてプラグインの順序を入れ替える場合にも使用されます。 ### Scheduling plugins {#scheduling-plugins} 以下のプラグインはデフォルトで有効化されており、1つ以上の拡張点に実装されています。 - `ImageLocality`:Podが実行するコンテナイメージを既に持っているNodeを優先します。 拡張点:`score` - `TaintToleration`:[TaintsとTolerations](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/)を実行します。 実装する拡張点:`filter`、`preScore`、`score` - `NodeName`: PodのSpecのNode名が、現在のNodeと一致するかをチェックします。 拡張点:`filter` - `NodePorts`:要求されたPodのポートに対して、Nodeが空きポートを持っているかチェックします。 拡張点:`preFilter`、`filter` - `NodeAffinity`:[nodeselectors](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector) と[Nodeアフィニティ](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity) を実行します。 拡張点:`filter`、`score` - `PodTopologySpread`:[Podトポロジーの分散制約](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)を実行します。 拡張点:`preFilter`、`filter`、`preScore`、`score` - `NodeUnschedulable`:`.spec.unschedulable`がtrueに設定されているNodeをフィルタリングします。 拡張点:`filter`. - `NodeResourcesFit`:Podが要求しているすべてのリソースがNodeにあるかをチェックします。 スコアは3つのストラテジのうちの1つを使用します:`LeastAllocated`(デフォルト)、`MostAllocated`、 と`RequestedToCapacityRatio` 拡張点:`preFilter`、`filter`、`score` - `NodeResourcesBalancedAllocation`:Podがスケジュールされた場合に、よりバランスの取れた リソース使用量となるNodeを優先します。 拡張点:`score` - `VolumeBinding`:Nodeが、要求された{{< glossary_tooltip text="ボリューム" term_id="volume" >}} を持っている、もしくはバインドしているかチェックします。 拡張点:`preFilter`、`filter`、`reserve`、`preBind`、`score` {{< note >}} `score`拡張点は、`VolumeCapacityPriority`機能が有効になっている時に有効化されます。 要求されたボリュームに適合する最小のPVを優先的に使用します。 {{< /note >}} - `VolumeRestrictions`:Nodeにマウントされたボリュームが、ボリュームプロバイダ固有の制限を満たしているかを確認します。 拡張点:`filter` - `VolumeZone`:要求されたボリュームがゾーン要件を満たしているかどうかを確認します。 拡張点:`filter` - `NodeVolumeLimits`:NodeのCSIボリューム制限を満たすかどうかをチェックします。 拡張点:`filter` - `EBSLimits`:NodeのAWSのEBSボリューム制限を満たすかどうかをチェックします。 拡張点:`filter` - `GCEPDLimits`:NodeのGCP-PDボリューム制限を満たすかどうかをチェックします。 拡張点:`filter` - `AzureDiskLimits`:NodeのAzureディスクボリューム制限を満たすかどうかをチェックします。 拡張点:`filter` - `InterPodAffinity`:[Pod間のaffinityとanti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity) を実行します。 拡張点:`preFilter`、`filter`、`preScore`、`score` - `PrioritySort`:デフォルトの優先順位に基づくソートを提供します。 拡張点:`queueSort`. - `DefaultBinder`:デフォルトのバインディングメカニズムを提供します。 拡張点:`bind` - `DefaultPreemption`:デフォルトのプリエンプションメカニズムを提供します。 拡張点:`postFilter` また、コンポーネント設定のAPIにより、以下のプラグインを有効にすることができます。 デフォルトでは有効になっていません。 - `SelectorSpread`:{{< glossary_tooltip text="サービス" term_id="service" >}}と {{< glossary_tooltip text="レプリカセット" term_id="replica-set" >}}、 {{< glossary_tooltip text="ステートフルセット" term_id="statefulset" >}}、 に属するPodのNode間の拡散を優先します。 拡張点:`preScore`、`score` - `CinderLimits`:Nodeが[`OpenStack Cinder`](https://docs.openstack.org/cinder/) ボリューム制限を満たせるかチェックします。 拡張点:`filter` ### 複数のプロファイル {#multiple-profiles} `kube-scheduler`は複数のプロファイルを実行するように設定することができます。 各プロファイルは関連するスケジューラー名を持ち、その[拡張点](#extension-points)に異なるプラグインを 設定することが可能です。 以下のサンプル設定では、スケジューラーは2つのプロファイルで実行されます。1つはデフォルトプラグインで、 もう1つはすべてのスコアリングプラグインを無効にしたものです。 ```yaml apiVersion: kubescheduler.config.k8s.io/v1beta2 kind: KubeSchedulerConfiguration profiles: - schedulerName: default-scheduler - schedulerName: no-scoring-scheduler plugins: preScore: disabled: - name: '*' score: disabled: - name: '*' ``` 特定のプロファイルに従ってスケジュールさせたいPodは、その`.spec.schedulerName`に、対応するスケジューラー名を含めることができます。 デフォルトでは、スケジューラー名`default-scheduler`としてプロファイルが生成されます。 このプロファイルは、上記のデフォルトプラグインを含みます。複数のプロファイルを宣言する場合は、 それぞれユニークなスケジューラー名にする必要があります。 もしPodがスケジューラー名を指定しない場合、kube-apiserverは`default-scheduler`を設定します。 従って、これらのPodをスケジュールするために、このスケジューラー名を持つプロファイルが存在する必要があります。 {{< note >}} Podのスケジューリングイベントには、ReportingControllerとして`.spec.schedulerName`が設定されています。 リーダー選出のイベントには、リスト先頭のプロファイルのスケジューラー名が使用されます。 {{< /note >}} {{< note >}} すべてのプロファイルは、`queueSort`拡張点で同じプラグインを使用し、同じ設定パラメーターを持つ必要があります (該当する場合)。これは、pending状態のPodキューがスケジューラーに1つしかないためです。 {{< /note >}} ### 複数の拡張点に適用されるプラグイン {#multipoint} `kubescheduler.config.k8s.io/v1beta3`からは、プロファイル設定に`multiPoint`というフィールドが追加され、複数の拡張点でプラグインを簡単に有効・無効化できるようになりました。 `multiPoint`設定の目的は、カスタムプロファイルを使用する際に、ユーザーや管理者が必要とする設定を簡素化することです。 `MyPlugin`というプラグインがあり、`preScore`、`score`、`preFilter`、`filter`拡張点を実装しているとします。 すべての利用可能な拡張点で`MyPlugin`を有効化するためには、プロファイル設定は次のようにします。 ```yaml apiVersion: kubescheduler.config.k8s.io/v1beta3 kind: KubeSchedulerConfiguration profiles: - schedulerName: multipoint-scheduler plugins: multiPoint: enabled: - name: MyPlugin ``` これは以下のように、`MyPlugin`を手動ですべての拡張ポイントに対して有効にすることと同じです。 ```yaml apiVersion: kubescheduler.config.k8s.io/v1beta3 kind: KubeSchedulerConfiguration profiles: - schedulerName: non-multipoint-scheduler plugins: preScore: enabled: - name: MyPlugin score: enabled: - name: MyPlugin preFilter: enabled: - name: MyPlugin filter: enabled: - name: MyPlugin ``` `multiPoint`を使用する利点の一つは、将来的に`MyPlugin`が別の拡張点を実装した場合に、 `multiPoint`設定が自動的に新しい拡張点に対しても有効化されることです。 特定の拡張点は、その拡張点の`disabled`フィールドを使用して、`MultiPoint`の展開から除外することができます。 これは、デフォルトのプラグインを無効にしたり、デフォルト以外のプラグインを無効にしたり、 ワイルドカード(`'*'`)を使ってすべてのプラグインを無効にしたりする場合に有効です。 この例として、`Score`と`PreScore`を無効にするためには、次のようにします。 ```yaml apiVersion: kubescheduler.config.k8s.io/v1beta3 kind: KubeSchedulerConfiguration profiles: - schedulerName: non-multipoint-scheduler plugins: multiPoint: enabled: - name: 'MyPlugin' preScore: disabled: - name: '*' score: disabled: - name: '*' ``` `v1beta3`では、`MultiPoint`を通じて、内部的に全ての[デフォルトプラグイン](#scheduling-plugins)が有効化されています。 しかしながら、デフォルト値(並び順やスコアの重みなど)を柔軟に設定し直せるように、個別の拡張点は用意されています。 例えば、2つのスコアプラグイン`DefaultScore1`と`DefaultScore2`に、重み1が設定されているとします。 その場合、次のように重さを変更し、並べ替えることができます ```yaml apiVersion: kubescheduler.config.k8s.io/v1beta3 kind: KubeSchedulerConfiguration profiles: - schedulerName: multipoint-scheduler plugins: score: enabled: - name: 'DefaultScore2' weight: 5 ``` この例では、`MultiPoint`はデフォルトプラグインであるため、明示的にプラグイン名を指定する必要はありません。 そして、`Score`に指定されているプラグインは`DefaultScore2`のみです。 これは、特定の拡張点を通じて設定されたプラグインは、常に`MultiPoint`プラグインよりも優先されるためです。つまり、この設定例では、結果的に2つのプラグインを両方指定することなく、並び替えが行えます。 `MultiPoint`プラグインを設定する際の一般的な優先順位は、以下の通りです。 1. 特定の拡張点が最初に実行され、その設定は他の場所で設定されたものよりも優先される 2. `MultiPoint`を使用して、手動で設定したプラグインとその設定内容 3. デフォルトプラグインとそのデフォルト設定 上記の優先順位を示すために、次の例はこれらのプラグインをベースにします。 |プラグイン|拡張点| |---|---| |`DefaultQueueSort`|`QueueSort`| |`CustomQueueSort`|`QueueSort`| |`DefaultPlugin1`|`Score`, `Filter`| |`DefaultPlugin2`|`Score`| |`CustomPlugin1`|`Score`, `Filter`| |`CustomPlugin2`|`Score`, `Filter`| これらのプラグインの有効な設定例は次の通りです。 ```yaml apiVersion: kubescheduler.config.k8s.io/v1beta3 kind: KubeSchedulerConfiguration profiles: - schedulerName: multipoint-scheduler plugins: multiPoint: enabled: - name: 'CustomQueueSort' - name: 'CustomPlugin1' weight: 3 - name: 'CustomPlugin2' disabled: - name: 'DefaultQueueSort' filter: disabled: - name: 'DefaultPlugin1' score: enabled: - name: 'DefaultPlugin2' ``` なお、特定の拡張点に`MultiPoint`プラグインを再宣言しても、エラーにはなりません。 特定の拡張点が優先されるため、再宣言は無視されます(ログは記録されます)。 このサンプルは、ほとんどのコンフィグを一箇所にまとめるだけでなく、いくつかの工夫をしています。 * カスタムの`queueSort`プラグインを有効にし、デフォルトのプラグインを無効にする。 * `CustomPlugin1`と`CustomPlugin2`を有効にし、この拡張点のプラグイン内で、最初に実行されるようにする。 * `filter`拡張点でのみ、`DefaultPlugin1`を無効にする。 * `score`拡張点で`DefaultPlugin2`が最初に実行されるように並べ替える(カスタムプラグインより先に) `v1beta3`以前のバージョンで、`multiPoint`がない場合、上記の設定例は、次のものと同等になります。 ```yaml apiVersion: kubescheduler.config.k8s.io/v1beta2 kind: KubeSchedulerConfiguration profiles: - schedulerName: multipoint-scheduler plugins: # デフォルトQueueSortプラグインを無効化 queueSort: enabled: - name: 'CustomQueueSort' disabled: - name: 'DefaultQueueSort' # カスタムFilterプラグインを有効化 filter: enabled: - name: 'CustomPlugin1' - name: 'CustomPlugin2' - name: 'DefaultPlugin2' disabled: - name: 'DefaultPlugin1' # カスタムScoreプラグインを有効化し、実行順を並べ替える score: enabled: - name: 'DefaultPlugin2' weight: 1 - name: 'DefaultPlugin1' weight: 3 ``` これは複雑な例ですが、`MultiPoint`設定の柔軟性と、拡張点を設定する既存の方法とのシームレスな統合を実証しています。 ## スケジューラー設定の移行 {{< tabs name="tab_with_md" >}} {{% tab name="v1beta1 → v1beta2" %}} * v1beta2`のバージョン`の設定では、新しい`NodeResourcesFit`プラグインをスコア拡張点で使用できます。 この新しい拡張機能は、`NodeResourcesLeastAllocated`、`NodeResourcesMostAllocated`、 `RequestedToCapacityRatio`プラグインの機能を組み合わせたものです。 例えば、以前は`NodeResourcesMostAllocated`プラグインを使っていたなら、代わりに`NodeResourcesFitプラグイン を使用し(デフォルトで有効)、`pluginConfig`に次のような`scoreStrategy`を追加することになるでしょう。 ```yaml apiVersion: kubescheduler.config.k8s.io/v1beta2 kind: KubeSchedulerConfiguration profiles: - pluginConfig: - args: scoringStrategy: resources: - name: cpu weight: 1 type: MostAllocated name: NodeResourcesFit ``` * スケジューラープラグインの`NodeLabel`は廃止されました。代わりに[`NodeAffinity`](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)プラグイン(デフォルトで有効)を使用することで同様の振る舞いを実現できます。 * スケジューラープラグインの`ServiceAffinity`は廃止されました。代わりに[`InterPodAffinity`](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)プラグイン(デフォルトで有効)を使用することで同様の振る舞いを実現できます。 * スケジューラープラグインの`NodePreferAvoidPods`は廃止されました。代わりに[Node taints](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/)を使用することで同様の振る舞いを実現できます。 * v1beta2で有効化されたプラグインは、そのプラグインのデフォルトの設定より優先されます。 * スケジューラーのヘルスとメトリクスのバインドアドレスに設定されている`host`や`port`が無効な場合、バリデーションに失敗します。 {{% /tab %}} {{% tab name="v1beta2 → v1beta3" %}} * デフォルトで3つのプラグインの重みが増加しました。 * `InterPodAffinity`:1から2 * `NodeAffinity`:1から2 * `TaintToleration`:1から3 {{% /tab %}} {{< /tabs >}} ## {{% heading "whatsnext" %}} * [kube-schedulerリファレンス](/docs/reference/command-line-tools-reference/kube-scheduler/)を読む * [scheduling](/ja/docs/concepts/scheduling-eviction/kube-scheduler/)について学ぶ * [kube-scheduler設定(v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/)のリファレンスを読む * [kube-scheduler設定(v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/)のリファレンスを読む </ins>


 {{ end }}

 {{ end }}  No newline at end of file


<ins> --- title: Sidecar Containers content_type: concept weight: 50 --- <!-- overview --> {{< feature-state for_k8s_version="v1.28" state="alpha" >}} Sidecar containers are the secondary containers that run along with the main application container within the same {{< glossary_tooltip text="Pod" term_id="pod" >}}. These containers are used to enhance or to extend the functionality of the main application container by providing additional services, or functionality such as logging, monitoring, security, or data synchronization, without directly altering the primary application code. <!-- body --> ## Enabling sidecar containers Starting with Kubernetes 1.28, a [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) named `SidecarContainers` allows you to specify a `restartPolicy` for containers listed in a Pod's `initContainers` field. These restartable _sidecar_ containers are independent with other [init containers](/docs/concepts/workloads/pods/init-containers/) and main application container within the same pod. These can be started, stopped, or restarted without effecting the main application container and other init containers. ## Sidecar containers and Pod lifecycle If an init container is created with its `restartPolicy` set to `Always`, it will start and remain running during the entire life of the Pod. This can be helpful for running supporting services separated from the main application containers. If a `readinessProbe` is specified for this init container, its result will be used to determine the `ready` state of the Pod. Since these containers are defined as init containers, they benefit from the same ordering and sequential guarantees as other init containers, allowing them to be mixed with other init containers into complex Pod initialization flows. Compared to regular init containers, sidecars defined within `initContainers` continue to run after they have started. This is important when there is more than one entry inside `.spec.initContainers` for a Pod. After a sidecar-style init container is running (the kubelet has set the `started` status for that init container to true), the kubelet then starts the next init container from the ordered `.spec.initContainers` list. That status either becomes true because there is a process running in the container and no startup probe defined, or as a result of its `startupProbe` succeeding. Here's an example of a Deployment with two containers, one of which is a sidecar: {{% code_sample language="yaml" file="application/deployment-sidecar.yaml" %}} This feature is also useful for running Jobs with sidecars, as the sidecar container will not prevent the Job from completing after the main container has finished. Here's an example of a Job with two containers, one of which is a sidecar: {{% code_sample language="yaml" file="application/job/job-sidecar.yaml" %}} By default, this feature is not available in Kubernetes. To avail this feature, you need to enable the [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) named `SidecarContainers`. ## Differences from regular containers Sidecar containers run alongside regular containers in the same pod. However, they do not execute the primary application logic; instead, they provide supporting functionality to the main application. Sidecar containers have their own independent lifecycles. They can be started, stopped, and restarted independently of regular containers. This means you can update, scale, or maintain sidecar containers without affecting the primary application. Sidecar containers share the same network and storage namespaces with the primary container This co-location allows them to interact closely and share resources. ## Differences from init containers Sidecar containers work alongside the main container, extending its functionality and providing additional services. Sidecar containers run concurrently with the main application container. They are active throughout the lifecycle of the pod and can be started and stopped independently of the main container. Unlike [init containers](/docs/concepts/workloads/pods/init-containers/), sidecar containers support [probes](/docs/concepts/workloads/pods/pod-lifecycle/#types-of-probe) to control their lifecycle. These containers can interact directly with the main application containers, sharing the same network namespace, filesystem, and environment variables. They work closely together to provide additional functionality. ## Resource sharing within containers {{< comment >}} This section is also present in the [init containers](/docs/concepts/workloads/pods/init-containers/) page. If you're editing this section, change both places. {{< /comment >}} Given the order of execution for init, sidecar and app containers, the following rules for resource usage apply: * The highest of any particular resource request or limit defined on all init containers is the *effective init request/limit*. If any resource has no resource limit specified this is considered as the highest limit. * The Pod's *effective request/limit* for a resource is the sum of [pod overhead](/docs/concepts/scheduling-eviction/pod-overhead/) and the higher of: * the sum of all non-init containers(app and sidecar containers) request/limit for a resource * the effective init request/limit for a resource * Scheduling is done based on effective requests/limits, which means init containers can reserve resources for initialization that are not used during the life of the Pod. * The QoS (quality of service) tier of the Pod's *effective QoS tier* is the QoS tier for all init, sidecar and app containers alike. Quota and limits are applied based on the effective Pod request and limit. Pod level control groups (cgroups) are based on the effective Pod request and limit, the same as the scheduler. ## {{% heading "whatsnext" %}} * Read a blog post on [native sidecar containers](/blog/2023/08/25/native-sidecar-containers/). * Read about [creating a Pod that has an init container](/docs/tasks/configure-pod-container/configure-pod-initialization/#create-a-pod-that-has-an-init-container). * Learn about the [types of probes](/docs/concepts/workloads/pods/pod-lifecycle/#types-of-probe): liveness, readiness, startup probe. * Learn about [pod overhead](/docs/concepts/scheduling-eviction/pod-overhead/). </ins>


* `apiserver_flowcontrol_rejected_requests_total` is a counter vector (cumulative since server start) of requests that were rejected, <del> broken down by the labels `flowSchema` (indicating the one that matched the request), `priorityLevel` (indicating the one to which </del> <ins> broken down by the labels `flow_schema` (indicating the one that matched the request), `priority_level` (indicating the one to which </ins> the request was assigned), and `reason`.  The `reason` label will be have one of the following values: * `queue-full`, indicating that too many requests were already