Kubernetesに貢献する

Kubernetesに貢献する方法はたくさんあります。 新機能の設計に取り組むこともできますし、既存のコードにドキュメントを追加することも、ブログで記事を書くこともできます。 それだけではありません。新機能を実装したり、バグを修正したりすることもできます。 貢献者コミュニティへの参加を支援することも、既存の貢献者をサポートすることもできます。

様々な方法でプロジェクトに貢献することができるため、Kubernetesは https://k8s.dev/ という専用のウェブサイトを作成しました。 Kubernetesへの貢献についてもっと学ぶために、参照することができます。

もし この ドキュメントへの貢献について特に学びたい場合は、Kubernetesドキュメントへの貢献を参照してください。

また、Kubernetesへの貢献については、CNCFのページを参照することもできます。

1 - Kubernetesのドキュメントに貢献する

このウェブサイトはKubernetes SIG Docsが管理しています。 Kubernetesプロジェクトは初心者でも経験者でも、全てのコントリビューターからの改善を歓迎しています！

Kubernetesドキュメントコントリビューターは

備考:

Kubernetesへの貢献について総合的に知りたい場合は、contributor documentationを参照してください。

はじめに

どなたでも、問題を説明するissueや、ドキュメントの改善を求めるissueを作成し、kubernetes/website GitHubリポジトリに対するプルリクエスト(PR)を用いて変更に貢献することができます。 Kubernetesコミュニティで効果的に働くためには、gitとGitHubを基本的に使いこなせる必要があります。

ドキュメンテーションに関わるには:

  1. CNCFのContributor License Agreementにサインしてください。
  2. ドキュメンテーションのリポジトリと、ウェブサイトの静的サイトジェネレーターに慣れ親しんでください。
  3. プルリクエストのオープンと変更レビューの基本的なプロセスを理解していることを確認してください。

flowchart TB subgraph third[プルリクエストのオープン] direction TB U[ ] -.- Q[コンテンツを改善する] --- N[コンテンツを作成する] N --- O[ドキュメントを翻訳する] O --- P[k8sリリースサイクルの
ドキュメントを管理する] end subgraph second[レビュー] direction TB T[ ] -.- D[kubernetes/website
リポジトリを確認する] --- E[静的サイトジェネレーター
Hugoを確認する] E --- F[基本的なGitHubの
コマンドを理解する] F --- G[オープンした
プルリクエストを確認し
レビュープロセスを見直す] end subgraph first[サインアップ] direction TB S[ ] -.- B[CNCFの
コントリビューターライセンス
サインに署名する] --- C[Slackチャンネル
sig-docs に
参加する] C --- V[kubernetes-sig-docsの
メーリングリストに
参加する] V --- M[毎週開催している
sig-docs callsや
slack callsに
参加する] end A([fa:fa-user 新たな
コントリビューター]) --> first A --> second A --> third A --> H[質問をする!!!] classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px; classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000 class A,B,C,D,E,F,G,H,M,Q,N,O,P,V grey class S,T,U spacewhite class first,second,third white
図1. 新たなコントリビューターのためのスタートガイド。

図1は新たなコントリビューターのためのロードマップを概説しています。サインアップやレビューのステップのいくつか、またはその全てに従えばよいです。これで、プルリクエストのオープンの下にリストされているいくつかの貢献目標を達成するためのプルリクエストを開く準備が整いました。また、質問はいつでも歓迎です！

一部のタスクでは、Kubernetes organizationで、より多くの信頼とアクセス権限が必要です。 役割と権限についての詳細は、SIG Docsへの参加を参照してください。

はじめての貢献

あらかじめいくつかのステップを見直すことで、最初の貢献に備えることができます。図2はそれらのステップの概説で、詳細は次のとおりです。

flowchart LR subgraph second[はじめての貢献] direction TB S[ ] -.- G[K8sメンバーからの
PRレビューを受ける] --> A[最初のPRを作成するための
良いissueを
kubernetes/websiteから探す] --> B[PRをオープンする!!] end subgraph first[推奨される準備] direction TB T[ ] -.- D[コントリビューターの概要を読む] -->E[K8sのコンテンツと
スタイルガイドを読む] E --> F[Hugoのページコンテンツタイプと
ショートコードについて学ぶ] end first ----> second classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px; classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000 class A,B,D,E,F,G grey class S,T spacewhite class first,second white
図2. はじめての貢献のための準備。

貢献時の支援の受け方

はじめて貢献を行うのは大変なことかもしれません。新規コントリビューターのためのアンバサダーは、最初の数回の貢献を行う手助けをしてくれます。Kubernetes Slackで、特に#sig-docsチャンネルを用いて連絡を取ることができます。また毎月第一火曜日に行われる新規コントリビューターのための歓迎会もあります。ここで新規コントリビューターのアンバサダーと交流し、質問に答えてもらうことができます。

訳注: 日本語ローカライゼーションに関しては、Slackのkubernetes-docs-jaチャンネルを利用してください。

次のステップ

SIG Docsに参加する

SIG DocsはKubernetesのドキュメントとウェブサイトを公開・管理するコントリビューターのグループです。SIG Docsに参加することはKubernetesコントリビューター(機能開発でもそれ以外でも)にとってKubernetesプロジェクトに大きな影響を与える素晴らしい方法の一つです。

SIG Docsは複数の方法でコミュニケーションをとっています。

その他の貢献方法

2 - コンテンツの改善を提案する

Kubernetesのドキュメントに何か問題を見つけたり、新しいコンテンツに関してアイデアを思い付いたときは、issueを作ってください。必要なものは、GitHubアカウントとウェブブラウザーだけです。

Kubernetesのドキュメント上の新しい作業は、ほとんどの場合、GitHubのissueから始まります。Kubernetesのコントリビューターは、必要に応じてレビュー、分類、タグ付けを行います。次に、あなたやKubernetesコミュニティの他のメンバーが、そのissueを解決するための変更を加えるpull requestを開きます。

issueを作る

既存のコンテンツに対して改善を提案したい場合や、間違いを発見した場合は、issueを作ってください。

  1. ページの右側のサイドバーにあるドキュメントのissueを作成ボタンをクリックします。GitHubのissueページにリダイレクトし、一部のヘッダーが自動的に挿入されます。
  2. 問題や改善の提案について書きます。できる限り多くの詳細情報を提供するようにしてください。
  3. Submit new issueボタンをクリックします。

送信後、定期的にissueを確認するか、GitHubの通知を設定してください。レビュアや他のコミュニティメンバーが、issueに対して作業を行うために、あなたに何か質問をするかもしれません。

新しいコンテンツの提案

新しいコンテンツに関するアイデアがあるものの、どの場所に追加すればわからないときでも、issueを作ることができます。次のいずれかを選択して行ってください。

よいissueを作るには

issueを作るときは、以下のことを心に留めてください。

3 - 新しいコンテンツの貢献

このセクションでは、新しいコンテンツの貢献を行う前に知っておくべき情報を説明します。

flowchart LR subgraph second[始める前に] direction TB S[ ] -.- A[CNCF CLAに署名] --> B[Gitブランチを選択] B --> C[言語ごとにPR] C --> F[コントリビューターのための
ツールをチェックアウト] end subgraph first[貢献の基本] direction TB T[ ] -.- D[ドキュメントをMarkdownで書き
Hugoでサイトをビルド] --- E[GitHubにあるソース] E --- G[複数の言語のドキュメントを含む
'/content/../docs'フォルダー] G --- H[Hugoのpage content
typesやshortcodeをレビュー] end first ----> second classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px; classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000 class A,B,C,D,E,F,G,H grey class S,T spacewhite class first,second white

図 - 新しいコンテンツ提供の貢献方法

上記の図は新しいコンテンツを申請する前に知っておくべき情報を示しています。 詳細については以下で説明します。

貢献の基本

始める前に

CNCF CLAに署名する

すべてのKubernetesのコントリビューターは、コントリビューターガイドを読み、Contributor License Agreement(コントリビューターライセンス契約、CLA)への署名を必ず行わなければなりません。

CLAへの署名が完了していないコントリビューターからのpull requestは、自動化されたテストで失敗します。名前とメールアドレスはgit configコマンドで表示されるものに一致し、gitの名前とメールアドレスはCNCF CLAで使われたものに一致しなければなりません。

どのGitブランチを使用するかを選ぶ

pull requestをオープンするときは、どのブランチをベースにして作業するかをあらかじめ知っておく必要があります。

シナリオ ブランチ
現在のリリースに対する既存または新しい英語のコンテンツ main
機能変更のリリースに対するコンテンツ 機能変更が含まれるメジャーおよびマイナーバージョンに対応する、dev-<version>というパターンのブランチを使います。たとえば、機能変更がv1.36に含まれる場合、ドキュメントの変更はdev-1.36ブランチに追加します。
他の言語内のコンテンツ(翻訳) 各翻訳対象の言語のルールに従います。詳しい情報は、翻訳のブランチ戦略を読んでください。

それでも選ぶべきブランチがわからないときは、Slack上の#sig-docsチャンネルで質問してください。

備考:

すでにpull requestを作成していて、ベースブランチが間違っていたことに気づいた場合は、作成者であるあなただけがベースブランチを変更できます。

言語ごとのPR

pull requestはPRごとに1つの言語に限定してください。複数の言語に同一の変更を行う必要がある場合は、言語ごとに別々のPRを作成してください。

コントリビューターのためのツール

kubernetes/websiteリポジトリ内のdoc contributors toolsディレクトリには、コントリビューターとしての旅を楽にしてくれるツールがあります。

4 - 変更のレビュー

このセクションでは、コンテンツのレビュー方法について説明します。

4.1 - Pull Requestのレビュー

ドキュメントのPull Requestは誰でもレビューすることができます。Kubernetesのwebsiteリポジトリでpull requestsのセクションに移動し、open状態のPull Requestを確認してください。

ドキュメントのPull Requestのレビューは、Kubernetesコミュニティに自分を知ってもらうためのよい方法の1つです。コードベースについて学んだり、他のコントリビューターとの信頼関係を築く助けともなるはずです。

レビューを行う前には、以下のことを理解しておくとよいでしょう。

はじめる前に

レビューを始める前に、以下のことを心に留めてください。

レビューのプロセス

一般に、コンテンツや文体に対するPull Requestは、英語でレビューを行います。図1は、レビュープロセスについて手順の概要を示しています。 各ステップの詳細は次のとおりです。

(訳注:SIG Docs jaでは、日本語でも対応しています。日本語の翻訳に対するレビューは、日本語でも構いません。ただし、Pull Requestの作成者や他のコントリビューターが必ずしも日本語を理解できるとは限りませんので、注意して発言してください。)

flowchart LR subgraph fourth[レビューの開始] direction TB S[ ] -.- M[コメントを追加] --> N[変更の確認] N --> O[Commentを選択] end subgraph third[PRの選択] direction TB T[ ] -.- J[説明とコメントを読む]--> K[Netlifyプレビューで
変更点を表示] end A[オープン状態の
PR一覧を確認]--> B[オープン状態のPRを
ラベルで絞り込む] B --> third --> fourth classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px; classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000 class A,B,J,K,M,N,O grey class S,T spacewhite class third,fourth white

図1. レビュープロセスの手順

  1. https://github.com/kubernetes/website/pullsに移動します。Kubernetesのウェブサイトとドキュメントに対するopen状態のPull Request一覧が表示されます。

  2. open状態のPRに、以下に示すラベルを1つ以上使って絞り込みます。

    さらに、PRがwork in progressとしてマークされていないことも確認してください。work in progressラベルの付いたPRは、まだレビューの準備ができていない状態です。

  3. レビューするPRを選んだら、以下のことを行い、変更点について理解します。

  4. Files changedタブに移動してレビューを始めます。

    1. コメントしたい場合は行の横の+マークをクリックします。

    2. その行に関するコメントを書き、Add single comment(1つのコメントだけを残したい場合)またはStart a review(複数のコメントを行いたい場合)のいずれかをクリックします。

    3. コメントをすべて書いたら、ページ上部のReview changesをクリックします。ここでは、レビューの要約を追加できます(コントリビューターにポジティブなコメントも書きましょう！)。常に「Comment」を使用してください。

      • レビューの終了時、「Request changes」ボタンをクリックしないでください。さらに変更される前にマージされるのをブロックしたい場合、「/hold」コメントを残すことができます。Holdを設定する理由を説明し、必要に応じて、自分や他のレビューアがHoldを解除できる条件を指定してください。
      • レビューの終了時、「Approve」ボタンをクリックしないでください。大抵の場合、「/approve」コメントを残すことが推奨されます。

レビューのチェックリスト

レビューするときは、最初に以下の点を確認してみてください。

言語と文法

コンテンツ

ウェブサイト

その他

レビュアーが誤字や不適切な空白など、PRの本質でない小さな問題を発見した場合は、コメントの先頭にnit:を付けてください。これにより、作成者はこのフィードバックが重要でないことを知ることができます。

Pull Requestの承認を検討する際、残りのすべてのフィードバックがnitとしてマークされていれば、残っていたとしてもPRをマージできます。その場合、残っているnitに関するIssueをオープンすると役立つことがよくあります。その新しいIssueをGood First Issueとしてマークするための条件を満たすことができるかどうか検討してください。それができたら、これらは良い情報源になります。

4.2 - approverとreviewer向けのレビュー

SIG DocsのReviewer(レビュアー)とApprover(承認者)は、変更をレビューする時にいくつか追加の作業を行います。

毎週、docsのメンバーの特定のapproverのボランティアは、pull requestのトリアージとレビューを担当します。この担当者は、その週の「PR Wrangler(PRの世話人)」と呼ばれます。詳しい情報は、PR Wrangler schedulerを参照してください。PR Wranglerになるには、週次のSIG Docsミーティングに参加し、ボランティアをします。もしその週にスケジュールされていなくても、活発なレビューが行われていないpull request(PR)をレビューすることは問題ありません。

このローテーションに加えて、変更されたファイルのオーナーに基づいて、botがPRにreviewerとapproverを割り当てます。

PRをレビューする

KubernetesのドキュメントはKubernetesコードレビュープロセスに従います。

pull requestのレビューに書かれているすべてのことが適用されますが、ReviewerとApproverはそれに加えて次のことも行います。

他の作者のPRにコミットを追加する

PRにコメントを残すのは助けになりますが、まれに他の作者のPRに代わりにコミットを追加する必要がある場合があります。

あなたが明示的に作者から頼まれたり、長い間放置されたPRを蘇らせるような場合でない限り、他の作者のPRを「乗っ取る」ようなことはしないでください。短期的に見ればそのほうが短時間で終わるかもしれませんが、そのようなことをするとその人が貢献するチャンスを奪ってしまうことになります。

あなたが取る方法は、編集する必要のあるファイルがすでにPRのスコープに入っているか、あるいはPRがまだ触れていないファイルであるかによって変わります。

以下のいずれかが当てはまる場合、他の作者のPRにあなたがコミットを追加することはできません。

レビュー向けのProwコマンド

Prowは、pull request(PR)に対してジョブを実行するKubernetesベースのCI/CDシステムです。Prowは、Kubernetes organization全体でチャットボットスタイルのコマンドを利用してGitHub actionsを扱えるようにします。たとえば、ラベルの追加と削除、issueのクローズ、approverの割り当てなどが行なえます。Prowコマンドは、GitHubのコメントに/<command-name>という形式で入力します。

reviewerとapproverが最もよく使うprowコマンドには、以下のようなものがあります。

Prow commands for reviewing
Prowコマンド Roleの制限 説明
/lgtm Organizationメンバー PRのレビューが完了し、変更に納得したことを知らせる。
/approve Approver PRをマージすることを承認する。
/assign 誰でも PRのレビューまたは承認するひとを割り当てる。
/close Organizationメンバー issueまたはPRをクローズする。
/hold 誰でも do-not-merge/holdラベルを追加して、自動的にマージできないPRであることを示す。
/hold cancel 誰でも do-not-merge/holdラベルを削除する。

PRで利用できるすべてのコマンドを確認するには、Prowコマンドリファレンスを参照してください。

issueのトリアージとカテゴリー分類

一般に、SIG DocsはKubernetes issue triageのプロセスに従い、同じラベルを使用しています。

このGitHub issueのフィルターは、トリアージが必要な可能性があるissueを表示します。

issueをトリアージする

  1. issueを検証する

  2. 優先度(priority)ラベルを追加する(issueトリアージガイドラインは、priorityラベルについて詳しく定義しています。)

issueのラベル
ラベル 説明
priority/critical-urgent 今すぐに作業する。
priority/important-soon 3ヶ月以内に取り組む。
priority/important-longterm 6ヶ月以内に取り組む。
priority/backlog 無期限に延期可能。リソースに余裕がある時に取り組む。
priority/awaiting-more-evidence よいissueの可能性があるissueを見失わないようにするためのプレースホルダー。
helpまたはgood first issue KubernetesまたはSIG Docsでほとんど経験がない人に適したissue。より詳しい情報は、Help WantedとGood First Issueラベルを読んでください。

あなたの裁量で、issueのオーナーシップを取り、issueに対するPRを提出してください(簡単なissueや、自分がすでに行った作業に関連するissueである場合は特に)。

issueのトリアージについて質問があるときは、Slackの#sig-docsかkubernetes-sig-docs mailing listで質問してください。

issueラベルの追加と削除

ラベルを追加するには、以下のいずれかの形式でコメントします。

ラベルを削除するには、以下のいずれかの形式でコメントします。

いずれの場合でも、ラベルは既存のものでなければなりません。存在しないラベルを追加しようとした場合、コマンドは無視されます。

すべてのラベル一覧は、websiteリポジトリのラベルセクションで確認できます。 SIG Docsですべてのラベルが使われているわけではありません。

issueのライフサイクルに関するラベル

issueは一般にオープン後に短期間でクローズされます。しかし、オープンされたものの非アクティブになるissueもあります。逆に、90日以上オープンのままにしておく必要があるissueもあります。

issueのライブラリに関するラベル
ラベル 説明
lifecycle/stale 90日間活動がない場合、issueは自動的にstaleとラベル付けされます。/remove-lifecycle staleコマンドを使って手動でlifecycleをリバートしない限り、issueは自動的にクローズされます。
lifecycle/frozen このラベルが付けられたissueは、90日間活動がなくてもstaleになりません。priority/important-longtermラベルを付けたissueなど、90日以上オープンにしておく必要があるissueには、このラベルを手動で追加します。

特別な種類のissueに対処する

SIG Docsでは、対処方法をドキュメントに書いても良いくらい頻繁に、以下のような種類のissueに出会います。

重複したissue

1つの問題に対して1つ以上のissueがオープンしている場合、1つのissueに統合します。あなたはどちらのissueをオープンにしておくか(あるいは新しいissueを作成するか)を決断して、すべての関連する情報を移動し、関連するすべてのissueにリンクしなければなりません。最後に、同じ問題について書かれたすべての他のissueにtriage/duplicateラベルを付けて、それらをクローズします。作業対象のissueを1つだけにすることで、混乱を減らし、同じ問題に対して作業が重複することを避けられます。

リンク切れのissueがAPIまたはkubectlのドキュメントにあるものは、問題が完全に理解されるまでは/priority critical-urgentを割り当ててください。その他のすべてのリンク切れに関するissueには、手動で修正が必要であるため、/priority important-longtermを付けます。

ブログに関するissue

Kubernetesブログのエントリは時間が経つと情報が古くなるものだと考えています。そのため、ブログのエントリは1年以内のものだけをメンテナンスします。1年以上前のブログエントリに関するissueは修正せずにクローズします。

PRをクローズするときに送信するメッセージの一部として、記事の更新とメンテナンスへのリンクを含めて案内しても構いません。

関連する正当な理由がある場合には、例外を設けても問題ありません。

サポートリクエストまたはコードのバグレポート

一部のドキュメントのissueは、実際には元になっているコードの問題や、何か(たとえば、チュートリアル)がうまく動かないときにサポートをリクエストするものです。ドキュメントに関係のない問題は、kind/supportラベルを付け、サポートチャンネル(SlackやStack Overflowなど)へ報告者を導くコメントをして、もし関連があれば機能のバグに対するissueを報告するリポジトリ(kubernetes/kubernetesは始めるのに最適な場所です)を教えて、クローズします。

サポートリクエストに対する返答の例を示します。(リクエストを行うときは英語で行うことが想定されるため、英文とその日本語訳を記載しています)

This issue sounds more like a request for support and less
like an issue specifically for docs. I encourage you to bring
your question to the `#kubernetes-users` channel in
[Kubernetes slack](https://slack.k8s.io/). You can also search
resources like
[Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes)
for answers to similar questions.

You can also open issues for Kubernetes functionality in
https://github.com/kubernetes/kubernetes.

If this is a documentation issue, please re-open this issue.

このissueは特定のドキュメントに関するissueではなく、サポートリクエストのようです。
Kubernetesに関する質問については、[Kubernetes slack](https://slack.k8s.io/)の
`#kubernetes-users`チャンネルに投稿することをおすすめします。同様の質問に対する回答を
[Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes)などの
リソースで検索することもできます。

Kubernetesの機能に関するissueについては、https://github.com/kubernetes/kubernetes
でissueを作成できます。

もしこれがドキュメントに関するissueの場合、このissueを再びオープンしてください。

コードのバグに対する返答の例を示します。

This sounds more like an issue with the code than an issue with
the documentation. Please open an issue at
https://github.com/kubernetes/kubernetes/issues.

If this is a documentation issue, please re-open this issue.

こちらのissueは、ドキュメントではなくコードに関係するissueのようです。
https://github.com/kubernetes/kubernetes/issues でissueを作成してください。

もしこれがドキュメントに関するissueの場合、このissueを再びオープンしてください。

スカッシュを行う

approverとして、pull request(PR)をレビューするときに、次のような場合があります。

コントリビューターにスカッシュを行うように伝える: 新しいコントリビューターは、pull request(PR)でコミットをスカッシュする必要があることを知らない場合があります。このような場合は、スカッシュするように案内し、役立つ情報へのリンクを表示し、必要であればサポートを手配できることを伝えます。以下は役立つリンクの例です。

コントリビューターの代わりにコミットをスカッシュする: コントリビューターがコミットのスカッシュに困っている場合やPRをマージするまでに時間的に制約がある場合は、代わりにスカッシュを行うことができます。

コントリビューターにスカッシュを避けるように伝える

決してスカッシュしないようにする

5 - Kubernetesのドキュメントを翻訳する

このページでは、Kubernetesドキュメントにおける日本語翻訳の方針について説明します。

ドキュメントを日本語に翻訳するまでの流れ

翻訳を行うための基本的な流れについて説明します。不明点がある場合はKubernetes公式Slackの#kubernetes-docs-jaチャンネルにてお気軽にご質問ください。

前提知識

翻訳作業は全てGitHubのIssueによって管理されています。翻訳作業を行いたい場合は、Issueの一覧をまず最初にご確認ください。

また、Kubernetes傘下のリポジトリではCLAと呼ばれる同意書に署名しないと、Pull Requestをマージすることができません。詳しくは英語のドキュメントや、Qiitaに有志の方が書いてくださった日本語のまとめをご覧ください。

翻訳を始めるまで

翻訳を希望するページのIssueが存在しない場合

  1. こちらのサンプルに従う形でIssueを作成する
  2. 自分自身を翻訳作業に割り当てたい場合は、Issueのメッセージまたはコメントに/assignと書く
  3. 新規ページを翻訳する場合のステップに進む

不明点がある場合はKubernetes公式Slackの#kubernetes-docs-jaチャンネルにてお気軽にご質問ください。

翻訳を希望するページのIssueが存在する場合

  1. 自分自身を翻訳作業に割り当てるために、Issueのコメントに/assignと書く
  2. 新規ページを翻訳する場合のステップに進む

Pull Requestを送るまで

新規ページを翻訳する場合の手順

  1. kubernetes/websiteリポジトリをフォークする
  2. mainから任意の名前でブランチを作成する
  3. content/enのディレクトリから必要なファイルをcontent/jaにコピーし、翻訳する
  4. mainブランチに向けてPull Requestを作成する

既存のページの誤字脱字や古い記述を修正する場合の手順

  1. kubernetes/websiteリポジトリをフォークする
  2. mainから任意の名前でブランチを作成する
  3. content/jaのディレクトリから必要なファイルを編集する
  4. mainブランチに向けてPull Requestを作成する

翻訳スタイルガイド

基本方針

用語の表記

Kubernetesのリソース名や技術用語などは、原則としてそのままの表記を使用します。 例えば、PodやService、Deploymentなどは翻訳せずにそのまま表記してください。

ただし、ノード(Node)に関してはKubernetesとしてのNodeリソース(例: kind: Nodeやkubectl get nodes、Nodeコントローラーなど)を指していないのであれば、「ノード」と表記してください。

またこれらの単語は、複数形ではなく単数形を用います。 例えば、原文に"pods"と表記されている場合でも、日本語訳では"Pod"と表記してください。

特定の用語がKubernetes固有の技術用語であるかどうかについて迷った時は、次の判断フローを参考にしてください。

  1. APIリソースの一覧または標準化用語集に対象の用語が掲載されている場合は、掲載されている用語で表記します。
  2. その他のKubernetesに関連する用語については、固有名詞と判断できるものは原則アルファベットで表記します。
  3. 新しく用語を日本語として翻訳する際は、レビュアーやローカライゼーションチームに意見を聞いてください。

ローカライゼーションチームは、あなたのコメントを歓迎します！

頻出表記(日本語)

よくある表記 あるべき形
〜ので、〜から、〜だから 〜のため 、〜ため
(あいうえお。) (あいうえお)。
〇,〇,〇 〇、〇、〇(※列挙はすべて読点で統一)

長音の有無

カタカナ語に長音を付与するかどうかは、以下の原則に従ってください。

ただし、「コンテナ」は例外的に長音を付与しないこととします。

この原則を作成するにあたって、mozilla-japan/translation Editorial Guideline#カタカナ語の表記を参考にしました。

その他の表記

その他の表記については、以下の表を参考にしてください。

英語 日本語
interface インターフェース
proxy プロキシ
quota クォータ
stacked 積層

cron jobの訳し方に関して

混同を避けるため、cron jobはcronジョブと訳し、CronJobはリソース名としてそのまま表記します。 cron「の」ジョブは、「の」が続く事による解釈の難から基本的にはつけないものとします。

その他基本方針など

アップストリームのコントリビューター

SIG Docsでは、英語のソースに対するアップストリームへのコントリビュートや誤りの訂正を歓迎しています。

6 - SIG Docsへの参加

SIG Docsは、Kubernetesプロジェクト内の special interest groupsの1つであり、 Kubernetes全体のドキュメントの作成、更新、および保守に重点を置いています。 SIGの詳細については、SIG DocsのGithubリポジトリを参照してください。

SIG Docsは、すべての寄稿者からのコンテンツとレビューを歓迎します。 誰でもPull Request(PR)を開くことができ、コンテンツに関するissueを提出したり、進行中のPull Requestにコメントしたりできます。

あなたは、memberや、 reviewer、 approverになることもできます。 これらの役割にはより多くのアクセスが必要であり、変更を承認およびコミットするための特定の責任が伴います。 Kubernetesコミュニティ内でメンバーシップがどのように機能するかについての詳細は、 community-membership をご覧ください。

このドキュメントの残りの部分では、kubernetesの中で最も広く公開されている Kubernetesのウェブサイトとドキュメントの管理を担当しているSIG Docsの中で、これらの役割がどのように機能するのかを概説します。

SIG Docs chairperson

SIG Docsを含む各SIGは、議長として機能する1人以上のSIGメンバーを選択します。 これらは、SIGDocsとKubernetes organizationの他の部分との連絡先です。 それらには、Kubernetesプロジェクト全体の構造と、SIG Docsがその中でどのように機能するかについての広範な知識が必要です。 現在のchairpersonのリストについては、 Leadership を参照してください。

SIG Docs teamsと自動化

SIG Docsの自動化は、GitHub teamsとOWNERSファイルの2つの異なるメカニズムに依存しています。

GitHub teams

GitHubには、二つのSIG Docs teams カテゴリがあります:

それぞれをGitHubコメントの@nameで参照して、そのグループの全員とコミュニケーションできます。

ProwチームとGitHub teamsが完全に一致せずに重複する場合があります。 問題の割り当て、Pull Request、およびPR承認のサポートのために、自動化ではOWNERSファイルからの情報を使用します。

OWNERSファイルとfront-matter

Kubernetesプロジェクトは、GitHubのissueとPull Requestに関連する自動化のためにprowと呼ばれる自動化ツールを使用します。 Kubernetes Webサイトリポジトリ は、2つのprowプラグインを使用します：

これらの2つのプラグインはkubernetes.websiteのGithubリポジトリのトップレベルにある OWNERSファイルと、 OWNERS_ALIASESファイルを使用して、 リポジトリ内でのprowの動作を制御します。

OWNERSファイルには、SIG Docsのレビュー担当者および承認者であるユーザーのリストが含まれています。 OWNERSファイルはサブディレクトリに存在することもでき、そのサブディレクトリとその子孫のファイルのレビュー担当者または承認者として機能できるユーザーを上書きできます。 一般的なOWNERSファイルの詳細については、 OWNERSを参照してください。

さらに、個々のMarkdownファイルは、個々のGitHubユーザー名またはGitHubグループを一覧表示することにより、そのfront-matterでレビュー担当者と承認者を一覧表示できます。

OWNERSファイルとMarkdownファイルのfront-matterの組み合わせにより、PRの技術的および編集上のレビューを誰に依頼するかについてPRの所有者が自動化システムから得るアドバイスが決まります。

マージの仕組み

Pull Requestがコンテンツの公開に使用されるブランチにマージされると、そのコンテンツは https://kubernetes.io に公開されます。 公開されたコンテンツの品質を高くするために、Pull RequestのマージはSIG Docsの承認者に限定しています。仕組みは次のとおりです。

次の項目

Kubernetesドキュメントへの貢献の詳細については、以下を参照してください：

6.1 - ロールと責任

誰もがKubernetesに貢献することができます。 SIG Docs へのコントリビューションが増えると、コミュニティ内で異なるレベルのメンバーシップに申請することができます。 これらの役割により、コミュニティ内でより多くの責任を担うことができます。 各役割にはより多くの時間とコミットメントが必要です。 役割は以下の通りです:

Anyone

GitHubのアカウントを持っている人なら誰もがKubernetesに貢献することができます。 SIG Docs はすべての新たなコントリビューターを歓迎します。

誰もが以下のことをできます:

CLA に署名した後は、誰もが以下のことをできます:

詳細については、新しいコンテンツの貢献を参照してください。

Member

Memberは、kubernetes/websiteに複数のPull Requestを作成した人です。 MemberはKubernetes GitHub organizationの一員です。

Memberは以下のことをできます:

Memberになる

少なくとも5つの実質的なPull Requestを作成し、その他の要件を満たした後に以下のようにしてMemberになることができます:

  1. 2人のReviewerまたはApproverにあなたのメンバーシップをスポンサーしてもらいます。

    Slackの#sig-docsチャンネルやSIG Docsのメーリングリストでスポンサーを依頼してください。

    備考:

    個別のSIG Docsメンバーに直接メールやSlackのダイレクトメッセージを送らないでください。 また申請する前にスポンサーを依頼する必要があります。

  2. kubernetes/orgリポジトリにIssueを作成します。Organization Membership Requestのissueテンプレートを使用してください。

  3. スポンサーにGitHub Issueのことを知らせます。以下の方法があります:

  4. メールアカウントでKubernetes GitHub organizationの招待を受け入れます。

    備考:

    GitHubはアカウントのデフォルトメールアドレスに招待を送信します。

Reviewer

ReviewerはオープンなPull Requestのレビューを担当します。 Memberのフィードバックとは異なり、PRを作成した人はReviewerのフィードバックに対応する必要があります。 Reviewerは@kubernetes/sig-docs-{language}-reviews GitHubチームのメンバーです。

Reviewerは以下のことをできます:

SIG DocsのReviewer、あるいは特定の領域に関するドキュメントのReviewerになることができます。

Pull RequestへのReviewerの割り当て

自動化により、すべてのPull RequestにReviewerが割り当てられます。 特定の人物にレビューを依頼するには、/assign [@_github_handle]とコメントします。

割り当てられたReviewerがPRにコメントしていない場合、他のReviewerが代わりにレビューできます。 また、必要に応じて技術的なReviewerを割り当てることもできます。

/lgtmの使用

LGTMは"Looks good to me"の略で、Pull Requestが技術的に正確でマージの準備が整っていることを示します。 すべてのPRには、マージするためにReviewerからの/lgtmコメントとApproverからの/approveコメントが必要です。

Reviewerからの/lgtmコメントは拘束力があり、自動化によりlgtmラベルが追加されます。

Reviewerになる

要件を満たすと、SIG DocsのReviewerになることができます。他のSIGのReviewerは、SIG DocsでのReviewerステータスを別途申請する必要があります。

申請方法は以下の通りです:

  1. kubernetes/websiteリポジトリのOWNERS_ALIASESファイルのセクションに、GitHubユーザー名を追加するPull Requestを開きます。

    備考:

    どこに追加すればよいかわからない場合は、sig-docs-en-reviewsに追加してください。

    訳注: sig-docs-en-reviewsは英語版のReviewerチームです。日本語ローカライゼーションのReviewerチームに参加する場合は、sig-docs-ja-reviewsに追加してください。

  2. PRを1人以上のSIG Docs Approverに割り当てます(ユーザー名はsig-docs-{language}-ownersに記載されています)。

承認されると、SIG Docsのリードが適切なGitHubチームに追加します。 追加されると、k8s-ci-robotが新しいPull RequestのReviewerとしてあなたを割り当て、提案します。

Approver

ApproverはPull Requestをレビューし、マージするために承認します。 Approverは@kubernetes/sig-docs-{language}-owners GitHubチームのメンバーです。

Approverは以下のことをできます:

PRに既に/lgtmが付いている場合、またはApprover自身が/lgtmコメントを付けた場合、PRは自動的にマージされます。 SIG DocsのApproverは、追加の技術的なレビューが不要な変更にのみ/lgtmを付けるべきです。

Pull Requestの承認

ApproverとSIG DocsのリードだけがPull Requestをwebsiteリポジトリにマージすることができます。 これには一定の責任が伴います。

Approverになる

要件を満たすと、SIG DocsのApproverになることができます。 他のSIGのApproverは、SIG DocsでのApproverステータスを別途申請する必要があります。

申請方法は以下の通りです:

  1. kubernetes/websiteリポジトリのOWNERS_ALIASESファイルのセクションに、自分自身を追加するPull Requestを開きます。

    備考:

    どこに追加すればよいかわからない場合は、`sig-docs-en-owners`に追加してください。

訳注: `sig-docs-en-owners`は英語版のApproverチームです。
日本語ローカライゼーションのApproverチームに参加する場合は、`sig-docs-ja-owners`に追加してください。

  2. PRを1人以上の現在のSIG Docs Approversに割り当てます。

承認されると、SIG Docsのリードが適切なGitHubチームに追加します。 追加されると、k8s-ci-robotが新しいPull RequestのReviewerとしてあなたを割り当て、提案します。

次の項目

7 - ドキュメントスタイルの概要

このセクション内のトピックでは、文章のスタイル、コンテンツの形式や構成、特にKubernetesのドキュメント特有のHugoカスタマイズの使用方法に関するガイダンスを提供します。

7.1 - ドキュメントコンテンツガイド

このページでは、Kubernetesのドキュメント上のコンテンツのガイドラインを説明します。

許可されるコンテンツに関して疑問がある場合は、Kubernetes Slackの#sig-docsチャンネルに参加して質問してください！

Kubernetes Slackには、https://slack.k8s.io/ から参加登録ができます。

Kubernetesドキュメントの新しいコンテンツの作成に関する情報については、スタイルガイドに従ってください。

概要

ドキュメントを含むKubernetesのウェブサイトのソースは、kubernetes/websiteリポジトリに置かれています。

Kubernetesの主要なドキュメントはkubernetes/website/content/<language_code>/docsフォルダに置かれており、これらはKubernetesプロジェクトを対象としています。

許可されるコンテンツ

Kubernetesのドキュメントにサードパーティーのコンテンツを掲載することが許されるのは、次の場合のみです。

サードパーティーのコンテンツ

Kubernetesのドキュメントには、Kubernetesプロジェクト(kubernetesおよびkubernetes-sigs GitHub organizationsに存在するプロジェクト)の適用例が含まれています。

Kubernetesプロジェクト内のアクティブなコンテンツへのリンクは常に許可されます。

Kubernetesを機能させるためには、一部サードパーティーのコンテンツが必要です。たとえば、コンテナランタイム(containerd、CRI-O、Docker)、ネットワークポリシー(CNI plugin)、Ingressコントローラー、ロギングなどです。

ドキュメント内で、Kubernetesプロジェクト外のサードパーティーのオープンソースソフトウェア(OSS)にリンクすることができるのは、Kubernetesを機能させるために必要な場合のみです。

情報源が重複するコンテンツ

可能な限り、Kubernetesのドキュメントは正規の情報源にリンクするようにし、情報源が重複してしまうようなホスティングは行いません。

情報源が重複したコンテンツは、メンテナンスするために2倍の労力(あるいはそれ以上！)が必要になり、より早く情報が古くなってしまいます。

備考:

あなたがKubernetesのプロジェクトのメンテナーであり、ドキュメントのホスティングに関して手助けが必要なときは、Kubernetes Slackの#sig-docsで教えてください。

その他の情報

許可されるコンテンツに関して疑問がある場合は、Kubernetes Slackの#sig-docsチャンネルに参加して質問してください！

次の項目

7.2 - コンテンツの構造化

このサイトではHugoを使用しています。Hugoでは、コンテンツの構造化がコアコンセプトとなっています。

備考:

Hugoのヒント: コンテンツの編集を始めるときは、hugo server --navigateToChangedコマンドを使用してHugoを実行してください。

ページの一覧

ページの順序

ドキュメントのサイドメニューやページブラウザーなどでは、Hugoのデフォルトのソート順序を使用して一覧を作成しています。デフォルトでは、weight(1から開始)、日付(最新のものが1番目)、最後にリンクのタイトルの順でソートされます。

そのため、特定のページやセッションを上に移動したい場合には、ページのフロントマター内のweightを設定します。

title: My Page
weight: 10

備考:

ページのweightについては、1、2、3…などの値を使用せず、10、20、30…のように一定の間隔を空けた方が賢明です。こうすることで、後で別のページを間に挿入できるようになります。さらに、同じディレクトリ(セクション)内の各ページのweightは、重複しないようにする必要があります。これにより、特にローカライズされたコンテンツでは、コンテンツが常に正しく整列されるようになります。

ドキュメントのメインメニュー

ドキュメントのメインメニューは、docs/以下に置かれたセクションのコンテンツファイル_index.mdのフロントマター内にmain_menuフラグが設定されたものから生成されます。

main_menu: true

リンクのタイトルは、ページのlinkTitleから取得されることに注意してください。そのため、ページのタイトルとは異なるリンクテキストにしたい場合、コンテンツファイル内の値を以下のように設定します。

main_menu: true
title: ページタイトル
linkTitle: リンク内で使われるタイトル

備考:

上記の設定は言語ごとに行う必要があります。メニュー上にセクションが表示されないときは、Hugoからセクションとして認識されていないためである可能性が高いです。セクションフォルダー内に_index.mdコンテンツファイルを作成してください。

ドキュメントのサイドメニュー

ドキュメントのサイドバーメニューは、docs/以下の現在のセクションツリーから生成されます。

セクションと、そのセクション内のページがすべて表示されます。

特定のセクションやページをリストに表示したくない場合、フロントマター内のtoc_hideフラグをtrueに設定してください。

toc_hide: true

コンテンツが存在するセクションに移動すると、特定のセクションまたはページ(例:index.md)が表示されます。それ以外の場合、そのセクションの最初のページが表示されます。

ドキュメントのブラウザー

ドキュメントのホームページのページブラウザーは、docsセクション直下のすべてのセクションとページを使用して生成されています。

特定のセクションやページを表示したくない場合、フロントマターのtoc_hideフラグをtrueに設定してください。

toc_hide: true

メインメニュー

右上のメニュー(およびフッター)にあるサイトリンクは、page-lookupの機能を使用して実装されています。これにより、ページが実際に存在することを保証しています。そのため、たとえばcase-studiesのセクションが特定の言語のサイトに存在しない場合、メニューにはケーススタディのリンクが表示されません。

Page Bundle

スタンドアローンのコンテンツページ(Markdownファイル)に加えて、Hugoでは、Page Bundlesがサポートされています。

Page Bundleの1つの例は、カスタムのHugo Shortcodeです。これは、leaf bundleであると見做されます。ディレクトリ内のすべてのファイルは、index.mdを含めてバンドルの一部となります。これには、ページからの相対リンク、処理可能な画像なども含まれます。

en/docs/home/contribute/includes
├── example1.md
├── example2.md
├── index.md
└── podtemplate.json

もう1つのPage Bundleがよく使われる例は、includesバンドルです。フロントマターにheadless: trueを設定すると、自分自身のURLを持たなくなり、他のページ内でのみ使用されるようになります。

en/includes
├── default-storage-class-prereqs.md
├── index.md
├── partner-script.js
├── partner-style.css
├── task-tutorial-prereqs.md
├── user-guide-content-moved.md
└── user-guide-migration-notice.md

バンドル内のファイルに関して、いくつか重要な注意点があります。

スタイル

このサイトのスタイルシートのSASSのソースは、assets/sassに置かれていて、Hugoによって自動的にビルドされます。

次の項目

7.3 - カスタムHugoショートコード

このページではKubernetesのマークダウンドキュメント内で使用できるHugoショートコードについて説明します。

ショートコードについての詳細はHugoのドキュメントを読んでください。

機能の状態

このサイトのマークダウンページ(.mdファイル)内では、説明されている機能のバージョンや状態を表示するためにショートコードを使用することができます。

機能の状態のデモ

最新のKubernetesバージョンで機能をstableとして表示するためのデモスニペットを次に示します。

{{< feature-state state="stable" >}}

これは次の様に表示されます:

FEATURE STATE: Kubernetes v1.35 [stable]

stateの値として妥当な値は次のいずれかです:

機能の状態コード

表示されるKubernetesのバージョンのデフォルトはそのページのデフォルトまたはサイトのデフォルトです。 for_k8s_versionパラメーターを渡すことにより、機能の状態バージョンを変更することができます。 例えば:

{{< feature-state for_k8s_version="v1.10" state="beta" >}}

これは次の様に表示されます:

FEATURE STATE: Kubernetes v1.10 [beta]

用語集

用語集に関連するショートコードとして、glossary_tooltipとglossary_definitionの二つがあります。

コンテンツを自動的に更新し、用語集へのリンクを付与する挿入を使用して、用語を参照することができます。 用語がマウスオーバーされると、用語集の内容がツールチップとして表示されます。 また、用語はリンクとして表示されます。

ツールチップの挿入と同様に、用語集の定義も再利用することができます。

用語集の用語データはglossaryディレクトリに、それぞれの用語のファイルとして保存されています。

用語集のデモ

例えば、マークダウン内でツールチップ付きのclusterを表示するには、次の挿入を使用します:

{{< glossary_tooltip text="cluster" term_id="cluster" >}}

用語集の定義はこのようにします:

{{< glossary_definition prepend="A cluster is" term_id="cluster" length="short" >}}

これは次の様に表示されます:

A cluster is コンテナ化されたアプリケーションを実行する、ノードと呼ばれるワーカーマシンの集合です。すべてのクラスターには少なくとも1つのワーカーノードがあります。

完全な用語定義を挿入することもできます:

{{< glossary_definition term_id="cluster" length="all" >}}

これは次の様に表示されます:

コンテナ化されたアプリケーションを実行する、ノードと呼ばれるワーカーマシンの集合です。すべてのクラスターには少なくとも1つのワーカーノードがあります。

ワーカーノードは、アプリケーションのコンポーネントであるPodをホストします。マスターノードは、クラスター内のワーカーノードとPodを管理します。複数のマスターノードを使用して、クラスターにフェイルオーバーと高可用性を提供します。 ワーカーノードは、アプリケーションワークロードのコンポーネントであるPodをホストします。コントロールプレーンは、クラスター内のワーカーノードとPodを管理します。本番環境では、コントロールプレーンは複数のコンピューターを使用し、クラスターは複数のノードを使用し、耐障害性や高可用性を提供します。

APIリファレンスへのリンク

api-referenceショートコードを使用することで、Kubernetes APIリファレンスへのリンクを作成することができます。 例えば、 Podへの参照方法は次の通りです:

{{< api-reference page="workload-resources/pod-v1" >}}

pageパラメーターの値はAPIリファレンスページのURLの末尾です。

anchorパラメーターを指定することでページ内の特定の場所へリンクすることもできます。 例えば、 PodSpecや environment-variablesへのリンクは次の様に書きます:

{{< api-reference page="workload-resources/pod-v1" anchor="PodSpec" >}}
{{< api-reference page="workload-resources/pod-v1" anchor="environment-variables" >}}

textパラメーターを指定することでリンクテキストを変更することもできます。 例えば、 Environment Variablesへのリンクは次の様に書きます:

{{< api-reference page="workload-resources/pod-v1" anchor="environment-variables" text="Environment Variable" >}}

テーブルキャプション

テーブルキャプションを追加することで、表をスクリーンリーダーにとってよりアクセスしやすいものにする事ができます。 表へキャプションを追加するには、表をtableショートコードで囲い、captionパラメーターにキャプションを指定します。

備考:

テーブルキャプションはスクリーンリーダーからは読むことができますが、標準的なHTMLでは読むことができません。

例えば、次の様に書きます:

{{< table caption="Configuration parameters" >}}
Parameter | Description | Default
:---------|:------------|:-------
`timeout` | The timeout for requests | `30s`
`logLevel` | The log level for log output | `INFO`
{{< /table >}}

これは次の様に表示されます:

Configuration parameters
Parameter Description Default
timeout The timeout for requests 30s
logLevel The log level for log output INFO

この表に対するHTMLを検査すると、次の要素が<table>要素のすぐ次にあるのを見ることができるでしょう:

<caption style="display: none;">Configuration parameters</caption>

タブ

このサイトのマークダウンページ(.mdファイル)内では、あるソリューションに対する複数のフレーバーを表示するためのタブセットを追加することができます。

tabsショートコードはこれらのパラメーターを受けとります:

タブショートコードの例を次に示します。

備考:

tabs定義内のnameはコンテンツページ内でユニークである必要があります。

タブのデモ: コードハイライト

{{< tabs name="tab_with_code" >}}
{{{< tab name="Tab 1" codelang="bash" >}}
echo "これはタブ1です。"
{{< /tab >}}
{{< tab name="Tab 2" codelang="go" >}}
println "これはタブ2です。"
{{< /tab >}}}
{{< /tabs >}}

これは次の様に表示されます:


echo "これはタブ1です。"



println "これはタブ2です。"

タブのデモ: インラインマークダウンとHTML

{{< tabs name="tab_with_md" >}}
{{% tab name="Markdown" %}}
これは**なにがしかのマークダウン**です。
{{< note >}}
ショートコードを含むこともできます。
{{< /note >}}
{{% /tab %}}
{{< tab name="HTML" >}}
<div>
	<h3>プレーンHTML</h3>
	<p>これはなにがしかの<i>プレーン</i>HTMLです。</p>
</div>
{{< /tab >}}
{{< /tabs >}}

これは次の様に表示されます。

これはなにがしかのマークダウンです。

備考:

ショートコードを含むこともできます。

プレーンHTML

これはなにがしかのプレーンHTMLです。

タブのデモ: ファイルの読み込み

{{< tabs name="tab_with_file_include" >}}
{{< tab name="Content File #1" include="example1" />}}
{{< tab name="Content File #2" include="example2" />}}
{{< tab name="JSON File" include="podtemplate" />}}
{{< /tabs >}}

これは次の様に表示されます:

これは挿入leaf bundle内のコンテンツファイルの例です。

備考:

挿入されたコンテンツファイル内でもショートコードを使用することができます。

これは挿入leaf bundle内のコンテンツファイルのもう一つの例です

  {
    "apiVersion": "v1",
    "kind": "PodTemplate",
    "metadata": {
      "name": "nginx"
    },
    "template": {
      "metadata": {
        "labels": {
          "name": "nginx"
        },
        "generateName": "nginx-"
      },
      "spec": {
         "containers": [{
           "name": "nginx",
           "image": "dockerfile/nginx",
           "ports": [{"containerPort": 80}]
         }]
      }
    }
  }

サードパーティーコンテンツマーカー

Kubernetesの実行にはサードパーティーのソフトウェアが必要です。 例えば、名前解決を行うためにはクラスターにDNSサーバーを追加する必要があります。

私たちがサードパーティーソフトウェアにリンクするときや言及するときは、コンテンツガイドに従い、サードパーティーのものに印をつけます。

これらのショートコードを使用すると、それらを使用しているドキュメントページに免責事項が追加されます。

リスト

サードパーティーのリストには、

{{% thirdparty-content %}}

をすべてのアイテムを含むセクションのヘッダーのすぐ下に追加します。

アイテム

ほとんどのアイテムがプロジェクト内ソフトウェア(例えばKubernetes自体やDeschedulerコンポーネント)を参照している場合、違う形を使用することができます。

次のショートコードをアイテムの前か、特定のアイテムのヘッダーのすぐ下に追加します:

{{% thirdparty-content single="true" %}}

バージョン文字列

ドキュメント内でバージョン文字列を生成して挿入するために、いくつかのバージョンショートコードから選んで使用することができます。 それぞれのバージョンショートコードはサイトの設定ファイル(hugo.toml)から取得したバージョンパラメーターの値を使用してバージョン文字列を表示します。 最もよく使われる二つのバージョンパラメーターはlatestとversionです。

{{< param "version" >}}

{{< param "version" >}}ショートコードはサイトのversionパラメーターに設定されたKubernetesドキュメントの現在のバージョンを生成します。 paramショートコードはサイトパラメーターの名前の一つを受けとり、この場合はversionを渡しています。

備考:

以前にリリースされたドキュメントではlatestとversionの値は同じではありません。 新しいバージョンがリリースされると、latestはインクリメントされ、versionは変更されません。 例えば、以前にリリースされたドキュメントはversionをv1.19として表示し、latestをv1.20として表示します。

これは次の様に表示されます:

v1.35

{{< latest-version >}}

{{< latest-version >}}ショートコードはサイトのlatestパラメーターの値を返します。 サイトのlatestパラメーターは新しいドキュメントのバージョンがリリースされた時に更新されます。 このパラメーターは必ずしもversionの値と一致しません。

これは次の様に表示されます:

v1.35

{{< latest-semver >}}

{{< latest-semver >}}ショートコードはlatestから"v"接頭辞を取り除いた値を生成します。

これは次の様に表示されます。

1.35

{{< version-check >}}

{{< version-check >}}ショートコードはページにmin-kubernetes-server-versionパラメーターがあるかどうか確認し、versionと比較するために使用します。

これは次の様に表示されます:

バージョンを確認するには次のコマンドを実行してください: kubectl version.

{{< latest-release-notes >}}

{{< latest-release-notes >}}ショートコードはlatestからバージョン文字列を生成し、"v"接頭辞を取り除きます。 このショートコードはバージョン文字列に対応したリリースノートCHANGELOGページのURLを表示します。

これは次の様に表示されます:

https://git.k8s.io/kubernetes/CHANGELOG/CHANGELOG-1.35.md

次の項目