Question:
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 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
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

<ins> --- title: cgroup v2について content_type: concept weight: 50 --- <!-- overview --> Linuxでは、{{< glossary_tooltip text="コントロールグループ" term_id="cgroup" >}}がプロセスに割り当てられるリソースを制限しています。 コンテナ化されたワークロードの、CPU/メモリーの要求と制限を含む[Podとコンテナのリソース管理](/docs/concepts/configuration/manage-resources-containers/)を強制するために、 {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}と基盤となるコンテナランタイムはcgroupをインターフェースとして接続する必要があります。 Linuxではcgroup v1とcgroup v2の2つのバージョンのcgroupがあります。 cgroup v2は新世代の`cgroup` APIです。 <!-- body --> ## cgroup v2とは何か？ {#cgroup-v2} {{< feature-state for_k8s_version="v1.25" state="stable" >}} cgroup v2はLinuxの`cgroup` APIの次のバージョンです。 cgroup v2はリソース管理機能を強化した統合制御システムを提供しています。 以下のように、cgroup v2はcgroup v1からいくつかの点を改善しています。 - 統合された単一階層設計のAPI - より安全なコンテナへのサブツリーの移譲 - [Pressure Stall Information](https://www.kernel.org/doc/html/latest/accounting/psi.html)などの新機能 - 強化されたリソース割り当て管理と複数リソース間の隔離 - 異なるタイプのメモリー割り当ての統一(ネットワークメモリー、カーネルメモリーなど) - ページキャッシュの書き戻しといった、非即時のリソース変更 Kubernetesのいくつかの機能では、強化されたリソース管理と隔離のためにcgroup v2のみを使用しています。 例えば、[MemoryQoS](/blog/2021/11/26/qos-memory-resources/)機能はメモリーQoSを改善し、cgroup v2の基本的な機能に依存しています。 ## cgroup v2を使う {#using-cgroupv2} cgroup v2を使うおすすめの方法は、デフォルトでcgroup v2が有効で使うことができるLinuxディストリビューションを使うことです。 あなたのディストリビューションがcgroup v2を使っているかどうかを確認するためには、[Linux Nodeのcgroupバージョンを特定する](#check-cgroup-version)を参照してください。 ### 必要要件 {#requirements} cgroup v2を使うには以下のような必要要件があります。 * OSディストリビューションでcgroup v2が有効であること * Linuxカーネルバージョンが5.8以上であること * コンテナランタイムがcgroup v2をサポートしていること。例えば、 * [containerd](https://containerd.io/) v1.4以降 * [cri-o](https://cri-o.io/) v1.20以降 * kubeletとコンテナランタイムが[systemd cgroupドライバー](/docs/setup/production-environment/container-runtimes#systemd-cgroup-driver)を使うように設定されていること ### Linuxディストリビューションのcgroup v2サポート cgroup v2を使っているLinuxディストリビューションの一覧は[cgroup v2ドキュメント](https://github.com/opencontainers/runc/blob/main/docs/cgroup-v2.md)をご覧ください。 <!-- 一覧は https://github.com/opencontainers/runc/blob/main/docs/cgroup-v2.md と同期してください --> * Container-Optimized OS (M97以降) * Ubuntu (21.10以降, 22.04以降推奨) * Debian GNU/Linux (Debian 11 bullseye以降) * Fedora (31以降) * Arch Linux (April 2021以降) * RHEL and RHEL-like distributions (9以降) あなたのディストリビューションがcgroup v2を使っているかどうかを確認するためには、あなたのディストリビューションのドキュメントを参照するか、[Linux Nodeのcgroupバージョンを特定する](#check-cgroup-version)の説明に従ってください。 カーネルのcmdlineの起動時引数を修正することで、手動であなたのLinuxディストリビューションのcgroup v2を有効にすることもできます。 あなたのディストリビューションがGRUBを使っている場合は、 `/etc/default/grub`の中の`GRUB_CMDLINE_LINUX`に`systemd.unified_cgroup_hierarchy=1`を追加し、`sudo update-grub`を実行してください。 ただし、おすすめの方法はデフォルトですでにcgroup v2が有効になっているディストリビューションを使うことです。 ### cgroup v2への移行 {#migrating-cgroupv2} cgroup v2に移行するには、[必要要件](#requirements)を満たすことを確認し、 cgroup v2がデフォルトで有効であるカーネルバージョンにアップグレードします。 kubeletはOSがcgroup v2で動作していることを自動的に検出し、それに応じて処理を行うため、追加設定は必要ありません。 ノード上やコンテナ内からユーザーが直接cgroupファイルシステムにアクセスしない限り、cgroup v2に切り替えたときのユーザー体験に目立った違いはないはずです。 cgroup v2はcgroup v1とは違うAPIを利用しているため、cgroupファイルシステムに直接アクセスしているアプリケーションはcgroup v2をサポートしている新しいバージョンに更新する必要があります。例えば、 * サードパーティーの監視またはセキュリティエージェントはcgroupファイルシステムに依存していることがあります。 エージェントをcgroup v2をサポートしているバージョンに更新してください。 * Podやコンテナを監視するために[cAdvisor](https://github.com/google/cadvisor)をスタンドアローンのDaemonSetとして起動している場合、v0.43.0以上に更新してください。 * JDKを利用している場合、[cgroup v2を完全にサポートしている](https://bugs.openjdk.org/browse/JDK-8230305)JDK 11.0.16以降、またはJDK15以降を利用することが望ましいです。 ## Linux Nodeのcgroupバージョンを特定する {#check-cgroup-version} cgroupバージョンは利用されているLinuxディストリビューションと、OSで設定されているデフォルトのcgroupバージョンに依存します。 あなたのディストリビューションがどちらのcgroupバージョンを利用しているのかを確認するには、`stat -fc %T /sys/fs/cgroup/`コマンドをノード上で実行してください。 ```shell stat -fc %T /sys/fs/cgroup/ ``` cgroup v2では、`cgroup2fs`と出力されます。 cgroup v1では、`tmpfs`と出力されます。 ## {{% heading "whatsnext" %}} - [cgroups](https://man7.org/linux/man-pages/man7/cgroups.7.html)についてもっと学習しましょう。 - [コンテナランタイム](/ja/docs/concepts/architecture/cri)についてもっと学習しましょう。 - [cgroupドライバー](/docs/setup/production-environment/container-runtimes#cgroup-drivers)についてもっと学習しましょう。 </ins>


Question:
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: The image files in need to be converted to an SVG. Currently, they are PNG. The originals are PPT files that can be found at Earlier attempts to convert them to SVG resulted in poor-quality images. Proposed Solution: If anyone has the tools and expertise to convert the PNG/PPT to high-quality SVG that will look the same as the PNGs, we welcome the help. Page to Update: <!--Optional Information (remove the comment tags around the information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/assign If anyone gets to this first: great!
hey! looking to contribute to this project !..can I?
/triage accepted
I've made progress on this and hope to send in a PR later this week.

Being vulnerable does not necessarily mean that your service will be exploited. Though your services are vulnerable in some ways unknown to you, offenders still need to identify these vulnerabilities and then exploit them. If offenders fail to exploit your service vulnerabilities, you win! In other words, having a vulnerability that can’t be exploited, represents a risk that can’t be realized. <del> {{< figure src="Example.png" alt="Image of an example of offender gaining foothold in a service" class="diagram-large" caption="Figure 1. An Offender gaining foothold in a vulnerable service" >}} </del> <ins> {{< figure src="security_behavior_figure_1.svg" alt="Image of an example of offender gaining foothold in a service" class="diagram-large" caption="Figure 1. An Offender gaining foothold in a vulnerable service" >}} </ins> The above diagram shows an example in which the offender does not yet have a foothold in the service; that is, it is assumed that your service does not run code controlled by the offender on day 1. In our example the service has vulnerabilities in the API exposed to clients. To gain an initial foothold the offender uses a malicious client to try and exploit one of the service API vulnerabilities. The malicious client sends an exploit that triggers some unplanned behavior of the service.


Question:
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: The image files in need to be converted to an SVG. Currently, they are PNG. The originals are PPT files that can be found at Earlier attempts to convert them to SVG resulted in poor-quality images. Proposed Solution: If anyone has the tools and expertise to convert the PNG/PPT to high-quality SVG that will look the same as the PNGs, we welcome the help. Page to Update: <!--Optional Information (remove the comment tags around the information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/assign If anyone gets to this first: great!
hey! looking to contribute to this project !..can I?
/triage accepted
I've made progress on this and hope to send in a PR later this week.

Kubernetes is often used to support workloads designed with microservice architecture. By design, microservices aim to follow the UNIX philosophy of "Do One Thing And Do It Well". Each microservice has a bounded context and a clear interface. In other words, you can expect the microservice clients to send relatively regular requests and the microservice to present a relatively regular behavior as a response to these requests. Consequently, a microservice architecture is an excellent candidate for security-behavior monitoring. <del> {{< figure src="Microservices.png" alt="Image showing why microservices are well suited for security-behavior monitoring" class="diagram-large" caption="Figure 2. Microservices are well suited for security-behavior monitoring" >}} </del> <ins> {{< figure src="security_behavior_figure_2.svg" alt="Image showing why microservices are well suited for security-behavior monitoring" class="diagram-large" caption="Figure 2. Microservices are well suited for security-behavior monitoring" >}} </ins> The diagram above clarifies how dividing a monolithic service to a set of microservices improves our ability to perform security-behavior monitoring and control. In a monolithic service approach, different client requests are intertwined, resulting in a diminished ability to identify irregular client behaviors. Without prior knowledge, an observer of the intertwined client requests will find it hard to distinguish between types of requests and their related characteristics. Further, internal client requests are not exposed to the observer. Lastly, the aggregated behavior of the monolithic service is a compound of the many different internal behaviors of its components, making it hard to identify irregular service behavior.