Question: <ins> --- title: Serviceトポロジー feature: title: Serviceトポロジー description: > Serviceのトラフィックをクラスタートポロジーに基づいてルーティングします。 content_type: concept weight: 10 --- <!-- overview --> {{< feature-state for_k8s_version="v1.17" state="alpha" >}} *Serviceトポロジー*を利用すると、Serviceのトラフィックをクラスターのノードトポロジーに基づいてルーティングできるようになります。たとえば、あるServiceのトラフィックに対して、できるだけ同じノードや同じアベイラビリティゾーン上にあるエンドポイントを優先してルーティングするように指定できます。 <!-- body --> ## はじめに デフォルトでは、`ClusterIP`や`NodePort`Serviceに送信されたトラフィックは、Serviceに対応する任意のバックエンドのアドレスにルーティングされる可能性があります。しかし、Kubernetes 1.7以降では、「外部の」トラフィックをそのトラフィックを受信したノード上のPodにルーティングすることが可能になりました。しかし、この機能は`ClusterIP`Serviceでは対応しておらず、ゾーン内ルーティングなどのより複雑なトポロジーは実現不可能でした。*Serviceトポロジー*の機能を利用すれば、Serviceの作者が送信元ノードと送信先ノードのNodeのラベルに基づいてトラフィックをルーティングするためのポリシーを定義できるようになるため、この問題を解決できます。 送信元と送信先の間のNodeラベルのマッチングを使用することにより、オペレーターは、そのオペレーターの要件に適したメトリクスを使用して、お互いに「より近い」または「より遠い」ノードのグループを指定できます。たとえば、パブリッククラウド上のさまざまなオペレーターでは、Serviceのトラフィックを同一ゾーン内に留めようとする傾向があります。パブリッククラウドでは、ゾーンをまたぐトラフィックでは関連するコストがかかる一方、ゾーン内のトラフィックにはコストがかからない場合があるからです。その他のニーズとしては、DaemonSetが管理するローカルのPodにトラフィックをルーティングできるようにしたり、レイテンシーを低く抑えるために同じラック上のスイッチに接続されたノードにトラフィックを限定したいというものがあります。 ## Serviceトポロジーを利用する クラスターのServiceトポロジーが有効になっていれば、Serviceのspecに`topologyKeys`フィールドを指定することで、Serviceのトラフィックのルーティングを制御できます。このフィールドは、Nodeラベルの優先順位リストで、このServiceにアクセスするときにエンドポイントをソートするために使われます。トラフィックは、最初のラベルの値が送信元Nodeのものと一致するNodeに送信されます。一致したノード上にServiceに対応するバックエンドが存在しなかった場合は、2つ目のラベルについて検討が行われ、同様に、残っているラベルが順番に検討されまます。 一致するキーが1つも見つからなかった場合、トラフィックは、Serviceに対応するバックエンドが存在しなかったかのように拒否されます。言い換えると、エンドポイントは、利用可能なバックエンドが存在する最初のトポロジーキーに基づいて選択されます。このフィールドが指定され、すべてのエントリーでクライアントのトポロジーに一致するバックエンドが存在しない場合、そのクライアントに対するバックエンドが存在しないものとしてコネクションが失敗します。「任意のトポロジー」を意味する特別な値`"*"`を指定することもできます。任意の値にマッチするこの値に意味があるのは、リストの最後の値として使った場合だけです。 `topologyKeys`が未指定または空の場合、トポロジーの制約は適用されません。 ホスト名、ゾーン名、リージョン名のラベルが付いたNodeを持つクラスターについて考えてみましょう。このとき、Serviceの`topologyKeys`の値を設定することで、トラフィックの向きを以下のように制御できます。 * トラフィックを同じノード上のエンドポイントのみに向け、同じノード上にエンドポイントが1つも存在しない場合には失敗するようにする: `["kubernetes.io/hostname"]`。 * 同一ノード上のエンドポイントを優先し、失敗した場合には同一ゾーン上のエンドポイント、同一リージョンゾーンのエンドポイントへとフォールバックし、それ以外の場合には失敗する: `["kubernetes.io/hostname", "topology.kubernetes.io/zone", "topology.kubernetes.io/region"]`。これは、たとえばデータのローカリティが非常に重要である場合などに役に立ちます。 * 同一ゾーンを優先しますが、ゾーン内に利用可能なノードが存在しない場合は、利用可能な任意のエンドポイントにフォールバックする: `["topology.kubernetes.io/zone", "*"]`。 ## 制約 * Serviceトポロジーは`externalTrafficPolicy=Local`と互換性がないため、Serviceは2つの機能を同時に利用できません。2つの機能を同じクラスター上の異なるServiceでそれぞれ利用することは可能ですが、同一のService上では利用できません。 * 有効なトポロジーキーは、現在は`kubernetes.io/hostname`、`topology.kubernetes.io/zone`、および`topology.kubernetes.io/region`に限定されています。しかし、将来は一般化され、他のノードラベルも使用できるようになる予定です。 * トポロジーキーは有効なラベルのキーでなければならず、最大で16個のキーまで指定できます。 * すべての値をキャッチする`"*"`を使用する場合は、トポロジーキーの最後の値として指定しなければなりません。 ## 例 以下では、Serviceトポロジーの機能を利用したよくある例を紹介します。 ### ノードローカルのエンドポイントだけを使用する ノードローカルのエンドポイントのみにルーティングするServiceの例です。もし同一ノード上にエンドポイントが存在しない場合、トラフィックは損失します。 ```yaml apiVersion: v1 kind: Service metadata: name: my-service spec: selector: app: my-app ports: - protocol: TCP port: 80 targetPort: 9376 topologyKeys: - "kubernetes.io/hostname" ``` ### ノードローカルのエンドポイントを優先して使用する ノードローカルのエンドポイントを優先して使用しますが、ノードローカルのエンドポイントが存在しない場合にはクラスター全体のエンドポイントにフォールバックするServiceの例です。 ```yaml apiVersion: v1 kind: Service metadata: name: my-service spec: selector: app: my-app ports: - protocol: TCP port: 80 targetPort: 9376 topologyKeys: - "kubernetes.io/hostname" - "*" ``` ### 同一ゾーンや同一リージョンのエンドポイントだけを使用する 同一リージョンのエンドポイントより同一ゾーンのエンドポイントを優先するServiceの例です。もしいずれのエンドポイントも存在しない場合、トラフィックは損失します。 ```yaml apiVersion: v1 kind: Service metadata: name: my-service spec: selector: app: my-app ports: - protocol: TCP port: 80 targetPort: 9376 topologyKeys: - "topology.kubernetes.io/zone" - "topology.kubernetes.io/region" ``` ### ノードローカル、同一ゾーン、同一リーションのエンドポイントを優先して使用する ノードローカル、同一ゾーン、同一リージョンのエンドポイントを順番に優先し、クラスター全体のエンドポイントにフォールバックするServiceの例です。 ```yaml apiVersion: v1 kind: Service metadata: name: my-service spec: selector: app: my-app ports: - protocol: TCP port: 80 targetPort: 9376 topologyKeys: - "kubernetes.io/hostname" - "topology.kubernetes.io/zone" - "topology.kubernetes.io/region" - "*" ``` ## {{% heading "whatsnext" %}} * [Serviceトポトジーを有効にする](/docs/tasks/administer-cluster/enabling-service-topology)を読む。 * [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)を読む。 </ins>

This is a Feature Request What would you like to be Translate into Japanese. Why is this needed This page has not been translated. Comments /language ja /assign
/close
Closing this issue. <detailsIn response to : /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


Question: - operation --- <del> एग्रीगेशन लेयर आपको अपने क्लस्टर में अतिरिक्त कुबेरनेट्स-शैली API स्थापित करने देता है।``` </del> <ins> एग्रीगेशन लेयर आपको अपने क्लस्टर में अतिरिक्त कुबेरनेट्स-शैली API स्थापित करने देता है। </ins> <!--more--> <del> जब आपने {{< glossary_tooltip text="कुबेरनेट्स API सर्वर" term_id="kube-apiserver" >}} को [अतिरिक्त API का समर्थन](/docs/tasks/extend-kubernetes/configure-aggregation-layer/) करने के लिए कॉन्फ़िगर किया हो, आप कुबेरनेट्स एपीआई में URL पथ का "दावा" करने के लिए `APIService` ऑब्जेक्ट जोड़ सकते हैं। </del> <ins> जब आपने {{< glossary_tooltip text="कुबेरनेट्स API सर्वर" term_id="kube-apiserver" >}} को [अतिरिक्त API का समर्थन](/docs/tasks/extend-kubernetes/configure-aggregation-layer/) करने के लिए कॉन्फ़िगर किया हो, आप कुबेरनेट्स API में URL पाथ का "दावा" करने के लिए `APIService` ऑब्जेक्ट जोड़ सकते हैं। </ins>

Observed this issue while reading . I have gone through the the whole file need to do these changes. ्रीगेशन लेयर आपको अपने क्लस्टर में अतिरिक्त कुबेरनेट्स-शैली API स्थापित करने देता है। Need to remove this कुबेरनेट्स need to change this to -API ें URL -URL पाथ /assign
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/language hi /kind bug


Question: <ins> --- layout: blog title: "别慌: Kubernetes 和 Docker" date: 2020-12-02 slug: dont-panic-kubernetes-and-docker --- <!-- layout: blog title: "Don't Panic: Kubernetes and Docker" date: 2020-12-02 slug: dont-panic-kubernetes-and-docker --> **作者：** Jorge Castro, Duffie Cooley, Kat Cosgrove, Justin Garrison, Noah Kantrowitz, Bob Killen, Rey Lejano, Dan “POP” Papandrea, Jeffrey Sica, Davanum “Dims” Srinivas <!-- Kubernetes is [deprecating Docker](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation) as a container runtime after v1.20. --> Kubernetes 从版本 v1.20 之后，[弃用 Docker](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation) 这个容器运行时。 <!-- **You do not need to panic. It’s not as dramatic as it sounds.** --> **不必慌张，这件事并没有听起来那么吓人。** <!-- TL;DR Docker as an underlying runtime is being deprecated in favor of runtimes that use the [Container Runtime Interface (CRI)](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/) created for Kubernetes. Docker-produced images will continue to work in your cluster with all runtimes, as they always have. --> 弃用 Docker 这个底层运行时，转而支持符合为 Kubernetes 创建的 [Container Runtime Interface (CRI)](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/) 的运行时。 Docker 构建的镜像，将在你的集群的所有运行时中继续工作，一如既往。 <!-- If you’re an end-user of Kubernetes, not a whole lot will be changing for you. This doesn’t mean the death of Docker, and it doesn’t mean you can’t, or shouldn’t, use Docker as a development tool anymore. Docker is still a useful tool for building containers, and the images that result from running `docker build` can still run in your Kubernetes cluster. --> 如果你是 Kubernetes 的终端用户，这对你不会有太大影响。 这事并不意味着 Dockder 已死、也不意味着你不能或不该继续把 Docker 用作开发工具。 Docker 仍然是构建容器的利器，使用命令 `docker build` 构建的镜像在 Kubernetes 集群中仍然可以运行。 <!-- If you’re using a managed Kubernetes service like GKE, EKS, or AKS (which [defaults to containerd](https://github.com/Azure/AKS/releases/tag/2020-11-16)) you will need to make sure your worker nodes are using a supported container runtime before Docker support is removed in a future version of Kubernetes. If you have node customizations you may need to update them based on your environment and runtime requirements. Please work with your service provider to ensure proper upgrade testing and planning. --> 如果你正在使用 GKE、EKS、或 AKS ([默认使用 containerd](https://github.com/Azure/AKS/releases/tag/2020-11-16)) 这类托管 Kubernetes 服务，你需要在 Kubernetes 后续版本移除对 Docker 支持之前， 确认工作节点使用了被支持的容器运行时。 如果你的节点被定制过，你可能需要根据你自己的环境和运行时需求更新它们。 请与你的服务供应商协作，确保做出适当的升级测试和计划。 <!-- If you’re rolling your own clusters, you will also need to make changes to avoid your clusters breaking. At v1.20, you will get a deprecation warning for Docker. When Docker runtime support is removed in a future release (currently planned for the 1.22 release in late 2021) of Kubernetes it will no longer be supported and you will need to switch to one of the other compliant container runtimes, like containerd or CRI-O. Just make sure that the runtime you choose supports the docker daemon configurations you currently use (e.g. logging). --> 如果你正在运营你自己的集群，那还应该做些工作，以避免集群中断。 在 v1.20 版中，你仅会得到一个 Docker 的弃用警告。 当对 Docker 运行时的支持在 Kubernetes 某个后续发行版（目前的计划是 2021 年晚些时候的 1.22 版）中被移除时， 你需要切换到 containerd 或 CRI-O 等兼容的容器运行时。 只要确保你选择的运行时支持你当前使用的 Docker 守护进程配置（例如 logging）。 <!-- ## So why the confusion and what is everyone freaking out about? --> ## 那为什么会有这样的困惑，为什么每个人要害怕呢？{#so-why-the-confusion-and-what-is-everyone-freaking-out-about} <!-- We’re talking about two different environments here, and that’s creating confusion. Inside of your Kubernetes cluster, there’s a thing called a container runtime that’s responsible for pulling and running your container images. Docker is a popular choice for that runtime (other common options include containerd and CRI-O), but Docker was not designed to be embedded inside Kubernetes, and that causes a problem. --> 我们在这里讨论的是两套不同的环境，这就是造成困惑的根源。 在你的 Kubernetes 集群中，有一个叫做容器运行时的东西，它负责拉取并运行容器镜像。 Docker 对于运行时来说是一个流行的选择（其他常见的选择包括 containerd 和 CRI-O）， 但 Docker 并非设计用来嵌入到 Kubernetes，这就是问题所在。 <!-- You see, the thing we call “Docker” isn’t actually one thing—it’s an entire tech stack, and one part of it is a thing called “containerd,” which is a high-level container runtime by itself. Docker is cool and useful because it has a lot of UX enhancements that make it really easy for humans to interact with while we’re doing development work, but those UX enhancements aren’t necessary for Kubernetes, because it isn’t a human. --> 你看，我们称之为 “Docker” 的物件实际上并不是一个物件——它是一个完整的技术堆栈， 它其中一个叫做 “containerd” 的部件本身，才是一个高级容器运行时。 Docker 既酷炫又实用，因为它提供了很多用户体验增强功能，而这简化了我们做开发工作时的操作， Kubernetes 用不到这些增强的用户体验，毕竟它并非人类。 <!-- As a result of this human-friendly abstraction layer, your Kubernetes cluster has to use another tool called Dockershim to get at what it really needs, which is containerd. That’s not great, because it gives us another thing that has to be maintained and can possibly break. What’s actually happening here is that Dockershim is being removed from Kubelet as early as v1.23 release, which removes support for Docker as a container runtime as a result. You might be thinking to yourself, but if containerd is included in the Docker stack, why does Kubernetes need the Dockershim? --> 因为这个用户友好的抽象层，Kubernetes 集群不得不引入一个叫做 Dockershim 的工具来访问它真正需要的 containerd。 这不是一件好事，因为这引入了额外的运维工作量，而且还可能出错。 实际上正在发生的事情就是：Dockershim 将在不早于 v1.23 版中从 kubelet 中被移除，也就取消对 Docker 容器运行时的支持。 你心里可能会想，如果 containerd 已经包含在 Docker 堆栈中，为什么 Kubernetes 需要 Dockershim。 <!-- Docker isn’t compliant with CRI, the [Container Runtime Interface](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/). If it were, we wouldn’t need the shim, and this wouldn’t be a thing. But it’s not the end of the world, and you don’t need to panic—you just need to change your container runtime from Docker to another supported container runtime. --> Docker 不兼容 CRI， [容器运行时接口](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/)。 如果支持，我们就不需要这个 shim 了，也就没问题了。 但这也不是世界末日，你也不需要恐慌——你唯一要做的就是把你的容器运行时从 Docker 切换到其他受支持的容器运行时。 <!-- One thing to note: If you are relying on the underlying docker socket (`/var/run/docker.sock`) as part of a workflow within your cluster today, moving to a different runtime will break your ability to use it. This pattern is often called Docker in Docker. There are lots of options out there for this specific use case including things like [kaniko](https://github.com/GoogleContainerTools/kaniko), [img](https://github.com/genuinetools/img), and [buildah](https://github.com/containers/buildah). --> 要注意一点：如果你依赖底层的 Docker 套接字(`/var/run/docker.sock`)，作为你集群中工作流的一部分， 切换到不同的运行时会导致你无法使用它。 这种模式经常被称之为嵌套 Docker（Docker in Docker）。 对于这种特殊的场景，有很多选项，比如： [kaniko](https://github.com/GoogleContainerTools/kaniko)、 [img](https://github.com/genuinetools/img)、和 [buildah](https://github.com/containers/buildah)。 <!-- ## What does this change mean for developers, though? Do we still write Dockerfiles? Do we still build things with Docker? --> ## 那么，这一改变对开发人员意味着什么？我们还要写 Dockerfile 吗？还能用 Docker 构建镜像吗？{#what-does-this-change-mean-for-developers} <!-- This change addresses a different environment than most folks use to interact with Docker. The Docker installation you’re using in development is unrelated to the Docker runtime inside your Kubernetes cluster. It’s confusing, we understand. As a developer, Docker is still useful to you in all the ways it was before this change was announced. The image that Docker produces isn’t really a Docker-specific image—it’s an OCI ([Open Container Initiative](https://opencontainers.org/)) image. Any OCI-compliant image, regardless of the tool you use to build it, will look the same to Kubernetes. Both [containerd](https://containerd.io/) and [CRI-O](https://cri-o.io/) know how to pull those images and run them. This is why we have a standard for what containers should look like. --> 此次改变带来了一个不同的环境，这不同于我们常用的 Docker 交互方式。 你在开发环境中用的 Docker 和你 Kubernetes 集群中的 Docker 运行时无关。 我们知道这听起来让人困惑。 对于开发人员，Docker 从所有角度来看仍然有用，就跟这次改变之前一样。 Docker 构建的镜像并不是 Docker 特有的镜像——它是一个 OCI（[开放容器标准](https://opencontainers.org/)）镜像。 任一 OCI 兼容的镜像，不管它是用什么工具构建的，在 Kubernetes 的角度来看都是一样的。 [containerd](https://containerd.io/) 和 [CRI-O](https://cri-o.io/) 两者都知道怎么拉取并运行这些镜像。 这就是我们制定容器标准的原因。 <!-- So, this change is coming. It’s going to cause issues for some, but it isn’t catastrophic, and generally it’s a good thing. Depending on how you interact with Kubernetes, this could mean nothing to you, or it could mean a bit of work. In the long run, it’s going to make things easier. If this is still confusing for you, that’s okay—there’s a lot going on here; Kubernetes has a lot of moving parts, and nobody is an expert in 100% of it. We encourage any and all questions regardless of experience level or complexity! Our goal is to make sure everyone is educated as much as possible on the upcoming changes. We hope this has answered most of your questions and soothed some anxieties! ❤ --> 所以，改变已经发生。 它确实带来了一些问题，但这不是一个灾难，总的说来，这还是一件好事。 根据你操作 Kubernetes 的方式的不同，这可能对你不构成任何问题，或者也只是意味着一点点的工作量。 从一个长远的角度看，它使得事情更简单。 如果你还在困惑，也没问题——这里还有很多事情； Kubernetes 有很多变化中的功能，没有人是100%的专家。 我们鼓励你提出任何问题，无论水平高低、问题难易。 我们的目标是确保所有人都能在即将到来的改变中获得足够的了解。 我们希望这已经回答了你的大部分问题，并缓解了一些焦虑！❤ <!-- Looking for more answers? Check out our accompanying [Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/). --> 还在寻求更多答案吗？请参考我们附带的 [弃用 Dockershim 的常见问题](/zh/blog/2020/12/02/dockershim-faq/)。 </ins>

This is a Feature Request translate /blog/posts/2020-12-02-dont-panic-kubernetes-and- What would you like to be content/zh/blog/posts/2020-12-02-dont-panic-kubernetes-and- /assign /language zh
/triage accepted /kind feature


Question: [blackfriday] hrefTargetBlank = true fractions = false <ins> smartDashes = false </ins> [frontmatter] date = ["date", ":filename", "publishDate", "lastmod"]

reference docs render with (single UTF8 8211) instead of (ANSI 45) even if a generated reference page contains the regular double dash . see vs this makes users copy-pasting command line flags insert bogus flags in their setup. request: please make the website render the double dash . /kind bug /sig docs /cc
reported here on slack:
/priority important-longterm (or higher)
Thanks for filing the issue
Emm. Hugo is again doing some conversion behind the scene. If you check the reference page we generated: you can see that the is in the source. Hugo converted into , for unknown reason.
I suspect we will find pages that have relied on the smart dashes behavior. For a different, lasting fix, maybe we change the docs generation to write HTML/Markdown that looks like: or maybe we switch to a newer Hugo that implements more of CommonMark and that lets us re-enable smart dashes without breaking reference docs?
Wow thanks for implementing the change so quickly after the report <3 you guys rock!!


Question: <ins> --- title: Namespaceに対する最小および最大メモリー制約の構成 content_type: task weight: 30 --- <!-- overview --> このページでは、Namespaceで実行されるコンテナが使用するメモリーの最小値と最大値を設定する方法を説明します。 [LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core) で最小値と最大値のメモリー値を指定します。 PodがLimitRangeによって課される制約を満たさない場合、そのNamespaceではPodを作成できません。 ## {{% heading "prerequisites" %}} {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} クラスタ内の各ノードには、少なくとも1GiBのメモリが必要です。 <!-- steps --> ## Namespaceの作成 この演習で作成したリソースがクラスターの他の部分から分離されるように、Namespaceを作成します。 ```shell kubectl create namespace constraints-mem-example ``` ## LimitRangeとPodを作成 LimitRangeの設定ファイルです。 {{< codenew file="admin/resource/memory-constraints.yaml" >}} LimitRangeを作成します。 ```shell kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints.yaml --namespace=constraints-mem-example ``` LimitRangeの詳細情報を表示します。 ```shell kubectl get limitrange mem-min-max-demo-lr --namespace=constraints-mem-example --output=yaml ``` 出力されるのは、予想通りメモリ制約の最小値と最大値を示しています。 しかし、LimitRangeの設定ファイルでデフォルト値を指定していないにもかかわらず、 自動的に作成されていることに気づきます。 ``` limits: - default: memory: 1Gi defaultRequest: memory: 1Gi max: memory: 1Gi min: memory: 500Mi type: Container ``` constraints-mem-exampleNamespaceにコンテナが作成されるたびに、 Kubernetesは以下の手順を実行するようになっています。 * コンテナが独自のメモリ要求と制限を指定しない場合は、デフォルトのメモリ要求と制限をコンテナに割り当てます。 * コンテナに500MiB以上のメモリ要求があることを確認します。 * コンテナのメモリ制限が1GiB以下であることを確認します。 以下は、1つのコンテナを持つPodの設定ファイルです。設定ファイルのコンテナ(containers)では、600MiBのメモリ要求と800MiBのメモリ制限が指定されています。これらはLimitRangeによって課される最小と最大のメモリ制約を満たしています。 {{< codenew file="admin/resource/memory-constraints-pod.yaml" >}} Podの作成 ```shell kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod.yaml --namespace=constraints-mem-example ``` Podのコンテナが実行されていることを確認します。 ```shell kubectl get pod constraints-mem-demo --namespace=constraints-mem-example ``` Podの詳細情報を見ます ```shell kubectl get pod constraints-mem-demo --output=yaml --namespace=constraints-mem-example ``` 出力は、コンテナが600MiBのメモリ要求と800MiBのメモリ制限になっていることを示しています。これらはLimitRangeによって課される制約を満たしています。 ```yaml resources: limits: memory: 800Mi requests: memory: 600Mi ``` Podを消します。 ```shell kubectl delete pod constraints-mem-demo --namespace=constraints-mem-example ``` ## 最大メモリ制約を超えるPodの作成の試み これは、1つのコンテナを持つPodの設定ファイルです。コンテナは800MiBのメモリ要求と1.5GiBのメモリ制限を指定しています。 {{< codenew file="admin/resource/memory-constraints-pod-2.yaml" >}} Podを作成してみます。 ```shell kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod-2.yaml --namespace=constraints-mem-example ``` 出力は、コンテナが大きすぎるメモリ制限を指定しているため、Podが作成されないことを示しています。 ``` Error from server (Forbidden): error when creating "examples/admin/resource/memory-constraints-pod-2.yaml": pods "constraints-mem-demo-2" is forbidden: maximum memory usage per Container is 1Gi, but limit is 1536Mi. ``` ## 最低限のメモリ要求を満たさないPodの作成の試み これは、1つのコンテナを持つPodの設定ファイルです。コンテナは100MiBのメモリ要求と800MiBのメモリ制限を指定しています。 {{< codenew file="admin/resource/memory-constraints-pod-3.yaml" >}} Podを作成してみます。 ```shell kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod-3.yaml --namespace=constraints-mem-example ``` 出力は、コンテナが小さすぎるメモリリクエストを指定しているため、Podが作成されないことを示しています。 ``` Error from server (Forbidden): error when creating "examples/admin/resource/memory-constraints-pod-3.yaml": pods "constraints-mem-demo-3" is forbidden: minimum memory usage per Container is 500Mi, but request is 100Mi. ``` ## メモリ要求や制限を指定しないPodの作成 これは、1つのコンテナを持つPodの設定ファイルです。コンテナはメモリ要求を指定しておらず、メモリ制限も指定していません。 {{< codenew file="admin/resource/memory-constraints-pod-4.yaml" >}} Podを作成します。 ```shell kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod-4.yaml --namespace=constraints-mem-example ``` Podの詳細情報を見ます ``` kubectl get pod constraints-mem-demo-4 --namespace=constraints-mem-example --output=yaml ``` 出力を見ると、Podのコンテナのメモリ要求は1GiB、メモリ制限は1GiBであることがわかります。 コンテナはどのようにしてこれらの値を取得したのでしょうか？ ``` resources: limits: memory: 1Gi requests: memory: 1Gi ``` コンテナが独自のメモリ要求と制限を指定していなかったため、LimitRangeから与えられたのです。 コンテナが独自のメモリ要求と制限を指定していなかったため、LimitRangeから[デフォルトのメモリ要求と制限](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)が与えられたのです。 この時点で、コンテナは起動しているかもしれませんし、起動していないかもしれません。このタスクの前提条件は、ノードが少なくとも1GiBのメモリを持っていることであることを思い出してください。それぞれのノードが1GiBのメモリしか持っていない場合、どのノードにも1GiBのメモリ要求に対応するのに十分な割り当て可能なメモリがありません。たまたま2GiBのメモリを持つノードを使用しているのであれば、おそらく1GiBのメモリリクエストに対応するのに十分なスペースを持っていることになります。 Podを削除します。 ``` kubectl delete pod constraints-mem-demo-4 --namespace=constraints-mem-example ``` ## 最小および最大メモリ制約の強制 LimitRangeによってNamespaceに課される最大および最小のメモリ制約は、Podが作成または更新されたときにのみ適用されます。LimitRangeを変更しても、以前に作成されたPodには影響しません。 ## 最小・最大メモリ制約の動機 クラスタ管理者としては、Podが使用できるメモリ量に制限を課したいと思うかもしれません。 例: * クラスタ内の各ノードは2GBのメモリを持っています。クラスタ内のどのノードもその要求をサポートできないため、2GB以上のメモリを要求するPodは受け入れたくありません。 * クラスターは運用部門と開発部門で共有されています。 本番用のワークロードでは最大8GBのメモリーを消費しますが、開発用のワークロードでは512MBに制限したいとします。本番用と開発用に別々のNamespaceを作成し、それぞれのNamespaceにメモリー制限を適用します。 ## クリーンアップ Namespaceを削除します。 ```shell kubectl delete namespace constraints-mem-example ``` ## {{% heading "whatsnext" %}} ### クラスター管理者向け * [名前空間に対するデフォルトのメモリ要求と制限の構成](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/) * [名前空間に対するデフォルトのCPU要求と制限の構成](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/) * [名前空間に対する最小および最大CPU制約の構成](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/) * [名前空間に対するメモリーとCPUのクォータの構成](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/) * [名前空間に対するPodクォータの設定](/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/) * [APIオブジェクトのクォータの設定](/docs/tasks/administer-cluster/quota-api-object/) ### アプリケーション開発者向け * [コンテナとPodへのメモリーリソースの割り当て](/docs/tasks/configure-pod-container/assign-memory-resource/) * [コンテナとPodへのCPUリソースの割り当て](/docs/tasks/configure-pod-container/assign-cpu-resource/) * [PodのQoS(サービス品質)を設定](/docs/tasks/configure-pod-container/quality-service-pod/) </ins>

This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be <!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --Translate the following document into Japanese. Why is this needed Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language ja /assign
/triage accepted


Question: kubeletはリソースの割当を決定する際にトポロジーのヒントを利用できます。 詳細は、[ノードのトポロジー管理ポリシーを制御する](/docs/tasks/administer-cluster/topology-manager/)を参照してください。 <ins> ## ノードの正常終了 {#graceful-node-shutdown} {{< feature-state state="beta" for_k8s_version="v1.21" >}} kubeletは、ノードのシステムシャットダウンを検出すると、ノード上で動作しているPodを終了させます。 Kubelet は、ノードのシャットダウン時に、ポッドが通常の[通常のポッド終了プロセス](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)に従うようにします。 Graceful Node Shutdownはsystemdに依存しているため、[systemd inhibitor locks](https://www.freedesktop.org/wiki/Software/systemd/inhibit/)を 利用してノードのシャットダウンを一定時間遅らせることができます。 Graceful Node Shutdownは、v1.21でデフォルトで有効になっている`GracefulNodeShutdown` [フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)で制御されます。 なお、デフォルトでは、後述の設定オプション`ShutdownGracePeriod`および`ShutdownGracePeriodCriticalPods`の両方がゼロに設定されているため、Graceful node shutdownは有効になりません。この機能を有効にするには、この2つのkubeletの設定を適切に設定し、ゼロ以外の値を設定する必要があります。 Graceful shutdownでは、kubeletは以下の2段階でPodを終了させます。 1. そのノード上で動作している通常のPodを終了させます。 2. そのノード上で動作している[critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)を終了させます。 Graceful Node Shutdownには、2つの[`KubeletConfiguration`](/docs/tasks/administer-cluster/kubelet-config-file/)オプションを設定します。: * `ShutdownGracePeriod`: *  ノードがシャットダウンを遅らせるべき合計期間を指定します。これは、通常のPodと[critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)の両方のPod終了の合計猶予期間です。 * `ShutdownGracePeriodCriticalPods`: * ノードのシャットダウン時に[critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)を終了させるために使用する期間を指定します。この値は、ShutdownGracePeriodよりも小さくする必要があります。 例えば、`ShutdownGracePeriod=30s`、`ShutdownGracePeriodCriticalPods=10s`とすると、 kubeletはノードのシャットダウンを30秒遅らせます。シャットダウンの間、最初の20(30-10)秒は通常のポッドを優雅に終了させるために確保され、 残りの10秒は重要なポッドを終了させるために確保されることになります。 {{< note >}} Graceful Node Shutdown中にPodが退避された場合、それらのPodの`.status`は`Failed`になります。 `kubectl get pods`を実行すると、退避させられたPodのステータスが `Shutdown` と表示されます。 また、`kubectl describe pod`を実行すると、ノードのシャットダウンのためにPodが退避されたことがわかります。 ``` Status:         Failed Reason:         Shutdown Message:        Node is shutting, evicting pods ``` 失敗したポッドオブジェクトは、明示的に削除されるか、[GCによってクリーンアップ](/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)されるまで保存されます。 これは、ノードが突然終了した場合とは異なった振る舞いです。 {{< /note >}} ## スワップメモリの管理 {#swap-memory} {{< feature-state state="alpha" for_k8s_version="v1.22" >}} Kubernetes 1.22以前では、ノードはスワップメモリの使用をサポートしておらず、ノード上でスワップが検出された場合、 kubeletはデフォルトで起動に失敗していました。1.22以降では、スワップメモリのサポートをノードごとに有効にすることができます。 ノードでスワップを有効にするには、kubeletの `NodeSwap` [フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にし、 `--fail-swap-on`コマンドラインフラグまたは`failSwapOn`[KubeletConfiguration](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)を false に設定する必要があります。 ユーザーはオプションで、ノードがスワップメモリをどのように使用するかを指定するために、`memorySwap.swapBehavior`を設定することもできます。ノードがスワップメモリをどのように使用するかを指定します。例えば、以下のようになります。 ```yaml memorySwap: swapBehavior: LimitedSwap ``` swapBehaviorで使用できる設定オプションは以下の通りです。: - `LimitedSwap`: Kubernetesのワークロードが、使用できるスワップ量に制限を設けます。Kubernetesが管理していないノード上のワークロードは、依然としてスワップを使用できます。 - `UnlimitedSwap`: Kubernetesのワークロードが使用できるスワップ量に制限を設けません。システムの限界まで、要求されただけのスワップメモリを使用することができます。 `memorySwap`の設定が指定されておらず、[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)が有効な場合、 デフォルトのkubeletは`LimitedSwap`の設定と同じ動作を適用します。 `LimitedSwap`設定の動作は、ノードがコントロールグループ(「cgroups」とも呼ばれる)のv1とv2のどちらで動作しているかによって異なります。 Kubernetesのワークロードでは、メモリとスワップを組み合わせて使用することができ、ポッドのメモリ制限が設定されている場合はその制限まで使用できます。 - **cgroupsv1:** Kubernetesのワークロードは、メモリとスワップを組み合わせて使用することができ、ポッドのメモリ制限が設定されている場合はその制限まで使用できます。 - **cgroupsv2:** Kubernetesのワークロードは、スワップメモリを使用できません。 詳しくは、[KEP-2400](https://github.com/kubernetes/enhancements/issues/2400)と [design proposal](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/2400-node-swap/README.md) をご覧いただき、テストにご協力、ご意見をお聞かせください。 </ins> ## {{% heading "whatsnext" %}} * [ノードコンポーネント](/ja/docs/concepts/overview/components/#node-components)について学習する。

This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be <!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --About Graceful node shutdown Swap memory management Why is this needed Graceful node shutdown is FEATURE STATE: Kubernetes v1.21 [beta] and Swap memory management is FEATURE STATE: Kubernetes v1.22 [alpha] The Japanese documents do not reflect the latest updates of them. In addition to that, I made some corrections. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --
/language ja
/assign
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
/remove-lifecycle rotten because the related PR is under reviewing /triage accepted


Question: {{< feature-state for_k8s_version="v1.14" state="stable" >}} <del> 追加のフィードバックやシグナルをPodStatus:_Pod readiness_に注入できるようにします。これを使用するには、Podの`spec`で`readinessGates`を設定して、kubeletがPodのReadinessを評価する追加の状態のリストを指定します。 </del> <ins> 追加のフィードバックやシグナルをPodStatus:*Pod readiness*に注入できるようにします。これを使用するには、Podの`spec`で`readinessGates`を設定して、kubeletがPodのReadinessを評価する追加の状態のリストを指定します。 </ins> ReadinessゲートはPodの`status.conditions`フィールドの現在の状態によって決まります。Kubernetesが`Podのstatus.conditions`フィールドでそのような状態を発見できない場合、ステータスはデフォルトで`False`になります。

This is a Feature Request What would you like to be We need to update content/ja/docs/concepts/workloads/pods/pod- according to the English text, because it is outdated. Why is this needed content/ja/docs/concepts/workloads/pods/pod- is outdated. For example, there is no description of PodHasNetwork(alpha feature). Comments /language ja /assign
/triage accepted


Question: The following networking options are sorted alphabetically - the order does not imply any preferential status. <ins> {{% thirdparty-content %}} </ins> ### ACI [Cisco Application Centric Infrastructure](https://www.cisco.com/c/en/us/solutions/data-center-virtualization/application-centric-infrastructure/index.html) offers an integrated overlay and underlay SDN solution that supports containers, virtual machines, and bare metal servers. [ACI](https://www.github.com/noironetworks/aci-containers) provides container networking integration for ACI. An overview of the integration is provided [here](https://www.cisco.com/c/dam/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/solution-overview-c22-739493.pdf).

Per our discussion in today's SIG Docs: Sections of the site, like will always have some degree of 3rd party content, due to the fact that a k8s developer must implement an external networking CNI. The majority of post-3rd party content KEP PR's we get that actually involve third party content are to pages like this one. A part of the reasons is that a change like the KEP requires initial communication (which was well done) but also ongoing communication. This change proposes the following: Create a reusable Note or similar shortcode for pages that fall under . The note should: Be translatable (use a key) Warn people that they must use a 3rd party plugin/software for this step Indicate that per the projects are listed alphabetically Indicate that additions to this list/page must directly provide a solution for this step of an implementation (i.e. for the cluster networking page, projects listed must provide a networking solution – no 'nice to haves' that make networking easier or somehow nicer.) Link to the content guidelines for more info on acceptable additions to the page.
/assign /area web-development /priority important-longterm
/language en
Wording for review: This section contains links to third party projects which provide functionality required by Kubernetes. The Kubernetes project authors are not responsible for these projects. Projects are listed alphabetically, in accordance with [CNCF website guidelines]. To add a project to this list, read the <a href="/contribute/style/content-guide/#third-party-content"content guide</abefore submitting a change.
Related:
How about:
LGTM, I'll go ahead and implement. Thank you for the edit!
Hello , Some late feedback (sorry I missed the meeting): Since this is a "special" note, I think it warrants a different color on the left hand border. Is there another shortcode besides note or warning that could be used to set off the text? Could substitute the shortcode "Note" text with "Third party content"? The language in the third party content message is a bit obtuse. When this label is applied, can the reader assume that all content on the page falls under these guidelines? This sentence, "Kubernetes project authors are not responsible for these projects" seems repetitive. Third party implies an external source and outside of the project's domain.

Is there another shortcode besides note or warning that could be used to set off the text? Could substitute the shortcode "Note" text with "Third party content"? All good feedback. How would you phrase it differently?
Hi. I am not entirely sure. The text is okay, though, it may not be clear about what is "required for Kubernetes to function". What do you want readers to do: determine if their project belongs in the section (read the content guide) read the content as third party content (Sig Docs is hosting the links but not responsible for the content on the page)? [One idea:] This section links to third party projects and follows [CNCF website guidelines] by listing projects alphabetically. [Do you want to suggest adding content or not?] If you are considering adding content in this section, read the before submitting a change. [Do you need a statement about content responsibility?]
Is there another shortcode besides note or warning that could be used to set off the text? Could substitute the shortcode "Note" text with "Third party content"? I think this is a good suggestion. I'll update the PR. What do you want readers to do: This section links to third party projects and follows [CNCF website guidelines] by listing projects alphabetically. If you are considering adding content in this section, read the content guide before submitting a change. Is this blocking for the PR? If we can't come up with a concrete alternative, I'd prefer to merge the PR, re-open this issue, and continue to work on the wording. Would that be okay,
Sure . I think what you have is fine. As an aside, did you consider using the theme's shortcode (which has a parameter)? It may work as well as wrapping the "third party content" shortcode in a note/warning shortcode. I think you can set the attribute too.
I'm imagining a one-line shortcode that, when rendered, closely matches the styles of existing callouts. I'd rather not use callouts from the Docsy theme because that's different from our existing callouts (something to handle in a separate issue, I feel). Wording-wise I'm happy to see something merged and leave room to iterate. Would you be happy to implement that?
Hi.

I agree, let's get this change moving forward with a single line shortcode with similar styling to the existing callouts. The shortcode would use two template strings: one variable for the message title and another variable for the message body. In the future, I could imagine a flexible interface or more generic shortcode that accepts at least one argument: the name of the variable representing the message title.


Question:
 {{/* Link directly to documentation etc., if possible. */}} {{ $langPage := cond (gt (len .Translations) 0) . .Site.Home }}  {{ $langPage.Language.LanguageName }}
 {{ range $langPage.Translations }} {{ .Language.LanguageName }} {{ end }}
   No newline at end of file

Expected behavior: https://v1- (drop-downs work) Actual behavior: (drop-downs do not work) This may be a issue or a result of non-translated pages not showing up in autogenerated navs. I'm unsure.
/assign /priority important-soon /kind bug
Hello, calestehorgan I investigated this problem quickly and found that (this is the version and language box) seemed to remain when the mouse cursor has hovered. ! Adding the following style makes the problem disappeared: ! Maybe some style is missing or something blocks a style applied.
Thank you for the help!! I'll try it out.
I'm glad to help!


Question: title: kube-apiserver id: kube-apiserver date: 2018-04-12 <del> full_link: /docs/reference/generated/kube-apiserver/ </del> <ins> full_link: /zh/docs/reference/command-line-tools-reference/kube-apiserver/ </ins> short_description: > <del> 主节点上负责提供 Kubernetes API 服务的组件；它是 Kubernetes 控制面的前端。 </del> <ins> 提供 Kubernetes API 服务的控制面组件。 </ins> aka: tags:

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: when I finished the translation of docs/reference/using-api/health-, I found a broken link when clicked the "API ":  Proposed Solution: fix it in
/language zh /assign /kind bug
/triage accepted