Merge pull request #50064 from rayandas/merged-main-dev-1.33

Merged main dev-1.33

Author: k8s-ci-robot

Diff for: OWNERS_ALIASES

@@ -139,6 +139,7 @@ aliases:
   sig-docs-ko-owners: # Admins for Korean content
     - gochist
     - jihoon-seo
+    - jongwooo
     - seokho-son
     - yoonian
     - ysyukr

Diff for: content/en/blog/_posts/2025-02-03-introducing-jobset/index.md renamed to content/en/blog/_posts/2025-03-23-introducing-jobset/index.md

@@ -1,9 +1,8 @@
 ---
 layout: blog
 title: "Introducing JobSet"
-date: 2025-02-03
+date: 2025-03-23
 slug: introducing-jobset
-draft: true
 ---
 
 **Authors**: Daniel Vega-Myhre (Google), Abdullah Gharaibeh (Google), Kevin Hannon (Red Hat)

Diff for: content/en/blog/_posts/2025-02-03-introducing-jobset/jobset_diagram.svg renamed to content/en/blog/_posts/2025-03-23-introducing-jobset/jobset_diagram.svg

@@ -6,8 +6,8 @@
 logo: nokia_featured_logo.png
 
 new_case_study_styles: true
-heading_background: /images/case-studies/nokia/banner1.jpg
-heading_title_logo: /images/nokia_logo.png
+heading_background: /images/case-studies/nokia/banner3.jpg
+heading_title_logo: /images/nokia-white-on-transparent.png
 subheading: >
   Nokia: Enabling 5G and DevOps at a Telecom Company with Kubernetes
 case_study_details:
@@ -41,7 +41,6 @@ <h2>Impact</h2>
 <p>Looking for a way to allow its teams to build products with infrastructure-agnostic behavior, the company decided to embrace containerization, Kubernetes, and other cloud native technologies, a move that is being made across the telecom industry. Since early 2018, "when people are picking up their phones and making a call on Nokia networks, they are creating containers in the background with Kubernetes," says Csatari. "Now, all the products are doing some kind of re-architecture work, and they're moving to Kubernetes."</p>
 
 {{< case-studies/quote
-  image="/images/case-studies/nokia/banner3.jpg"
   author="Gergely Csatari, Senior Open Source Engineer, Nokia"
 >}}
 "Having the community and CNCF around Kubernetes is not only important for having a connection to other companies who are using Kubernetes and a forum where you can ask or discuss features of Kubernetes. But as a company who would like to contribute to Kubernetes, it was very important to have a CLA (Contributors License Agreement) which is connected to the CNCF and not to a particular company. That was a critical step for us to start contributing to Kubernetes and Helm."
@@ -54,7 +53,6 @@ <h2>Impact</h2>
 <p>That meant that they needed to be able to set affinity and anti-affinity rules in their orchestration tools. "You cannot put all of the functions to the same physical host because physical hosts are failing," Csatari explains. "If you fail with one physical host, then you lose all of the core processing processes. Then there are no calls going through. So we have to divide them among the different physical hosts. At that time, only Kubernetes was able to provide these features. The simplicity of the label-based scheduling of Kubernetes was a sign that showed us this architecture will scale, will be stable, and will be good for our purposes."</p>
 
 {{< case-studies/quote 
-  image="/images/case-studies/nokia/banner4.jpg"
   author="Gergely Csatari, Senior Open Source Engineer, Nokia"
 >}}
 "Kubernetes opened the window to all of these open source projects instead of implementing everything in house. Our engineers can focus more on the application level, which is actually the thing what we are selling, and not on the infrastructure level. For us, the most important thing about Kubernetes is it allows us to focus on value creation of our business."

Diff for: content/en/case-studies/nokia/index.html

@@ -238,5 +238,4 @@ The output is similar to this:
 ## {{% heading "whatsnext" %}}
 
 * [Learn more about `crictl`](https://github.com/kubernetes-sigs/cri-tools).
-* [Map `docker` CLI commands to `crictl`](/docs/reference/tools/map-crictl-dockercli/).
 

Diff for: content/en/case-studies/nokia/nokia_featured_logo.jpg

@@ -145,6 +145,24 @@ <h5>
   </div>
 </section>
 
+
+<section class="call-to-action">
+  <div class="main-section">
+    <div class="call-to-action" id="cta-kubestronaut">
+      <div class="cta-text">
+        <h2>Kubestronaut Program: Elevate Your Kubernetes Expertise</h2>
+        <p> The CNCF's Kubestronaut Program celebrates and recognizes exceptional community leaders who have demonstrated a profound commitment to mastering Kubernetes. This prestigious initiative highlights individuals who have consistently invested in their ongoing education and achieved the highest levels of proficiency. To earn the esteemed title of Kubestronaut, individuals must successfully obtain and maintain all five CNCF Kubernetes certifications: Certified Kubernetes Administrator (CKA), Certified Kubernetes Application Developer (CKAD), Certified Kubernetes Security Specialist (CKS), Kubernetes and Cloud Native Associate (KCNA), and Kubernetes and Cloud Security Associate (KCSA). </p>
+      </div>
+      <div class="cta-img-container">
+        <div class="logo-certification cta-image" id="logo-kubestronaut">
+          <img src="/images/training/kubestronaut-stacked-color.svg" />
+        </div>
+      </div>
+    </div>
+  </div>
+</section>
+
+
 <div class="padded lighter-gray-bg">
   <div class="main-section two-thirds-centered">
     <center>
@@ -155,4 +173,4 @@ <h2>Kubernetes Training Partners</h2>
   <div class="main-section landscape-section">
     {{< cncf-landscape helpers=false category="special--kubernetes-training-partner" >}}
   </div>
-</div>
+</div>

Diff for: content/en/case-studies/nokia/nokia_featured_logo.png

@@ -38,7 +38,7 @@ Huawei Cloud | https://www.huaweicloud.com/intl/id-id/securecenter/overallsafety
 IBM Cloud | https://www.ibm.com/cloud/security |
 Microsoft Azure | https://docs.microsoft.com/en-us/azure/security/azure-security |
 Oracle Cloud Infrastructure | https://www.oracle.com/security/ |
-VMWare VSphere | https://www.vmware.com/security/hardening-guides.html |
+VMWare VSphere | https://www.vmware.com/solutions/security/hardening-guides |
 
 Jika kamu mengoperasikan perangkat keras kamu sendiri, atau penyedia layanan cloud yang berbeda, kamu perlu merujuk pada dokumentasi penyedia layanan cloud yang kamu pakai untuk praktik keamanan terbaik.
 

Diff for: content/en/case-studies/nokia/nokia_featured_logo.svg

@@ -57,7 +57,7 @@ IBM Cloud | https://www.ibm.com/cloud/security |
 Microsoft Azure | https://docs.microsoft.com/en-us/azure/security/azure-security |
 Oracle Cloud Infrastructure | https://www.oracle.com/security |
 Tencent Cloud | https://www.tencentcloud.com/solutions/data-security-and-information-protection |
-VMware vSphere | https://www.vmware.com/security/hardening-guides |
+VMware vSphere | https://www.vmware.com/solutions/security/hardening-guides |
 
 {{< /table >}} 
 

Diff for: content/en/docs/tasks/debug/debug-cluster/crictl.md

@@ -46,7 +46,7 @@ Huawei Cloud | https://www.huaweicloud.com/intl/ja-jp/securecenter/overallsafety
 IBM Cloud | https://www.ibm.com/cloud/security |
 Microsoft Azure | https://docs.microsoft.com/en-us/azure/security/azure-security |
 Oracle Cloud Infrastructure | https://www.oracle.com/security/ |
-VMWare VSphere | https://www.vmware.com/security/hardening-guides.html |
+VMWare VSphere | https://www.vmware.com/solutions/security/hardening-guides |
 
 {{< /table >}}
 

Diff for: content/en/training/_index.html

@@ -100,7 +100,7 @@ KEDAは例えばキューのメッセージ数などの処理するべきイベ
 
 ワークロードををスケールするためのもう一つの戦略は、例えばオフピークの時間帯にリソース消費を削減するために、スケーリング操作を**スケジュールする**ことです。
 
-イベント駆動型オートスケーリングと同様に、そのような動作はKEDAを[`Cron`スケーラー](https://keda.sh/docs/2.13/scalers/cron/)と組み合わせて使用することで実現できます。
+イベント駆動型オートスケーリングと同様に、そのような動作はKEDAを[`Cron`スケーラー](https://keda.sh/docs/latest/scalers/cron/)と組み合わせて使用することで実現できます。
 `Cron`スケーラーによりワークロードをスケールインまたはスケールアウトするためのスケジュール（およびタイムゾーン）を定義できます。
 
 ## クラスターのインフラストラクチャーのスケーリング {#scaling-cluster-infrastructure}

Diff for: content/id/docs/concepts/security/overview.md

@@ -170,7 +170,7 @@ as root:
   kubeadm join <control-plane-host>:<control-plane-port> --token <token> --discovery-token-ca-cert-hash sha256:<hash>
 ```
 
-kubectlをroot以外のユーザーでも実行できるようにするには、次のコマンドを実行します。これらのコマンドは、`kubectl init`の出力の中にも書かれています。
+kubectlをroot以外のユーザーでも実行できるようにするには、次のコマンドを実行します。これらのコマンドは、`kubeadm init`の出力の中にも書かれています。
 
 ```bash
 mkdir -p $HOME/.kube

Diff for: content/ja/docs/concepts/security/_index.md

@@ -114,10 +114,6 @@ weight: 110
     http://172.17.0.15:31637
     ```
 
-    {{< note >}}
-    Katacoda環境の場合のみ: 上部のterminalパネルでプラスのアイコンをクリックして、**Select port to view on Host 1**(Host 1を表示するポートを選択)をクリックします。NodePort(上の例では`31637`)を入力して、**Display Port**(ポートを表示)をクリックしてください。
-    {{< /note >}}
-
     出力は次のようになります。
 
     ```shell

Diff for: content/ja/docs/concepts/security/overview.md

@@ -0,0 +1,6 @@
+---
+title: "クラスターデーモンの管理"
+description: ローリングアップデートの実行など、DaemonSetを管理するための一般的なタスクを実行します。
+weight: 130
+---
+

Diff for: content/ja/docs/concepts/workloads/autoscaling.md

@@ -0,0 +1,66 @@
+---
+title: 基本的なDaemonSetを構築する
+content_type: task  
+weight: 5  
+---
+<!-- overview -->
+
+このページでは、Kubernetesクラスターの全てのノード上でPodを実行する、基本的な{{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}を構築する方法について示します。
+ホストからファイルをマウントし、[Initコンテナ](/ja/docs/concepts/workloads/pods/init-containers/)を使用してその内容をログに記録して、pauseコンテナを利用するという単純なユースケースを取り上げます。
+
+## {{% heading "prerequisites" %}}
+
+{{< include "task-tutorial-prereqs.md" >}}
+
+DaemonSetの動作を示すために、少なくとも2つのノード(1つのコントロールプレーンと1つのワーカーノード)を持つKubernetesクラスターを用意します。
+
+## DaemonSetの定義
+
+このタスクでは、Podのコピーが全てのノード上でスケジュールされるようにする、基本的なDaemonSetが作成されます。
+PodはInitコンテナを使用してホストから`/etc/machine-id`の内容を読み込んでログに記録し、メインのコンテナはPodを実行し続ける`pause`コンテナとなります。
+
+{{% code_sample file="application/basic-daemonset.yaml" %}}
+
+1. (YAML)マニフェストに基づいたDaemonSetを作成します:
+
+   ```shell
+   kubectl apply -f https://k8s.io/examples/application/basic-daemonset.yaml
+   ```
+
+1. 適用すると、DaemonSetがクラスター内の全てのノードでPodを実行していることを確認できます:
+
+   ```shell
+   kubectl get pods -o wide
+   ```
+
+   出力には、以下のようにノード毎に1つのPodが一覧表示されます:
+
+   ```
+   NAME                                READY   STATUS    RESTARTS   AGE    IP       NODE
+   example-daemonset-xxxxx             1/1     Running   0          5m     x.x.x.x  node-1
+   example-daemonset-yyyyy             1/1     Running   0          5m     x.x.x.x  node-2
+   ```
+
+1. ホストからマウントされたログディレクトリをチェックすることで、ログに記録された`/etc/machine-id`ファイルの内容を調べることができます:
+
+   ```shell
+   kubectl exec <pod-name> -- cat /var/log/machine-id.log
+   ```
+
+   `<pod-name>`は1つのPodの名前です。
+
+## {{% heading "cleanup" %}}
+
+DaemonSetを削除するためには、次のコマンドを実行します:
+
+```shell
+kubectl delete --cascade=foreground --ignore-not-found --now daemonsets/example-daemonset
+```
+
+この単純なDaemonSetの例では、Initコンテナやホストパスボリュームなどの主要なコンポーネントを紹介しており、より高度なユースケースに応じて拡張することができます。
+詳細については[DaemonSet](/ja/docs/concepts/workloads/controllers/daemonset/)を参照してください。
+
+## {{% heading "whatsnext" %}}
+
+* [DaemonSet上でローリングアップデートを実施する](/docs/tasks/manage-daemon/update-daemon-set/)を参照
+* [既存のDaemonSetのPodを再利用してDaemonSetを作成する](/ja/docs/concepts/workloads/controllers/daemonset/)を参照

Diff for: content/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md

@@ -0,0 +1,101 @@
+---
+title: PodからKubernetes APIにアクセスする
+content_type: task
+weight: 120
+---
+
+<!-- overview -->
+
+このガイドでは、Pod内からKubernetes APIにアクセスする方法を示します。
+
+## {{% heading "prerequisites" %}}
+
+{{< include "task-tutorial-prereqs.md" >}}
+
+<!-- steps -->
+
+## Pod内からAPIへのアクセス
+
+Podの中からAPIにアクセスする時、APIサーバーの場所の検出と認証は、外部クライアントの場合とは若干異なります。
+
+PodからKubernetes APIを使用する最も簡単な方法は、公式の[クライアントライブラリ](/docs/reference/using-api/client-libraries/)を使用することです。
+これらのライブラリは自動的にAPIサーバーを検出して認証できます。
+
+### 公式クライアントライブラリの使用
+
+Podの中からKubernetes APIに接続する推奨された方法として次のものがあります:
+
+- Goクライアントの場合、公式の[Goクライアントライブラリ](https://github.com/kubernetes/client-go/)を使用します。
+  `rest.InClusterConfig()`関数はAPIホストの探索と認証を自動的に処理します。
+  [ここにあるサンプル](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go)を参照してください。
+
+- Pythonクライアントの場合、公式の[Pythonクライアントライブラリ](https://github.com/kubernetes-client/python/)を使用します。
+  `config.load_incluster_config()`関数はAPIホストの探索と認証を自動的に処理します。
+  [ここにあるサンプル](https://github.com/kubernetes-client/python/blob/master/examples/in_cluster_config.py)を参照してください。
+
+- 他にも多くのライブラリが利用できます。
+  [クライアントライブラリ](/docs/reference/using-api/client-libraries/)のページを参照してください。
+
+いずれの場合も、APIサーバーと安全に通信するために、Podのサービスアカウントの資格情報が使用されます。
+
+### REST APIによる直接アクセス
+
+コンテナは、Pod内での実行中に環境変数`KUBERNETES_SERVICE_HOST`と`KUBERNETES_SERVICE_PORT_HTTPS`を取得することで、Kubernetes APIサーバーのHTTPSのURLを作成することができます。
+APIサーバーのクラスター内アドレスは、PodがローカルAPIサーバーのDNS名として`kubernetes.default.svc`を参照できるように、`default` Namespaceの`kubernetes`という名前のServiceにも公開されます。
+
+{{< note >}}
+Kubernetesは、APIサーバーがホスト名`kubernetes.default.svc`に対する有効な証明書を持っていることを保証しません。
+しかし、コントロールプレーンは`$KUBERNETES_SERVICE_HOST`によって表されるホスト名またはIPアドレスに対する有効な証明書を提示することが期待**されます**。
+{{< /note >}}
+
+APIサーバーに対して認証を行う推奨された方法は、[サービスアカウント](/docs/tasks/configure-pod-container/configure-service-account/)の資格情報を使用することです。
+既定では、Podはサービスアカウントと関連づけられており、そのサービスアカウントに対する資格情報(トークン)が、そのPod内の各コンテナのファイルシステムツリーの`/var/run/secrets/kubernetes.io/serviceaccount/token`内に配置されます。
+
+利用可能であれば、証明書バンドルが各コンテナのファイルシステムツリーの`/var/run/secrets/kubernetes.io/serviceaccount/ca.crt`に配置され、APIサーバーが提供する証明書を検証するために使用されます。
+
+最後に、NamespaceスコープのAPIの操作に対して使用される既定のNamespaceは、各コンテナの`/var/run/secrets/kubernetes.io/serviceaccount/namespace`にあるファイルに記載されます。
+
+### kubectl proxyの使用
+
+公式のクライアントライブラリを使用せずにAPIを呼び出したい場合は、Pod内の新しいサイドカーコンテナの[コマンド](/docs/tasks/inject-data-application/define-command-argument-container/)として`kubectl proxy`を実行することができます。
+こうすることで、`kubectl proxy`がAPIを認証してPodの`localhost`インターフェースに公開するため、Pod内の他のコンテナが直接使用することができます。
+
+### プロキシを使用しない方法
+
+認証トークンを直接APIサーバーに渡すことで、kubectl proxyの使用を避けることも可能です。
+内部の証明書によって接続を保護します。
+
+```shell
+# 内部のAPIサーバーのホスト名の指定
+APISERVER=https://kubernetes.default.svc
+
+# ServiceAccountトークンのパス
+SERVICEACCOUNT=/var/run/secrets/kubernetes.io/serviceaccount
+
+# PodのNamespaceの読み込み
+NAMESPACE=$(cat ${SERVICEACCOUNT}/namespace)
+
+# ServiceAccountのBearerトークンを取得
+TOKEN=$(cat ${SERVICEACCOUNT}/token)
+
+# 内部の認証局(CA)の参照
+CACERT=${SERVICEACCOUNT}/ca.crt
+
+# トークンを用いてAPIの探索
+curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/api
+```
+
+次のような出力になります:
+
+```json
+{
+  "kind": "APIVersions",
+  "versions": ["v1"],
+  "serverAddressByClientCIDRs": [
+    {
+      "clientCIDR": "0.0.0.0/0",
+      "serverAddress": "10.0.1.149:443"
+    }
+  ]
+}
+```

Diff for: content/ja/docs/tasks/access-application-cluster/ingress-minikube.md

@@ -0,0 +1,34 @@
+apiVersion: apps/v1
+kind: DaemonSet
+metadata:
+  name: example-daemonset
+spec:
+  selector:
+    matchLabels:
+      app.kubernetes.io/name: example
+  template:
+    metadata:
+      labels:
+        app.kubernetes.io/name: example
+    spec:
+      containers:
+      - name: pause
+        image: registry.k8s.io/pause
+      initContainers:
+      - name: log-machine-id
+        image: busybox:1.37
+        command: ['sh', '-c', 'cat /etc/machine-id > /var/log/machine-id.log']
+        volumeMounts:
+        - name: machine-id
+          mountPath: /etc/machine-id
+          readOnly: true
+        - name: log-dir
+          mountPath: /var/log
+      volumes:
+      - name: machine-id
+        hostPath:
+          path: /etc/machine-id
+          type: File
+      - name: log-dir
+        hostPath:
+          path: /var/log

Diff for: content/ja/docs/tasks/manage-daemon/_index.md

@@ -0,0 +1,12 @@
+---
+title: Aktualizacja materiałów źródłowych
+main_menu: true
+weight: 80
+---
+
+Tematy w tej sekcji opisują, jak aktualizować (czyli ponownie
+wygenerować) materiały źródłowe (ang. reference documentation) Kubernetesa.
+
+Aby zbudować materiały źródłowe, zapoznaj się z następującym przewodnikiem:
+
+* [Szybki start generowania materiałów źródłowych](/docs/contribute/generate-ref-docs/quickstart/)