First Japanese l10n work for release-1.16 (#18790)
* Translate concepts/services-networking/connect-applications-service/ into Japanese (#17710) * Translate concepts/services-networking/connect-applications-service/ into Japanese * Apply review * Translate content/ja/docs/tasks/_index.md into Japanese (#17789) * add task index * huge page * ja-docs: Update kops Installation Steps (#17804) * Update /ja/docs/tasks/tools/install-minikube/ (#17711) * Update /ja/docs/tasks/tools/install-minikube/ * Apply review * Apply review * Update content/ja/docs/tasks/tools/install-minikube.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/tools/install-minikube.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Translate tasks/configure-pod-container/assign-cpu-resource/ in Japanese (#16160) * copy from content/en/docs/tasks/configure-pod-container/ to ja * translate assign-cpu-resource.md in Japanese * Update content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update assign-cpu-resource.md ここの *request* と *limit* はほかの文中の単語とは異なり、YAMLのfieldを表すため、訳さないでおく * fix translation "Pod scheduling is based on requests." の箇所。 requestsに基づいているのは事実だが、直訳されたときになにを指すのかあいまいなので、対象を具体的に記述 * Translate concepts/workloads/controllers/deployment/ in Japanese #14848 (#17794) * ja-trans: Translate concepts/workloads/controllers/deployment/ into Japanese (#14848) * ja-trans: Improve Japanese translation in concepts/workloads/controllers/deployment/ (#14848) * ja-trans: Improve Japanese translation in concepts/workloads/controllers/deployment/ (#14848) * ja-trans: Improve Japanese translation in concepts/workloads/controllers/deployment/ (#14848) * little fix (#18135) * update index (#18136) * Update /ja/docs/setup/_index.md (#18139) * Update /ja/docs/tasks/tools/install-kubectl/ (#18137) * update /docs/ja/tasks/tools/install-kubectl/ * fix mongon * apply reveiw * Update /ja/docs/reference/command-line-tools-reference/feature-gates/ (#18141) * Update feature agete * tidy up feature gates list * translate new lines * table caption * blank * する -> します * apply review * fix broken link * Update content/ja/docs/reference/command-line-tools-reference/feature-gates.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * update translation * remove line * Update content/ja/docs/reference/command-line-tools-reference/feature-gates.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * rollpack * Update /ja/docs/concepts/services-networking/service/ (#18138) * update /ja/docs/concepts/services-networking/service/ * Update content/ja/docs/concepts/services-networking/service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/services-networking/service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/services-networking/service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/services-networking/service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * consider Endpoints as a Kubernetes resource * full * Update content/ja/docs/concepts/_index.md (#18145) * Update concepts * control plane * apply review * fix bold (#18165) * Update /ja/docs/concepts/overview/components.md (#18153) * update /ja/docs/concepts/overview/components.md * some japanese docs are already there * translate prepend * apply upstream changes (#18278) * Translate concepts/services-networking/ingress into Japanese #17741 (#18234) * ja-trans: Translate concepts/services-networking/ingress into Japanese (#17741) * ja-trans: Improve Japanese translation in concepts/services-networking/ingress (#17741) * ja-trans: Improve Japanese translation in concepts/services-networking/ingress (#17741) * Update pod overview in Japanese (#18277) * Update pod-overview * Update content/ja/docs/concepts/workloads/pods/pod-overview.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/workloads/pods/pod-overview.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/workloads/pods/pod-overview.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/workloads/pods/pod-overview.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/workloads/pods/pod-overview.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/workloads/pods/pod-overview.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * ノード * Update content/ja/docs/concepts/workloads/pods/pod-overview.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/workloads/pods/pod-overview.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> Co-authored-by: Naoki Oketani <okepy.naoki@gmail.com> * Translate concepts/scheduling/scheduler-perf-tuning/ in Japanese #17119 (#17796) * ja-trans: Translate concepts/scheduling/scheduler-perf-tuning/ into Japanese (#17119) * ja-trans: Improve Japanese translation in concepts/scheduling/scheduler-perf-tuning/ (#17119) * ja-trans: Improve Japanese translation in concepts/scheduling/scheduler-perf-tuning/ (#17119) * ja-trans:conetent/ja/casestudies/nav (#18450) * Translate tasks/debug-application-cluster/debug-service/ in Japanese (#18395) * Translate tasks/debug-application-cluster/debug-service/ in Japanese * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Change all `Pods` to `Pod` and `Endpoints` to `Endpoint` * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Updated content pointed out in review * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Apply suggestions from code review Co-Authored-By: inductor <kohei.ota@zozo.com> * Apply suggestions from review * Apply suggestions form review * Apply suggestions from review * Apply suggestions from review * Apply suggestions from code review Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> Co-authored-by: inductor <kohei.ota@zozo.com> Co-authored-by: Naoki Oketani <okepy.naoki@gmail.com> * Translate concepts/extend-kubernetes/api-extension/custom-resources/ into Japanese (#18200) * Translate concepts/extend-kubernetes/api-extension/custom-resources/ into Japanese * Apply suggestions from code review between L1 an L120 by oke-py Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Apply suggestions from code review by oke-py Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update CustomResourceDefinition not to localize into Japanese * Revert the link to customresourcedefinitions to English Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Apply suggestions from code review by oke-py and inductor Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> Co-Authored-By: inductor <kohei.ota@zozo.com> * Apply a suggestion from review by inductor * Apply a suggestion from code review by oke-py Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> Co-authored-by: Naoki Oketani <okepy.naoki@gmail.com> Co-authored-by: inductor <kohei.ota@zozo.com> * Translate tasks/configure-pod-container/quality-service-pod/ into Japanese (#16173) * copy from content/en/docs/tasks/configure-pod-container/quality-service-pod.md to Ja * Translate tasks/configure-pod-container/quality-service-pod/ into Japanese Guaranteed, Burstable, BestEffortは用語として存在するので訳さない Signed-off-by: Takuma Hashimoto <takumaxd+github@gmail.com> * Update content/ja/docs/tasks/configure-pod-container/quality-service-pod.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/configure-pod-container/quality-service-pod.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/configure-pod-container/quality-service-pod.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/configure-pod-container/quality-service-pod.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> Co-authored-by: Naoki Oketani <okepy.naoki@gmail.com> * Translate content/ja/docs/reference/kubectl/cheatsheet.md (#17739) (#18285) * Translate content/ja/docs/reference/kubectl/cheatsheet.md (#17739) * Translated kubectl cheet sheet. * Fix typos in content/ja/docs/reference/kubectl/cheatsheet.md (#17739) * Fix japanese style in content/ja/docs/reference/kubectl/cheatsheet.md * Fix typo in content/ja/docs/reference/kubectl/cheatsheet.md * Fix translation in content/ja/docs/reference/kubectl/cheatsheet.md * Fix typo in content/ja/docs/reference/kubectl/cheatsheet.md * Fix typo in content/ja/docs/reference/kubectl/cheatsheet.md * Modify translation for casestudies (#18767) * modify terminology * add ten * update translation * update * update * update * fix typo (#18769) * remove english comment (#18770) * ja-trans:conetent/ja/casestudies/spotify (#18451) * ja-trans: content/ja/case-studies/spotify * Update content/ja/case-studies/spotify/index.html Updated with the proposal from inductor Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Updated with inductor 's proposal Co-Authored-By: inductor <kohei.ota@zozo.com> * ja-trans: content/ja/case-studies/spotify * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> Co-authored-by: inductor <kohei.ota@zozo.com> * Translate Japanese headers (#18776) * translate headers * add index for references * Update content/ja/docs/setup/production-environment/tools/_index.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * translate controller Co-authored-by: Naoki Oketani <okepy.naoki@gmail.com> * ja-docs: translate install-kubeadm into Japanese (#18198) * ja-docs: translate install-kubeadm into Japanese * translate table title in install-kubeadm to Japanese * update kubeadm install doc * remove extra spaces * fix translation miss * translate url title into japanese * fix translation miss * remove line break in sentence and translate title * remove extra line break * remove extra line break * fix translation miss Co-authored-by: Naoki Oketani <okepy.naoki@gmail.com> Co-authored-by: Samuel Kihahu <kihahu@users.noreply.github.com> Co-authored-by: Takuma Hashimoto <takuma-hashimoto@freee.co.jp> Co-authored-by: Keita Akutsu <kakts.git@gmail.com> Co-authored-by: Masa Taniguchi <maabou512@gmail.com> Co-authored-by: Soto Sugita <sotoiwa@gmail.com> Co-authored-by: Kozzy Hasebe <48105562+hasebe@users.noreply.github.com> Co-authored-by: kazuaki harada <canhel.4suti50y.salamander@gmail.com> Co-authored-by: Shunsuke Miyoshi <s.miyoshi@jp.fujitsu.com>
This commit is contained in:
inductor
Kubernetes Prow Robot
parent
3da672600e
commit
0c86e6515a
|
|
@ -1,8 +1,9 @@
|
|||
---
|
||||
title: "Production-Grade Container Orchestration"
|
||||
title: "プロダクショングレードのコンテナ管理基盤"
|
||||
abstract: "自動化されたコンテナのデプロイ・スケール・管理"
|
||||
cid: home
|
||||
---
|
||||
{{< announcement >}}
|
||||
|
||||
{{< deprecationwarning >}}
|
||||
|
||||
|
|
@ -44,12 +45,12 @@ Kubernetesはオープンソースなので、オンプレミスやパブリッ
|
|||
<br>
|
||||
<br>
|
||||
<br>
|
||||
<a href="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2019" button id="desktopKCButton">2019年5月のKubeCon バルセロナに参加する</a>
|
||||
<a href="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2020/" button id="desktopKCButton">2020年4月のKubeCon アムステルダムに参加する</a>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
<a href="https://www.lfasiallc.com/events/kubecon-cloudnativecon-china-2019" button id="desktopKCButton">2019年6月のKubeCon 上海に参加する</a>
|
||||
<a href="https://events19.lfasiallc.com/events/kubecon-cloudnativecon-china-2019/" button id="desktopKCButton">2020年7月のKubeCon 上海に参加する</a>
|
||||
</div>
|
||||
<div id="videoPlayer">
|
||||
<iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ quote: >
|
|||
そのため、提供までのパイプラインにボトルネックがあったのです。」
|
||||
これと同時に、エンジニアリングチームが大きくなっていき、その成長を後押しし加速する上でも、より良いインフラが必要であることに同社は気づいたのです。
|
||||
<br><br><h2>ソリューション</h2>Lacerteは言います。「私のアイデアは、チームがサービスをもっと高速にデプロイできる環境を作ろうぜ、というものです。そうすれば彼らも『そうだね、モノリスはもう建てたくないしサービスを構築したいよ』と言うでしょう。」
|
||||
彼らは、2016年初め<a href="https://kubernetes.io/">Kubernetes</a> の採用を決定するにあたり、他のいくつかのテクノロジーを調査・検討し、プロトタイプを作りました。 Lacerteのチームはこのプラットフォームへの監視のために<a href="https://prometheus.io/">Prometheus</a>
|
||||
彼らは、2016年初め<a href="https://kubernetes.io/">Kubernetes</a> の採用を決定するにあたり、他のいくつかの技術を調査・検討し、プロトタイプを作りました。 Lacerteのチームはこのプラットフォームへの監視のために<a href="https://prometheus.io/">Prometheus</a>
|
||||
モニタリングツールを統合しました。この次にあるのはトレーシングです。今やAppDirectは本番環境で50以上のマイクロサービス、15のKubernetesクラスターを<a href="https://aws.amazon.com/">AWS</a> 上や世界中のオンプレミス環境で展開しています。 <br><br><h2>インパクト</h2>Kubernetesプラットフォームは、エンジニアリングチームのここ数年の10倍成長を後押ししてきました。
|
||||
彼らが継続的に機能追加しているという事実と相まって「この新たなインフラがなければ、我々は大幅なスローダウンを強いられていたと思います」と、Lacerte氏は述べています。Kubernetesとサービス化へ移行していくことは、SCPコマンドを用いた、カスタムメイドで不安定なシェルスクリプトへの依存性を弱め、非常に高速になったことを意味していました。
|
||||
新しいバージョンをデプロイする時間は4時間から数分間に短縮されました。
|
||||
|
|
@ -51,7 +51,7 @@ quote: >
|
|||
<div class="banner3text">「正しいタイミングで正しい判断ができました。Kubernetesとクラウドネイティブ技術は、いまやデファクトのエコシステムとみなされています。スケールアウトしていく中で直面する新たな難題に取り組むにはどこに注力すべきか、私たちはわかっています。このコミュニティーはとても活発で、当社の優秀なチームをすばらしく補完してくれています。」<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- AppDirect ソフトウェア開発者 Alexandre Gervais </span></div>
|
||||
</div>
|
||||
<section class="section3">
|
||||
<div class="fullcol">Lacerteは当初から言っていました。「私のアイデアは、チームがサービスをもっと高速にデプロイできる環境を作ろう、というものです。そうすれば彼らもこう言うでしょう『そうだよ、モノリスを建てるなんてもうしたくないしサービスを構築したいんだ』と」(Lacerteは2019年に同社を退社)。<br><br>Lacerteのグループは運用チームと連携することで同社の <a href="https://aws.amazon.com/">AWSのインフラ</a>により多くアクセスし、コントロールするようになりました。そして、いくつかのオーケストレーションテクノロジーのプロトタイプを作り始めたのです。「当時を振り返ると、Kubernetesはちょっとアンダーグラウンドというか、それほど知られていなかったように思います。」と彼は言います。「しかし、コミュニティーやPull requestの数、GitHub上でのスピードなどをよく見てみると勢いが増してきていることがわかりました。他のテクノロジーよりも管理がはるかに簡単であることもわかりました。」彼らは、Kubernetes上で <a href="https://www.chef.io/">Chef</a> や<a href="https://www.terraform.io/">Terraform</a> によるプロビジョニングを用いながら最初のいくつかのサービスを開発しました。その後さらにサービスも、自動化されるところも増えました。「韓国、オーストラリア、ドイツ、そしてアメリカ、私たちのクラスターは世界中にあります。」とLacerteは言います。「自動化は私たちにとって極めて重要です。」今彼らは大部分で<a href="https://github.com/kubernetes/kops">Kops</a>を使っていて、いくつかのクラウドプロバイダーから提供されるマネージドKubernetesサービスも視野に入れていれています。<br><br> 今もモノリスは存在してはいますが、コミットや機能はどんどん少なくなってきています。あらゆるチームがこの新たなインフラ上でデプロイしていて、それらはサービスとして提供されるのが一般的です。今やAppDirectは本番環境で50以上のマイクロサービス、15のKubernetesクラスターをAWS上や世界中のオンプレミス環境で展開しています。<br><br> Kubernetesプラットフォームがデプロイ時間に非常に大きなインパクトを与えたことから、Lacerteの戦略が究極的に機能しました。カスタムメイドで不安定だった、SCPコマンドを用いたシェルスクリプトに対する依存性を弱めることで、新しいバージョンをデプロイする時間は4時間から数分にまで短縮されるようになったのです。こういったことに加え同社は、開発者たちが自らのサービスとして仕立て上げるよう、数多くの努力をしてきました。「新しいサービスを始めるのに、 <a href="https://www.atlassian.com/software/jira">Jira</a>のチケットや他のチームとのミーティングはもはや必要ないのです」とLacerteは言います。以前、週あたり1〜30だった同社のデプロイ数は、いまや週1,600デプロイにまでなっています。
|
||||
<div class="fullcol">Lacerteは当初から言っていました。「私のアイデアは、チームがサービスをもっと高速にデプロイできる環境を作ろう、というものです。そうすれば彼らもこう言うでしょう『そうだよ、モノリスを建てるなんてもうしたくないしサービスを構築したいんだ』と」(Lacerteは2019年に同社を退社)。<br><br>Lacerteのグループは運用チームと連携することで同社の <a href="https://aws.amazon.com/">AWSのインフラ</a>により多くアクセスし、コントロールするようになりました。そして、いくつかのオーケストレーション技術のプロトタイプを作り始めたのです。「当時を振り返ると、Kubernetesはちょっとアンダーグラウンドというか、それほど知られていなかったように思います。」と彼は言います。「しかし、コミュニティーやPull requestの数、GitHub上でのスピードなどをよく見てみると勢いが増してきていることがわかりました。他の技術よりも管理がはるかに簡単であることもわかりました。」彼らは、Kubernetes上で <a href="https://www.chef.io/">Chef</a> や<a href="https://www.terraform.io/">Terraform</a> によるプロビジョニングを用いながら最初のいくつかのサービスを開発しました。その後さらにサービスも、自動化されるところも増えました。「韓国、オーストラリア、ドイツ、そしてアメリカ、私たちのクラスターは世界中にあります。」とLacerteは言います。「自動化は私たちにとって極めて重要です。」今彼らは大部分で<a href="https://github.com/kubernetes/kops">Kops</a>を使っていて、いくつかのクラウドプロバイダーから提供されるマネージドKubernetesサービスも視野に入れていれています。<br><br> 今もモノリスは存在してはいますが、コミットや機能はどんどん少なくなってきています。あらゆるチームがこの新たなインフラ上でデプロイしていて、それらはサービスとして提供されるのが一般的です。今やAppDirectは本番環境で50以上のマイクロサービス、15のKubernetesクラスターをAWS上や世界中のオンプレミス環境で展開しています。<br><br> Kubernetesプラットフォームがデプロイ時間に非常に大きなインパクトを与えたことから、Lacerteの戦略が究極的に機能しました。カスタムメイドで不安定だった、SCPコマンドを用いたシェルスクリプトに対する依存性を弱めることで、新しいバージョンをデプロイする時間は4時間から数分にまで短縮されるようになったのです。こういったことに加え同社は、開発者たちが自らのサービスとして仕立て上げるよう、数多くの努力をしてきました。「新しいサービスを始めるのに、 <a href="https://www.atlassian.com/software/jira">Jira</a>のチケットや他のチームとのミーティングはもはや必要ないのです」とLacerteは言います。以前、週あたり1〜30だった同社のデプロイ数は、いまや週1,600デプロイにまでなっています。
|
||||
</div>
|
||||
</section>
|
||||
<div class="banner4" style="background-image: url('/images/CaseStudy_appdirect_banner4.jpg');width:100%;">
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ logo: chinaunicom_featured_logo.png
|
|||
featured: true
|
||||
weight: 1
|
||||
quote: >
|
||||
Kubernetesが私たちのクラウドインフラの経験値を上げてくれました。今のところこれに代わるテクノロジーはありません。
|
||||
Kubernetesが私たちのクラウドインフラの経験値を上げてくれました。今のところ、これに代わる技術はありません。
|
||||
---
|
||||
|
||||
<div class="banner1" style="background-image: url('/images/CaseStudy_chinaunicom_banner1.jpg')">
|
||||
|
|
@ -32,7 +32,7 @@ quote: >
|
|||
<br><br>
|
||||
|
||||
<h2>ソリューション</h2>
|
||||
急成長し、オープンソースコミュニティも成熟しているKubernetesはChina Unicomにとって自然な選択となりました。同社のKubernetes対応クラウドプラットフォームは、現状の50のマイクロサービスに加え、これから新たに開発されるすべてをここでホストしていくそうです。「Kubernetesが私たちのクラウドインフラの経験値を上げてくれました」とZhangはいいます。「今のところこれに代わるテクノロジーはありません。」また、China Unicomはそのマイクロサービスフレームワークのために、<a href="https://istio.io/">Istio</a>、 <a href="https://www.envoyproxy.io/">Envoy</a>、 <a href="https://coredns.io/">CoreDNS</a>、そして<a href="https://www.fluentd.org/">Fluentd</a>も活用しています。
|
||||
急成長し、オープンソースコミュニティも成熟しているKubernetesはChina Unicomにとって自然な選択となりました。同社のKubernetes対応クラウドプラットフォームでは、現状の50のマイクロサービスに加え、これから新たに開発されるすべてをここでホストしていくそうです。「Kubernetesが私たちのクラウドインフラの経験値を上げてくれました」とZhangはいいます。「今のところ、これに代わる技術はありません。」また、China Unicomはそのマイクロサービスフレームワークのために、<a href="https://istio.io/">Istio</a>、 <a href="https://www.envoyproxy.io/">Envoy</a>、 <a href="https://coredns.io/">CoreDNS</a>、そして<a href="https://www.fluentd.org/">Fluentd</a>も活用しています。
|
||||
<br><br>
|
||||
<h2>インパクト</h2>
|
||||
KubernetesはChina Unicomの運用と開発、両方について効率を高めてくれました。
|
||||
|
|
@ -44,7 +44,7 @@ quote: >
|
|||
</section>
|
||||
<div class="banner2">
|
||||
<div class="banner2text">
|
||||
「Kubernetesが私達のクラウドインフラの経験値を上げてくれました。今のところこれに代わるテクノロジーはありません。」
|
||||
「Kubernetesが私達のクラウドインフラの経験値を上げてくれました。今のところ、これに代わる技術はありません。」
|
||||
<span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Chengyu Zhang、 China Unicom プラットフォーム技術R&D グループリーダー</span></span>
|
||||
</div>
|
||||
</div>
|
||||
|
|
@ -54,7 +54,7 @@ quote: >
|
|||
|
||||
その舞台裏で、同社は2016年以来、Dockerコンテナ、VMware、OpenStackインフラなどを用いて、数千のサーバーを持つデータセンターを複数運用しています。残念ながら、「リソース利用率は相対的に低かった」と、プラットフォーム技術のR&D部門のグループリーダーであるChengyu Zhangは語っています。「そして、私たちには何百ものアプリケーションを収容できるクラウドプラットフォームがありませんでした。」
|
||||
<br><br>
|
||||
そこで新しいテクノロジー、研究開発(R&D)、およびプラットフォームの責務を担うZhangのチームは、IT管理におけるソリューションの探索を始めました。以前は完全な国営企業だったChina Unicomは、近年BAT(Baidu、Alibaba、Tencent)およびJD.comからの民間投資を受け、今は商用製品ではなくオープンソース技術を活用した社内開発に注力するようになりました。こういったこともあり、Zhangのチームはクラウドインフラのオープンソースオーケストレーションツールを探し始めたのです。
|
||||
そこで新しい技術、研究開発(R&D)、およびプラットフォームの責務を担うZhangのチームは、IT管理におけるソリューションの探索を始めました。以前は完全な国営企業だったChina Unicomは、近年BAT(Baidu、Alibaba、Tencent)およびJD.comからの民間投資を受け、今は商用製品ではなくオープンソース技術を活用した社内開発に注力するようになりました。こういったこともあり、Zhangのチームはクラウドインフラのオープンソースオーケストレーションツールを探し始めたのです。
|
||||
</div>
|
||||
</section>
|
||||
<div class="banner3" style="background-image: url('/images/CaseStudy_chinaunicom_banner3.jpg');width:100%;padding-left:0;">
|
||||
|
|
@ -67,9 +67,9 @@ quote: >
|
|||
<div class="fullcol">
|
||||
China Unicomはすでにコアとなる事業運用システムにMesosを活用していましたが、チームにとっては新しいクラウドプラットフォームにはKubernetesの選択が自然だろうと感じられたのです。「大きな理由は、Kubernetesには成熟したコミュニティがある、ということでした」とZhangは言います。「さらにKubernetesは非常に早いペースで成長していることもあり、さまざまな人のベストプラクティスから多くを学ぶことができるのです。」 またChina UnicomはマイクロサービスフレームワークのためにIstio、Envoy、CoreDNS、およびFluentdも使用しています。<br><br>
|
||||
|
||||
同社のKubernetes対応クラウドプラットフォームは、現状の50のマイクロサービスに加え、これから新たに開発されるすべてをここでホストしていくそうです。China Unicomの開発者たちは自身の手による開発を省き、APIを介すことで簡単にテクノロジーが利用できるようになりました。このクラウドプラットフォームは、同社データセンタのPaaSプラットフォームに繋がった20〜30のサービスを提供することに加え、中国国内の31省にわたる拠点の社内ユーザーたちが行うビッグデータ分析などもサポートしています。<br><br>
|
||||
同社のKubernetes対応クラウドプラットフォームでは、現状の50のマイクロサービスに加え、これから新たに開発されるすべてをここでホストしていくそうです。China Unicomの開発者たちは自身の手による開発を省き、APIを介すことで簡単に技術が利用できるようになりました。このクラウドプラットフォームは、同社データセンタのPaaSプラットフォームに繋がった20〜30のサービスを提供することに加え、中国国内の31省にわたる拠点の社内ユーザーたちが行うビッグデータ分析などもサポートしています。<br><br>
|
||||
|
||||
「Kubernetesが私達のクラウドインフラの経験値を上げてくれました。」とZhangはいいます。「今のところこれに代わるテクノロジーはありません。」
|
||||
「Kubernetesが私達のクラウドインフラの経験値を上げてくれました。」とZhangはいいます。「今のところ、これに代わる技術はありません。」
|
||||
|
||||
</div>
|
||||
</section>
|
||||
|
|
@ -87,12 +87,12 @@ quote: >
|
|||
|
||||
<div class="banner5" >
|
||||
<div class="banner5text">
|
||||
「企業はRancherのような事業者が提供するマネージドサービスを活用することができます。こういったテクノロジーはすでにカスタマイズされて提供されるので、簡単に利用することができるでしょう。」<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Jie Jia、China Unicom プラットフォーム技術 R&D</span></div>
|
||||
「企業はRancherのような事業者が提供するマネージドサービスを活用することができます。こうした技術はすでにカスタマイズされて提供されるので、簡単に利用することができるでしょう。」<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Jie Jia、China Unicom プラットフォーム技術 R&D</span></div>
|
||||
</div>
|
||||
|
||||
<div class="fullcol">
|
||||
プラットフォーム技術 R&D チームの一員であるJie Jiaは、「この技術は比較的複雑ですが、開発者が慣れれば、恩恵をすべて享受できるのではないかと思います」と付け加えています。一方でZhangは、仮想マシンベースのクラウドでの経験から見ると、「Kubernetesとこれらのクラウドネイティブテクノロジーは比較的シンプルなのではないか」と指摘しています。<br><br>
|
||||
「企業は <a href="https://rancher.com/">Rancher</a> のような事業者が提供するマネージドサービスを活用することができます。こういったテクノロジーはカスタマイズてされて提供されるので、簡単に利用することができるでしょう。」 <br><br>
|
||||
プラットフォーム技術 R&D チームの一員であるJie Jiaは、「この技術は比較的複雑ですが、開発者が慣れれば、恩恵をすべて享受できるのではないかと思います」と付け加えています。一方でZhangは、仮想マシンベースのクラウドでの経験から見ると、「Kubernetesとこれらのクラウドネイティブ技術は比較的シンプルなのではないか」と指摘しています。<br><br>
|
||||
「企業は <a href="https://rancher.com/">Rancher</a> のような事業者が提供するマネージドサービスを活用することができます。こうした技術はカスタマイズされて提供されるので、簡単に利用することができるでしょう。」 <br><br>
|
||||
|
||||
今後China Unicomはビッグデータと機械学習に重点を置いて、Kubernetes上でより多くのアプリケーションを開発することを計画しています。彼らのチームは築き上げたクラウドプラットフォームを継続的に最適化しており、CNCFの<a href="https://www.cncf.io/announcement/2017/11/13/cloud-native-computing-foundation-launches-certified-kubernetes-program-32-conformant-distributions-platforms/">認定Kubernetesコンフォーマンスプログラム(Certified Kubernetes Conformance Program)</a>に参加するべく、そのための適合テスト(Conformance test)への合格を目指しています。また彼らは、どこかのタイミングでコミュニティにコードをコントリビューションすることも目指しています。<br><br>
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,93 @@
|
|||
---
|
||||
title: Navケーススタディ
|
||||
linkTitle: Nav
|
||||
case_study_styles: true
|
||||
cid: caseStudies
|
||||
css: /css/style_case_studies.css
|
||||
logo: nav_featured_logo.png
|
||||
featured: true
|
||||
weight: 3
|
||||
quote: >
|
||||
コミュニティは非常に活発です。アイデアを出し合い、皆が直面する多くの類似課題について話すことができ、そして支援を得ることができます。私たちはさまざまな理由から同じ問題に取り組み、そこでお互いに助け合うことができる、そういう点が気に入っています。
|
||||
---
|
||||
|
||||
<div class="banner1" style="background-image: url('/images/CaseStudy_nav_banner1.jpg')">
|
||||
<h1>ケーススタディ：<img src="/images/nav_logo.png" class="header_logo" style="width:15%"><br><div class="subhead" style="margin-top:1%">スタートアップはどのようにしてKubernetesでインフラコストを50％も削減したのか</div></h1>
|
||||
|
||||
</div>
|
||||
|
||||
<div class="details">
|
||||
企業名 <b>Nav</b> 所在地 <b>ユタ州ソルトレイクシティ、カリフォルニア州サンマテオ</b> 業界 <b>事業者向け金融サービス</b>
|
||||
</div>
|
||||
|
||||
<hr>
|
||||
<section class="section1">
|
||||
<div class="cols">
|
||||
<div class="col1" style="width:100%;margin-left:-1.5%">
|
||||
<br><br>
|
||||
<h2>課題</h2>
|
||||
2012年に設立された <a href="https://www.nav.com/">Nav</a>は、小規模事業者たちに、民間信用調査企業主要3社 —Equifax、Experian、Dun＆Bradstreet— におけるビジネス信用スコアと、彼らのニーズに最適な資金調達オプションを提供しています。このスタートアップは5年で急速に成長したことで、「クラウド環境が非常に大きくなっていったのですが、これらの環境の使用率は極端に低く、1％を下回っていました」とエンジニアリングディレクターのTravis Jeppsonは述べています。「クラウド環境の使用率と実際私たちに必要なものとを連動させたかったので、同じリソースプールを共有しながら複数のワークロードそれぞれを分離して実行できるコンテナ化やオーケストレーションを検討しました。」
|
||||
<br><br>
|
||||
<h2>ソリューション</h2>
|
||||
数多くのオーケストレーション ソリューションを評価した結果、Navチームは <a href="https://aws.amazon.com/">AWS</a>上で稼働する <a href="https://kubernetes.io/">Kubernetes</a>を採用することを決めました。Kubernetesを取り巻くコミュニティの強みは人を引きつける点にあり、それがGoogleから生まれたものであることもその一つです。加えて、「他のソリューションは、かなり手間がかかり、本当に複雑で大きなものでした。そしてすぐに管理できるかという点においても厳しいものになりがちでした」とJeppsonは言います。「Kubernetesはその当時の私たちのニーズに合ったオーケストレーションソリューションに踏み出せる、とてもシンプルなやり方を提供してくれました。さらにその拡張性は、私たちがKubernetesと共に成長し、その後の追加機能を組み入れることを可能にしてくれました。」
|
||||
|
||||
<h2>インパクト</h2>
|
||||
4人編成のチームは、6か月でKubernetesを稼働させ、その後の6ヶ月でNavの25あったマイクロサービスすべてのマイグレーションを完了させました。その結果は目覚しいものでした。導入のきっかけとなったリソース使用率については、1％から40％まで増加しました。かつて新しいサービスを立ち上げるのに2人の開発者が2週間かけていましたが、いまや開発者はたった一人で10分もかかりません。デプロイ数は5倍増えました。そして同社はインフラコストを50％削減しています。
|
||||
|
||||
</div>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<div class="banner2">
|
||||
<div class="banner2text"><iframe width="500" height="320" src="https://www.youtube.com/embed/0IbOk1_H-f0" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
|
||||
<br><br>
|
||||
「Kubernetesはその当時の私たちのニーズに合ったオーケストレーションソリューションに踏み出せる、とてもシンプルなやり方を提供してくれました。さらにその拡張性は、私たちがKubernetesと共に成長し、その後の追加機能を組み入れることを可能にしてくれました。」
|
||||
<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Travis Jeppson、Nav エンジニアリング ディレクター</span></div>
|
||||
</div>
|
||||
<section class="section2">
|
||||
<div class="fullcol">
|
||||
<h2>2012年に設立された <a href="https://www.nav.com/">Nav</a>は、小規模事業者たちに、民間信用調査企業主要3社 —Equifax、Experian、Dun＆Bradstreet— におけるビジネス信用スコアと、彼らのニーズに最適な資金調達オプションを提供しています。「スモールビジネスの成功率を上げていくこと。」そのミッションはここに凝縮される、とエンジニアリングディレクターのTravis Jeppsonは言います。 </h2>
|
||||
数年前、Navは自分たちの成功への道筋に、障害があることを認識しました。ビジネスが急速に成長し、「クラウド環境が非常に大きくなっていったのですが、これらの環境の使用率は極端に低く、1％を下回っていました」と、Jeppsonは言います。「問題の大部分はスケールに関するものでした。私たちはそこにただお金を投入しようとしていました。『もっと多くのサーバーを稼働させよう。増えた負荷をさばくためにより多く作業しよう』といった具合に。私たちはスタートアップなので、そんなことをしていては終焉の一途をたどりかねませんし、そんなことにに使えるほどお金の余裕は我々にはないのです。」
|
||||
<br><br>
|
||||
こういったことに加えてすべての新サービスは違う10人を経由してリリースされなければならず、サービス立ち上げに2週間という受け入れがたいほどの時間をかけていたのです。パッチ管理とサーバ管理のすべてが手動で行われていたので、皆がそれらを見守り、うまく維持していく必要があったのです」とJeppsonは付け加えます。「非常にやっかいなシステムでした。」
|
||||
|
||||
</div>
|
||||
</section>
|
||||
<div class="banner3" style="background-image: url('/images/CaseStudy_nav_banner3.jpg')">
|
||||
<div class="banner3text"> 「コミュニティは非常に活発です。アイデアを出し合い、皆が直面する多くの類似課題について話すことができ、そして支援を得ることができます。私たちはさまざまな理由から同じ問題に取り組み、そこでお互いに助け合うことができる、そういう点が気に入っています。」<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Travis Jeppson、Nav エンジニアリングディレクター</span></div>
|
||||
|
||||
|
||||
</div>
|
||||
<section class="section3">
|
||||
<div class="fullcol">Jeppsonは前職でコンテナを取り扱っていたため、Navの経営陣にこれらの問題の解決策としてこの技術を売り込みました。そして2017年初め彼の提案にゴーサインがでました。「クラウド環境の使用率と実際私たちに必要なものとを連動させたかったので、類似したリソースプールを共有しながら複数のワークロードそれぞれを分離して実行できるコンテナ化やオーケストレーションを検討しました」と、彼は言います。<br><br>
|
||||
数多くのオーケストレーションソリューションを評価した結果、Navチームは <a href="https://aws.amazon.com/">AWS</a>での<a href="https://kubernetes.io/">Kubernetes</a> 採用を決断しました。Kubernetesを取り巻くコミュニティの強みは人を引きつける点にあり、それがGoogleから生まれたものであることもその一つです。加えて、「他のソリューションは、かなり手間がかかり、本当に複雑で大きなものでした。そしてすぐに管理できるかという点においても厳しいものになりがちでした」とJeppsonは言います。「Kubernetesはその当時の私たちのニーズに合ったオーケストレーションソリューションに踏み出せる、とてもシンプルなやり方を提供してくれました。一方でその拡張性は、私たちがKubernetesと共に成長し、その後の追加機能を組み入れることを可能にしてくれました。」<br><br>
|
||||
Jeppsonの4人編成のエンジニアリングサービスチームは、Kubernetesを立ち上げ、稼働させるのに6ヶ月かけました（クラスターを動かすために <a href="http://kubespray.io/">Kubespray</a> を使いました）。そして、その後6ヶ月かけNavの25のマイクロサービスと一つのモノリシックな主要サービスのフルマイグレーションを完了させました。「すべて書き換えたり、止めることはできませんでした」と彼は言います。「稼働し、利用可能であり続けなければいけなかったですし、ダウンタイムがあってもをそれを最小にしなければなりませんでした。そのためパイプライン作成、メトリクスやロギングといったことについてよくわかるようになりました。さらにKubernetes自身についても習熟し、起動、アップグレード、サービス提供の仕方についてもわかるようになりました。そうして移行を少しずつ進めていきました。」
|
||||
</div>
|
||||
</section>
|
||||
<div class="banner4" style="background-image: url('/images/CaseStudy_nav_banner4.jpg')" style="width:100%">
|
||||
<div class="banner4text">
|
||||
「Kubernetesは、これまで経験したことのない新たな自由とたくさんの価値をNavにもたらしてくれました。」 <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Travis Jeppson、Nav エンジニアリングディレクター</span>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<section class="section5" style="padding:0px !important">
|
||||
|
||||
<div class="fullcol">
|
||||
この過程で重要だったのは、Navの50人のエンジニアを教育すること、そしてマイグレーションに当たり新たなワークフローやロードマップについて透明性を確保することでした。
|
||||
そこでJeppsonはエンジニアリングスタッフ全員に対し定期的なプレゼンテーションや、一週間にわたる1日4時間の実習の場を設けました。そして彼はすべての情報を置いておくために <a href="https://gitlab.com/">GitLab</a>にリポジトリを作成しました。 「フロントエンドとバックエンドの開発者たち全員に、<a href="https://kubernetes.io/docs/tasks/tools/install-kubectl/">kubectl</a>を用い、独力でnamespaceを作成し、取り扱う方法を見せていきました」と彼は言います。「いまや、彼らはやってきて『これは準備OKだ』というだけで済むことが多くなりました。GitLabの小さなボタンをクリックすれば本番環境にリリースできるようになっているので彼らはすぐに次の行動に移ることができます。」<br><br>
|
||||
マイグレーションが2018年初めに完了したあとの結果は目覚しいものでした。導入のきっかけとなったリソース使用率については、1％から40％まで増加しました。かつて新しいサービスを立ち上げるのに2人の開発者が2週間かけていましたが、いまや開発者はたった一人で10分もかかりません。デプロイ数は1日あたり10だったものから50となり5倍増えました。そして同社はインフラコストを50％削減しています。「次はデータベース側に取り組みたいです。それができればかなりのコスト削減を継続できるでしょう」とJeppsonは言います。<br><br>
|
||||
また、KubernetesはNavのコンプライアンスのニーズにも力を貸しました。以前は、「1つのアプリケーションを1つのサーバーにマッピングする必要がありました。これは主にデータ周辺でコンプライアンスの異なるレギュレーションがあったためです」とJeppsonは言います。「KubernetesのAPIを用いれば、ネットワークポリシーを追加し、必要に応じてそれらのデータを分離し制限をかけることができるようになります。」同社は、クラスターを規制のないゾーンと、独自ノードセットを持ったデータ保護を行うべき規制ゾーンに分離しています。また、<a href="https://www.twistlock.com/">Twistlock</a>ツールを使用することでセキュリティを確保しています。「夜、よく眠れることもね」と彼は付け加えます。
|
||||
</div>
|
||||
|
||||
<div class="banner5" >
|
||||
<div class="banner5text">「今私たちが扱っているトラフィック量の4〜10倍が流れたとしても、『ああ、大丈夫だよ、Kubernetesがやってくれるから』と話しています。」<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Travis Jeppson、Nav エンジニアリング ディレクター</span></div>
|
||||
</div>
|
||||
|
||||
<div class="fullcol">
|
||||
Kubernetesが導入された中、Navチームは <a href="https://prometheus.io/">Prometheus</a>を採用してシステムのメトリクスやロギングの改良も始めました。。「Prometheusは開発者にとって、とても採用しやすいメトリクスの標準を作ってくれました」とJeppsonは言います。「彼らには、何をしたいかを示し、したいことを実践し、そして彼らのコードベースをクリーンな状態に保つ自由があります。そして私たちにとってそれはまちがいなく必須事項でした。」<br><br>
|
||||
これから先を見据え、次にNavが意欲的に視野に入れているのは、トレーシング(Tracing)、ストレージ、そしてサービスメッシュです。そしてKubeConで多くの時間をいろんな企業との対話に費やしたその後で、現在彼らは<a href="https://www.envoyproxy.io/">Envoy</a>、 <a href="https://opentracing.io/">OpenTracing</a>、そして <a href="https://www.jaegertracing.io/">Jaeger</a>を検証しています。「コミュニティは非常に活発です。アイデアを出し合い、皆が直面する多くの類似課題について話すことができ、そして支援を得ることができます。私たちはさまざまな理由から同じ問題に取り組み、そこでお互いに助け合うことができる、そういう点が気に入っています」とJeppsonは言います。「クラウドネイティブなソリューションをフルに採用できるようになるには、スケーラビリティ面でやるべきことがまだたくさんあります。」<br><br>
|
||||
もちろん、すべてはKubernetesから始まります。Jeppsonのチームは、この技術でNavをスケール可能にするプラットフォームを構築しました。そして「これまで経験したことのない新たな自由、たくさんの価値をNavにもたらしてくれたのです。」と彼は言います。新製品を検討しようにも、隔離された環境を用意するのに6か月待たなければならず、その後もトラフィックが急上昇するのに対応するやりかたも考え出さなければならないという事実があり、身動きが取れなくなってしまっていました。「しかし、もうそういった話もなくなりました。」とJeppsonは言います。「今私たちが扱っているトラフィック量の4〜10倍が流れたとしても、『ああ、大丈夫だよ、Kubernetesがやってくれるから』と話しています。」
|
||||
|
||||
</div>
|
||||
</section>
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 4.1 KiB |
|
|
@ -40,7 +40,7 @@ css: /css/style_case_studies.css
|
|||
</section>
|
||||
<div class="banner2">
|
||||
<div class="banner2text">
|
||||
私たちは常にテクノロジーを通じて最適化してより大きな価値を提供する方法を探しています。Kubernetesを用いて私たちは開発効率と運用効率という2つの効率を示します。これは双方にとって好都合です。
|
||||
私たちは常に、技術の最適化を通じてより大きな価値を提供する方法を探しています。Kubernetesを用いて私たちは開発効率と運用効率という2つの効率を示します。これは双方にとって好都合です。
|
||||
<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>-Nordstrom社シニアエンジニア Dhawal Patel</span>
|
||||
</div>
|
||||
</div>
|
||||
|
|
|
|||
|
|
@ -26,22 +26,22 @@ logo: sos_featured_logo.png
|
|||
<div class="col1" style="width:100%"">
|
||||
<h2>課題</h2>
|
||||
SOS Internationalは60年にわたり、北欧諸国の顧客に信頼性の高い緊急医療および旅行支援を提供してきました。近年、同社のビジネス戦略では、デジタル分野での開発をさらに強化する必要がありましたが、ITシステムに関しては
|
||||
3つの従来のモノリス(Java, .NET, およびIBMのAS/400)とウォーターフォールアプローチにおいて「SOSには非常に断片化された遺産があります。」とエンタープライズアーキテクチャー責任者のMartin Ahrentsen氏は言います。「新しいテクノロジーと新しい働き方の両方を導入することを余儀なくされているので、市場投入までの時間を短縮して効率を高めることができました。それははるかに機敏なアプローチであり、私たちにはそれをビジネスに提供するのに役立つプラットフォームが必要でした。」
|
||||
3つの従来のモノリス(Java, .NET, およびIBMのAS/400)とウォーターフォールアプローチにおいて「SOSには非常に断片化された遺産があります。」とエンタープライズアーキテクチャー責任者のMartin Ahrentsen氏は言います。「新しい技術と新しい働き方の両方を導入することを余儀なくされているので、市場投入までの時間を短縮して効率を高めることができました。それははるかに機敏なアプローチであり、私たちにはそれをビジネスに提供するのに役立つプラットフォームが必要でした。」
|
||||
|
||||
|
||||
<br><br>
|
||||
<h2>ソリューション</h2>
|
||||
標準システムの模索に失敗した後、同社はプラットフォームアプローチを採用し、Kubernetesとコンテナテクノロジーを包含するソリューションを探すことにしました。<a href="https://www.openshift.com/">RedHat OpenShift</a>はSOSの断片化されたシステムに最適であることが証明されました。「私たちはコード言語とその他の両方を使用する多くの異なる技術を持っていますが、それらはすべて新しいプラットフォーム上のリソースを使用できます。」とAhrentsen氏は言います。同社の3つのモノリスのうち、「この最先端のテクノロジーを2つ(.NETとJava)に提供できます。」このプラットフォームは2018年春に公開されました。現在、マイクロサービスアーキテクチャーに基づく6つの未開発プロジェクトが進行中であり、さらに、同社のJavaアプリケーションはすべて「リフト&シフト」移行を行っています。
|
||||
標準システムの模索に失敗した後、同社はプラットフォームアプローチを採用し、Kubernetesとコンテナ技術を包含するソリューションを探すことにしました。<a href="https://www.openshift.com/">RedHat OpenShift</a>はSOSの断片化されたシステムに最適であることが証明されました。「私たちはコード言語とその他の両方を使用する多くの異なる技術を持っていますが、それらはすべて新しいプラットフォーム上のリソースを使用できます。」とAhrentsen氏は言います。同社にある3つのモノリスの中で、「2つ(.NETとJava)に対してこの最先端の技術を提供できます。」このプラットフォームは2018年春に公開されました。現在、マイクロサービスアーキテクチャーに基づく6つの未開発プロジェクトが進行中であり、さらに、同社のJavaアプリケーションはすべて「リフト&シフト」移行を行っています。
|
||||
<br><br>
|
||||
<h2>影響</h2>
|
||||
Kubernetesによって「市場投入までの時間、アジリティ、および変更と新しいテクノロジーに適応する能力の向上を実現しました。」とAhrentsen氏は語ります。「ソフトウェアのリリース準備ができてからリリースできるまでの時間が大幅に改善されました。」SOS Internationalの考え方も劇的に変わりました。「自動化、CI/CDパイプラインの作成を容易にするKubernetesとスクリプトへの簡単なアクセスがあるので、この完全自動化の方法に至る所で多くの内部的な関心が生まれています。旅を始めるために非常に良い気候を作り出しています。」と彼は言います。さらに、クラウドネイティブのコミュニティの一員であることは、同社が人材を引き付けるのに役立ちました。「彼らはクールで新しいテクノロジーを使いたいと思っています」とAhrentsen氏は言います。「新しいテクノロジーを提供したという理由でITプロフェッショナルが我が社を選んでいたことが新人研修の時にわかりました。」
|
||||
Kubernetesによって「市場投入までの時間、アジリティ、および変更と新しい技術に適応する能力の向上を実現しました。」とAhrentsen氏は語ります。「ソフトウェアのリリース準備ができてからリリースできるまでの時間が大幅に改善されました。」SOS Internationalの考え方も劇的に変わりました。「自動化、CI/CDパイプラインの作成を容易にするKubernetesとスクリプトへの簡単なアクセスがあるので、この完全自動化の方法に至る所で多くの内部的な関心が生まれています。旅を始めるために非常に良い気候を作り出しています。」と彼は言います。さらに、クラウドネイティブのコミュニティの一員であることは、同社が人材を引き付けるのに役立ちました。「彼らはクールで新しい技術を使いたいと思っています」とAhrentsen氏は言います。「ITプロフェッショナルが新しい技術を提供したという理由で我が社を選んでいたことが新人研修の時にわかりました。」
|
||||
</div>
|
||||
|
||||
</div>
|
||||
</section>
|
||||
<div class="banner2">
|
||||
<div class="banner2text">
|
||||
「クラウドネイティブソフトウェアとテクノロジーが現在推進している変化の速度は驚くべきものであり、それをフォローして採用することは私たちにとって非常に重要です。Kubernetesとクラウドネイティブが提供する驚くべき技術はデジタルの未来に向けてSOSに変化をもたらしました。
|
||||
「クラウドネイティブなソフトウェアや技術が現在推進している変化の速度は驚くべきものであり、それに追従して導入することは私たちにとって非常に重要です。Kubernetesとクラウドネイティブが提供する驚くべき技術はデジタルの未来に向けてSOSに変化をもたらしました。
|
||||
<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- SOS International エンタープライズアーキテクチャー責任者 Martin Ahrentsen</span>
|
||||
</div>
|
||||
</div>
|
||||
|
|
@ -49,16 +49,16 @@ logo: sos_featured_logo.png
|
|||
<div class="fullcol">
|
||||
<h2>SOS Internationalは60年にわたり、北欧諸国の顧客に信頼性の高い緊急医療および旅行支援を提供してきました。</h2>
|
||||
SOSのオペレータは年間100万件の案件を扱い、100万件以上の電話を処理しています。しかし、過去4年間で同社のビジネス戦略にデジタル空間でのますます激しい開発が必要になりました。<br><br>
|
||||
ITシステムに関していえば、会社のデータセンターで稼働する3つの伝統的なモノリスとウォーターフォールアプローチにおいて「SOSは非常に断片化された資産があります。」とエンタープライズアーキテクチャー責任者のMartin Ahrentsen氏は言います。「市場投入までの時間を短縮し、効率を高めるために新しいテクノロジーと新しい働き方の両方を導入する必要がありました。それははるかに機敏なアプローチであり、それをビジネスに提供するために役立つプラットフォームが必要でした。」
|
||||
ITシステムに関していえば、会社のデータセンターで稼働する3つの伝統的なモノリスとウォーターフォールアプローチにおいて「SOSは非常に断片化された資産があります。」とエンタープライズアーキテクチャー責任者のMartin Ahrentsen氏は言います。「市場投入までの時間を短縮し、効率を高めるために新しい技術と新しい働き方の両方を導入する必要がありました。それははるかに機敏なアプローチであり、それをビジネスに提供するために役立つプラットフォームが必要でした。」
|
||||
<br><br>
|
||||
Ahrentsen氏と彼のチームは長い間SOSで機能する標準のソリューションを探していました。「私たちのような支援会社はそれほど多くないので、それにふさわしい標準システムを入手することはできません。完全に一致するものがないのです。」と彼は言います。「標準システムを採用したとしても、あまりにもひねりすぎて、もはや標準ではないものになるでしょう。そのため、新しいデジタルシステムとコアシステムを構築するために使用できるいくつかの共通コンポーネントを備えたテクノロジープラットフォームを見つけることにしました。」
|
||||
Ahrentsen氏と彼のチームは長い間SOSで機能する標準のソリューションを探していました。「私たちのような支援会社はそれほど多くないので、それにふさわしい標準システムを入手することはできません。完全に一致するものがないのです。」と彼は言います。「標準システムを採用したとしても、あまりにもひねりすぎて、もはや標準ではないものになるでしょう。そのため、新しいデジタルシステムとコアシステムを構築するために使用できるいくつかの共通コンポーネントを備えた技術プラットフォームを見つけることにしました。」
|
||||
|
||||
|
||||
</div>
|
||||
</section>
|
||||
<div class="banner3" style="background-image: url('/images/CaseStudy_sos_banner3.jpg')">
|
||||
<div class="banner3text">
|
||||
「私たちは新しいデジタルサービスを提供しなければなりませんが、古いものも移行する必要があります。そして、コアシステムをこのプラットフォーム上に構築された新しいシステムに変換する必要があります。このテクノロジーを選んだ理由の1つは古いデジタルサービスを変更しながら新しいサービスを構築できるからです。」
|
||||
「私たちは新しいデジタルサービスを提供しなければなりませんが、古いものも移行する必要があります。そして、コアシステムをこのプラットフォーム上に構築された新しいシステムに変換する必要があります。この技術を選んだ理由の1つは古いデジタルサービスを変更しながら新しいサービスを構築できるからです。」
|
||||
|
||||
<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- SOS International エンタープライズアーキテクチャー責任者 Martin Ahrentsen</span>
|
||||
|
||||
|
|
@ -68,14 +68,14 @@ logo: sos_featured_logo.png
|
|||
<div class="fullcol">
|
||||
Kubernetesができることを理解すると、Ahrentsen氏はすぐにビジネスニーズを満たすことができるプラットフォームに目を向けました。同社はDockerコンテナとKubernetesを組み込んだRed HatのOpenShift Container Platformを採用しました。また、RedHat Hyperconverged Infrastructureや一部のミッドウェアコンポーネントなど、すべてオープンソースコミュニティで提供されている技術スタックも利用することを決めました。<br><br>
|
||||
|
||||
テクノロジーやアジリティの適合性、法的要件、およびコンピテンシーという同社の基準に基づくと、OpenShiftソリューションはSOSの断片化されたシステムに完全に適合するように思われました。「私たちはコード言語とそれ以外の両方を使用する多くの異なる技術を持っています。それらはすべて新しいプラットフォーム上のリソースを使用できます。」とAhrentsen氏は言います。同社の3つのモノリスのうち、「この最先端のテクノロジーを2つ(.NETとJava)に提供できます。」<br><br>
|
||||
技術やアジリティの適合性、法的要件、およびコンピテンシーという同社の基準に基づくと、OpenShiftソリューションはSOSの断片化されたシステムに完全に適合するように思われました。「私たちはコード言語とそれ以外の両方を使用する多くの異なる技術を持っています。それらはすべて新しいプラットフォーム上のリソースを使用できます。」とAhrentsen氏は言います。同社にある3つのモノリスの中で、「2つ(.NETとJava)に対してこの最先端の技術を提供できます。」<br><br>
|
||||
|
||||
プラットフォームは2018年春に公開されました。マイクロサービスアーキテクチャーに基づく6つの未開発のプロジェクトが最初に開始されました。さらに、同社のJavaアプリケーションはすべて「リフト&シフト」移行を行っています。最初に稼働しているKubernetesベースのプロジェクトの一つがRemote Medical Treatmentです。これは顧客が音声、チャット、ビデオを介してSOSアラームセンターに連絡できるソリューションです。「完全なCI/CDパイプラインと最新のマイクロサービスアーキテクチャーをすべて2つのOpenShiftクラスターセットアップで実行することに焦点を当てて、非常に短時間で開発できました。」とAhrentsen氏は言います。北欧諸国へのレスキュートラックの派遣に使用されるOnsite、および、レッカー車の追跡を可能にするFollow Your Truckも展開されています。
|
||||
</div>
|
||||
</section>
|
||||
<div class="banner4" style="background-image: url('/images/CaseStudy_sos_banner4.jpg');width:100%">
|
||||
<div class="banner4text">
|
||||
「新しいテクノロジーを提供したという理由でITプロフェッショナルが我が社を選んでいたことが新人研修の時にわかりました。」
|
||||
「ITプロフェッショナルが新しい技術を提供したという理由で我が社を選んでいたことが新人研修の時にわかりました。」
|
||||
<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- SOS International エンタープライズアーキテクチャー責任者 Martin Ahrentsen</span>
|
||||
</div>
|
||||
</div>
|
||||
|
|
@ -84,11 +84,11 @@ logo: sos_featured_logo.png
|
|||
<div class="fullcol">
|
||||
プラットフォームがまだオンプレミスで稼働しているのは、保険業界のSOSの顧客の一部は同社がデータを処理しているためまだクラウド戦略を持っていないためです。KubernetesはSOSがデータセンターで開始し、ビジネスの準備ができたらクラウドに移行できるようにします。「今後3～5年にわたって、彼らすべてが戦略を持ち、そして、データを取り出してクラウドに移行できるでしょう。」とAhrentsen氏は言います。機密データと非機密データのハイブリッドクラウド設定に移行する可能性もあります。<br><br>
|
||||
|
||||
SOSの技術は確かに過渡期にあります。「新しいデジタルサービスを提供する必要がありますが、古いものも移行する必要があり、コアシステムをこのプラットフォーム上に構築された新しいシステムに変換しなければなりません。」とAhrentsen氏は言います。「このテクノロジーを選んだ理由の1つは古いデジタルサービスを変更しながら新しいサービスを構築できるからです。」<br><br>
|
||||
SOSの技術は確かに過渡期にあります。「新しいデジタルサービスを提供する必要がありますが、古いものも移行する必要があり、コアシステムをこのプラットフォーム上に構築された新しいシステムに変換しなければなりません。」とAhrentsen氏は言います。「この技術を選んだ理由の1つは古いデジタルサービスを変更しながら新しいサービスを構築できるからです。」<br><br>
|
||||
|
||||
しかし、Kubernetesはすでに市場投入までの時間を短縮しており、そのことは、新興プロジェクトがいかに迅速に開発され、リリースされたかにも表れています。「ソフトウェアのリリース準備ができてからリリース可能になるまでの時間は劇的に改善されました。」とAhrentsen氏は言います。<br><br>
|
||||
|
||||
さらに、クラウドネイティブのコミュニティの一員であることは、エンジニア、オペレーター、アーキテクトの数を今年60から100に増やすという目標を追求するうえで、同社が人材を引き付けるのに役立ちました。「彼らはクールで新しいテクノロジーを使いたいと思っています。」とAhrentsenは言います。「新しいテクノロジーを提供したという理由でITプロフェッショナルが我が社を選んでいたことが新人研修の時にわかりました。」
|
||||
さらに、クラウドネイティブのコミュニティの一員であることは、エンジニア、オペレーター、アーキテクトの数を今年60から100に増やすという目標を追求するうえで、同社が人材を引き付けるのに役立ちました。「彼らはクールで新しい技術を使いたいと思っています。」とAhrentsenは言います。「ITプロフェッショナルが新しい技術を提供したという理由で我が社を選んでいたことが新人研修の時にわかりました。」
|
||||
|
||||
</div>
|
||||
|
||||
|
|
@ -105,6 +105,6 @@ logo: sos_featured_logo.png
|
|||
|
||||
代表例：自動車へのIoTの導入。欧州委員会は現在、すべての新車にeCallを装備することを義務づけています。eCallは重大な交通事故が発生した場合に位置やその他データを送信します。SOSはこのサービスをスマート自動支援として提供しています。「電話を受けて、緊急対応チームを派遣する必要があるかどうか、またはそれほど大きな影響がないどうかを確認します。」とAhrentsen氏は言います。「すべてが接続され、データを送信する未来の世界は、新しい市場機会という点で私たちにとって大きな可能性を生み出します。しかし、それはまたITプラットフォームと私たちが提供すべきものに大きな需要をもたらすでしょう。」<br><br>
|
||||
|
||||
Ahrentsen氏はSOSが技術の選択を行ってきたことを考えると、この課題に十分対応できると感じています。「クラウドネイティブソフトウェアとテクノロジーが現在推進している変化の速度は驚くべきものであり、それに追従して採用することは私たちにとって非常に重要です。」と彼は言います。「Kubernetesとクラウドネイティブが提供する驚くべきテクノロジーは、デジタルの未来に向けてSOSに変化をもたらし始めました。」
|
||||
Ahrentsen氏はSOSが技術の選択を行ってきたことを考えると、この課題に十分対応できると感じています。「クラウドネイティブなソフトウェアや技術が現在推進している変化の速度は驚くべきものであり、それに追従して採用することは私たちにとって非常に重要です。」と彼は言います。「Kubernetesとクラウドネイティブが提供する驚くべき技術は、デジタルの未来に向けてSOSに変化をもたらし始めました。」
|
||||
</div>
|
||||
</section>
|
||||
|
|
|
|||
|
|
@ -0,0 +1,120 @@
|
|||
---
|
||||
title: Spotifyケーススタディ
|
||||
linkTitle: Spotify
|
||||
case_study_styles: true
|
||||
cid: caseStudies
|
||||
css: /css/style_case_studies.css
|
||||
logo: spotify_featured_logo.png
|
||||
featured: true
|
||||
weight: 2
|
||||
quote: >
|
||||
Kubernetesを中心に成長した素晴らしいコミュニティを見て、その一部になりたかったのです。スピードの向上とコスト削減のメリットを享受し、ベストプラクティスとツールについて業界の他の企業と連携したいとも思いました。
|
||||
---
|
||||
|
||||
<div class="banner1" style="background-image: url('/images/CaseStudy_spotify_banner1.jpg')">
|
||||
<h1> ケーススタディ：Spotify<br> <div class="subhead" style="margin-top:1%">Spotify：コンテナ技術のアーリーアダプターであるSpotifyは自社製オーケストレーションツールからKubernetesに移行しています
|
||||
|
||||
</div></h1>
|
||||
|
||||
</div>
|
||||
|
||||
<div class="details">
|
||||
企業名 <b>Spotify</b> 所在地 <b>グローバル</b> 業界 <b>エンターテイメント</b>
|
||||
</div>
|
||||
|
||||
<hr>
|
||||
<section class="section1">
|
||||
<div class="cols">
|
||||
<div class="col1" style="width:100%">
|
||||
<h2>課題</h2>
|
||||
2008年から始まったオーディオストリーミングプラットフォームは、アクティブユーザーが世界中で毎月2億人を超えるまでに成長しました。「私たちの目標は、クリエイターたちに力を与え、私たちが現在抱えるすべての消費者、そして願わくば将来抱える消費者が真に没入できる音楽体験を実現することです」、エンジニアリング、インフラおよびオペレーション担当ディレクターのJai Chakrabartiは、こう言います。マイクロサービスとDockerのアーリーアダプターであるSpotifyは、<a href="https://github.com/spotify/helios">Helios</a>という自社開発のコンテナオーケストレーションシステムを使い、自社のVM全体にわたり実行されるマイクロサービスをコンテナ化していました。2017年末までには、「こういった機能開発に自社の小さなチームで取り組むことは効率的ではなく、大きなコミュニティで支持されているものを採用したほうがよい」ことがはっきりしてきました。
|
||||
|
||||
<br><br>
|
||||
<h2>ソリューション</h2>
|
||||
「Kubernetesを中心に成長した素晴らしいコミュニティを見て、その一部になりたかったのです。」とChakrabartiは言います。KubernetesはHeliosよりも豊富な機能を有していました。さらに、「スピードの向上とコスト削減のメリットを享受し、ベストプラクティスとツールについて業界の他の企業と連携したいとも思いました。」また彼のチームは、活発なKubernetesコミュニティにその知見でコントリビュートし、影響を与えることも望みました。Heliosの稼働と並行して行われたマイグレーションは、スムーズにすすめることができました。それは「KubernetesがHeliosを補完するものとして、そして今はHeliosを代替するものとして非常にフィットしたものだったからです」とChakrabartiは言います。
|
||||
|
||||
<h2>インパクト</h2>
|
||||
2018年の後半に始まり、2019年に向けて大きな注力点となる本マイグレーションにおいて必要となる主要な技術の問題に対応するため、チームは2018年の大半を費やしました。「ほんの一部をKubernetesに移行したのですが、社内チームから聞こえてきたのは、手作業でのキャパシティプロビジョニングを意識する必要性が少なくなり、Spotifyとしての機能の提供に集中できる時間がより多くなってきたということです」とChakrabartiは言います。Kubernetesで現在実行されている最も大きなサービスはアグリゲーションサービスで、1秒あたり約1000万リクエストを受け取り、オートスケールによる大きな恩恵を受けている、とサイト・リライアビリティ・エンジニアのJames Wenは言います。さらに、「以前はチームが新しいサービスを作り、運用ホストを本番環境で稼働させるために1時間待たなければなりませんでしたが、Kubernetesでは秒・分のオーダーでそれを実現できます」と付け加えます。さらに、Kubernetesのビンパッキング（組み合わせ最適化）機能やマルチテナント機能により、CPU使用率が平均して2〜3倍向上しました。
|
||||
|
||||
</div>
|
||||
</div>
|
||||
</section>
|
||||
<div class="banner2">
|
||||
<div class="banner2text">
|
||||
「Kubernetesを中心に成長した素晴らしいコミュニティを見て、その一部になりたかったのです。スピードの向上とコスト削減のメリットを享受し、ベストプラクティスとツールについて業界の他の企業と連携したいとも思いました。」 <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Spotify エンジニアリング、インフラおよびオペレーション担当ディレクター、Jai Chakrabarti</span>
|
||||
</div>
|
||||
</div>
|
||||
<section class="section2">
|
||||
<div class="fullcol">
|
||||
<h2>「私たちのゴールは、クリエイターたちに力を与え、今・これからの消費者が真に没入できる音楽体験を実現することです。」Spotifyのエンジニアリング、インフラストラクチャおよびオペレーション担当ディレクター、Jai Chakrabartiは、このように述べています。
|
||||
2008年から始まったオーディオストリーミングプラットフォームは、アクティブユーザーが世界中で毎月2億人を超えるまでに成長しました。Chakrabartiのチームにとってのゴールは、将来のすべての消費者もサポートするべくSpotifyのインフラを強固なものにしていくことです。</h2>
|
||||
|
||||
<br><br>
|
||||
マイクロサービスとDockerのアーリーアダプターであるSpotifyは、自社のVM全体にわたり実行されるマイクロサービスをコンテナ化していました。同社は「Helios」というオープンソースの自社製コンテナオーケストレーションシステムを使用し、2016年から17年にかけてオンプレミスのデータセンターからGoogle Cloudへの移行を完了しました。こういった意思決定の「我々にはさまざまなピースに取り組む、すばやく繰り返す作業を必要とする自律的なエンジニアリングチームが200以上あり、彼らを中心とした文化があります」とChakrabartiは言います。「したがって、チームがすばやく動けるようになる開発者のベロシティツールを持つことが非常に大事です。」<br><br>しかし、2017年の終わりまでには、「小さなチームが<a href="https://github.com/spotify/helios">Helios</a>の機能に取り組むのは、それよりもはるかに大きなコミュニティで支持されているものと比べると効率的ではない」ことが明らかになった、とChakrabartiは言います。「Kubernetesを取り巻き成長した驚くべきコミュニティを見ました。その一員になりたいと思いました。スピードの向上とコストの削減による恩恵を受けたかったですし、ベストプラクティスとツールをもつ他の業界と連携したいとも思いました。」同時にこのチームは、活発なKubernetesコミュニティにその知見でコントリビュートし、影響を与えることも望みました。
|
||||
|
||||
|
||||
</div>
|
||||
</section>
|
||||
<div class="banner3" style="background-image: url('/images/CaseStudy_spotify_banner3.jpg')">
|
||||
<div class="banner3text">
|
||||
「このコミュニティは、あらゆる技術への取り組みをより速く、より容易にしてくれることを強力に助けてくれました。そして、私たちの取り組みのすべてを検証することも助けてくれました。」 <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Spotify ソフトウェアエンジニア、インフラおよびオペレーション担当、Dave Zolotusky</span>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<section class="section3">
|
||||
<div class="fullcol">
|
||||
もう1つのプラス：「KubernetesがHeliosを補完するものとして、そして今はHeliosを代替するものとして非常にフィットしたものだったので、リスク軽減のためにHeliosと同時に稼働させることができました」とChakrabartiは言います。「マイグレーションの最中はサービスが両方の環境で実行されるので、さまざまな負荷・ストレス環境下でKubernetesの有効性を確認できるようになるまではすべての卵を1つのバスケットに入れる必要がありません。」
|
||||
|
||||
<br><br>
|
||||
|
||||
チームは、本マイグレーションにおいて必要となる主要な技術の問題に対応するため、チームは2018年の大半を費やしました。「レガシーのインフラをサポートしたり連携するKubernetes APIやKubernetesの拡張性機能を多く使うことができたので、インテグレーションはシンプルで簡単なものでした」とサイト・リライアビリティ・エンジニアのJames Wenは言います。
|
||||
|
||||
<br><br>
|
||||
マイグレーションはその年の後半に始まり、2019年に加速しました。「私たちはステートレスなサービスに注力しています。最後に残る技術的課題を突破したら、それが上昇をもたらしてくれると期待しています」とChakrabartiは言います。「ステートフルサービスについては、より多くのやるべきことがあります。」
|
||||
<br><br>
|
||||
今のところ、Spotifyの150を超えるサービスのごく一部がKubernetesに移行されています。
|
||||
|
||||
「社内のチームから聞こえてきたのは、手作業でのキャパシティプロビジョニングを意識する必要性が少なくなり、Spotifyとしての機能の提供に集中できる時間がより多くなってきたということです」とChakrabartiは言います。
|
||||
|
||||
Kubernetesで現在実行されている最も大きなサービスはアグリゲーションサービスで、1秒あたり約1000万リクエストを受け取り、オートスケールによる大きな恩恵を受けている、とWenは言います。さらに、「以前はチームが新しいサービスを作り、運用ホストを本番環境で稼働させるために1時間待たなければなりませんでしたが、Kubernetesでは秒・分のオーダーでそれを実現できます」と付け加えます。さらに、Kubernetesのビンパッキング（組み合わせ最適化）機能やマルチテナント機能により、CPU使用率が平均して2〜3倍向上しました。
|
||||
|
||||
|
||||
</div>
|
||||
</section>
|
||||
<div class="banner4" style="background-image: url('/images/CaseStudy_spotify_banner4.jpg')">
|
||||
<div class="banner4text">
|
||||
「レガシーのインフラをサポートしたり連携するKubernetes APIやKubernetesの拡張性機能をたくさん使うことができたので、インテグレーションはシンプルで簡単なものでした」<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Spotify、Spotifyエンジニア、James Wen</span>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<section class="section5" style="padding:0px !important">
|
||||
<div class="fullcol">
|
||||
Chakrabartiは、Spotifyが見ている4つのトップレベルのメトリック - リードタイム、デプロイ頻度、修復時間、そして運用負荷 - のすべてについて「Kubernetesがインパクトを与えている」と指摘します。
|
||||
<br><br>
|
||||
Kubernetesが初期の頃に出てきたサクセスストーリーの1つに、SpotifyチームがKubernetesの上に構築したSlingshotというツールがあります。「プルリクエストを出すと、24時間後に自己消滅する一時的なステージング環境を生成します」とChakrabartiは言います。「これはすべてKubernetesがやってくれています。新しいテクノロジーが出てきて使えるようになったときに、自分のイメージを超えるようなソリューションをいかにしてこの環境上で作っていくか、そのやり方を示す刺激的な例だと思います。」
|
||||
<br><br>
|
||||
またSpotifyは<a href="https://grpc.io/">gRPC</a>と<a href="https://www.envoyproxy.io/">envoy</a>を使い、Kubernetesと同じように、既存の自社製ソリューションを置き換え始めました。「私たちはその時の自分たちの規模を理由にした開発をしていて、実際に他のソリューションはありませんでした」とインフラおよび運用担当のソフトウェアエンジニアであるDave Zolotuskyは言います。「しかし、そういった規模感のツールですらコミュニティは私たちに追いつき、追い越して行きました。」
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
<div class="banner5" >
|
||||
<div class="banner5text">
|
||||
「私たちが取り組んでいることに関する専門知識を得るために、コンタクトしたい人と連絡を取るのは驚くほど簡単でした。そして、私たちが行っていたすべての検証で役立ちました」 <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Spotify、サイト・リライアビリティ・エンジニア、James Wen</span></div>
|
||||
</div>
|
||||
|
||||
|
||||
<div class="fullcol">
|
||||
どちらの技術も採用するには初期段階ではありますが、「gRPCはスキーマ管理、API設計、下位互換の問題など、初期の開発段階における多くの問題に対してより劇的な影響を与えると確信しています」とZolotuskyは言います。「そのため、そういった領域でgRPCに傾倒しています。」
|
||||
|
||||
<br><br>
|
||||
チームはSpotifyのクラウドネイティブなスタックを拡大し続けており - この次にあるのはスタックトレーシングです - CNCFランドスケープを有用なガイドとして活用しています。「解決する必要があるものを見たときに、もし多数のプロジェクトがあればそれらを同じように評価しますが、そのプロジェクトがCNCFプロジェクトであることには間違いなく価値があります」とZolotuskyは言います。
|
||||
|
||||
<br><br>
|
||||
SpotifyがKubernetesでこれまでに経験してきたことはそれを裏付けています。「あらゆる技術により速くより簡単に取り組めるようになる点で、このコミュニティは極めて有益です」とZolotuskyは言います。「私たちが取り組んでいることに関する専門知識を得るために、コンタクトしたい人と連絡を取るのは驚くほど簡単でした。そして、私たちが行っていたすべての検証で役立ちました。」
|
||||
|
||||
|
||||
</div>
|
||||
</section>
|
||||
</body>
|
||||
</html>
|
||||
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 5.0 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 6.2 KiB |
|
|
@ -7,7 +7,7 @@ weight: 40
|
|||
|
||||
{{% capture overview %}}
|
||||
|
||||
本セクションは、Kubernetesシステムの各パートと、クラスターを表現するためにKubernetesが使用する抽象概念について学習し、Kubernetesの仕組みをより深く理解するのに役立ちます。
|
||||
本セクションは、Kubernetesシステムの各パートと、{{< glossary_tooltip text="クラスター" term_id="cluster" length="all" >}}を表現するためにKubernetesが使用する抽象概念について学習し、Kubernetesの仕組みをより深く理解するのに役立ちます。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
|
@ -17,7 +17,7 @@ weight: 40
|
|||
|
||||
Kubernetesを機能させるには、*Kubernetes API オブジェクト* を使用して、実行したいアプリケーションやその他のワークロード、使用するコンテナイメージ、レプリカ(複製)の数、どんなネットワークやディスクリソースを利用可能にするかなど、クラスターの *desired state* (望ましい状態)を記述します。desired sate (望ましい状態)をセットするには、Kubernetes APIを使用してオブジェクトを作成します。通常はコマンドラインインターフェイス `kubectl` を用いてKubernetes APIを操作しますが、Kubernetes APIを直接使用してクラスターと対話し、desired state (望ましい状態)を設定、または変更することもできます。
|
||||
|
||||
一旦desired state (望ましい状態)を設定すると、*Kubernetes コントロールプレーン* が働き、クラスターの現在の状態をdesired state (望ましい状態)に一致させます。そのためにKubernetesはさまざまなタスク(たとえば、コンテナの起動または再起動、特定アプリケーションのレプリカ数のスケーリング等)を自動的に実行します。Kubernetesコントロールプレーンは、クラスターで実行されている以下のプロセスで構成されています。
|
||||
一旦desired state (望ましい状態)を設定すると、Pod Lifecycle Event Generator([PLEG](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/pod-lifecycle-event-generator.md))を使用した*Kubernetes コントロールプレーン*が機能し、クラスターの現在の状態をdesired state (望ましい状態)に一致させます。そのためにKubernetesはさまざまなタスク(たとえば、コンテナの起動または再起動、特定アプリケーションのレプリカ数のスケーリング等)を自動的に実行します。Kubernetesコントロールプレーンは、クラスターで実行されている以下のプロセスで構成されています。
|
||||
|
||||
* **Kubernetes Master** :[kube-apiserver](/docs/admin/kube-apiserver/)、[kube-controller-manager](/docs/admin/kube-controller-manager/)、[kube-scheduler](/docs/admin/kube-scheduler/) の3プロセスの集合です。これらのプロセスはクラスター内の一つのノード上で実行されます。実行ノードはマスターノードとして指定します。
|
||||
* クラスター内の個々の非マスターノードは、それぞれ2つのプロセスを実行します。
|
||||
|
|
@ -26,7 +26,7 @@ Kubernetesを機能させるには、*Kubernetes API オブジェクト* を使
|
|||
|
||||
## Kubernetesオブジェクト
|
||||
|
||||
Kubernetesには、デプロイ済みのコンテナ化されたアプリケーションやワークロード、関連するネットワークとディスクリソース、クラスターが何をしているかに関するその他の情報といった、システムの状態を表現する抽象が含まれています。これらの抽象は、Kubernetes APIのオブジェクトによって表現されます。詳細については、[Kubernetesオブジェクト概要](/docs/concepts/abstractions/overview/) をご覧ください。
|
||||
Kubernetesには、デプロイ済みのコンテナ化されたアプリケーションやワークロード、関連するネットワークとディスクリソース、クラスターが何をしているかに関するその他の情報といった、システムの状態を表現する抽象が含まれています。これらの抽象は、Kubernetes APIのオブジェクトによって表現されます。詳細については、[Kubernetesオブジェクトについて知る](/docs/concepts/overview/working-with-objects/kubernetes-objects/)をご覧ください。
|
||||
|
||||
基本的なKubernetesのオブジェクトは次のとおりです。
|
||||
|
||||
|
|
@ -35,19 +35,19 @@ Kubernetesには、デプロイ済みのコンテナ化されたアプリケー
|
|||
* [Volume](/docs/concepts/storage/volumes/)
|
||||
* [Namespace](/ja/docs/concepts/overview/working-with-objects/namespaces/)
|
||||
|
||||
上記に加え、Kubernetesにはコントローラーと呼ばれる多くの高レベルの抽象概念が含まれています。コントローラーは基本オブジェクトに基づいて構築され、以下のような追加の機能と便利な機能を提供します。
|
||||
Kubernetesには、[コントローラー](/docs/concepts/architecture/controller/)に依存して基本オブジェクトを構築し、追加の機能と便利な機能を提供する高レベルの抽象化も含まれています。これらには以下のものを含みます:
|
||||
|
||||
* [ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)
|
||||
* [Deployment](/docs/concepts/workloads/controllers/deployment/)
|
||||
* [StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/)
|
||||
* [Deployment](/ja/docs/concepts/workloads/controllers/deployment/)
|
||||
* [DaemonSet](/ja/docs/concepts/workloads/controllers/daemonset/)
|
||||
* [StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/)
|
||||
* [ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)
|
||||
* [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)
|
||||
|
||||
## Kubernetesコントロールプレーン
|
||||
|
||||
Kubernetesマスターや kubeletプロセスといったKubernetesコントロールプレーンのさまざまなパーツは、Kubernetesがクラスターとどのように通信するかを統制します。コントロールプレーンはシステム内のすべてのKubernetesオブジェクトの記録を保持し、それらのオブジェクトの状態を管理するために継続的制御ループを実行します。コントロールプレーンの制御ループは常にクラスターの変更に反応し、システム内のすべてのオブジェクトの実際の状態が、指定した状態に一致するように動作します。
|
||||
|
||||
たとえば、Kubernetes APIを使用してDeploymentオブジェクトを作成する場合、システムには新しいdesired state (望ましい状態)が提供されます。Kubernetesコントロールプレーンは、そのオブジェクトの作成を記録します。そして、要求されたアプリケーションの開始、およびクラスターノードへのスケジューリングにより指示を完遂します。このようにしてクラスターの実際の状態を望ましい状態に一致させます。
|
||||
たとえば、Kubernetes APIを使用してDeploymentを作成する場合、システムには新しいdesired state (望ましい状態)が提供されます。Kubernetesコントロールプレーンは、そのオブジェクトの作成を記録します。そして、要求されたアプリケーションの開始、およびクラスターノードへのスケジューリングにより指示を完遂します。このようにしてクラスターの実際の状態を望ましい状態に一致させます。
|
||||
|
||||
### Kubernetesマスター
|
||||
|
||||
|
|
@ -59,11 +59,6 @@ Kubernetesのマスターは、クラスターの望ましい状態を維持す
|
|||
|
||||
クラスターのノードは、アプリケーションとクラウドワークフローを実行するマシン(VM、物理サーバーなど)です。Kubernetesのマスターは各ノードを制御します。運用者自身がノードと直接対話することはほとんどありません。
|
||||
|
||||
#### オブジェクトメタデータ
|
||||
|
||||
|
||||
* [Annotations](/ja/docs/concepts/overview/working-with-objects/annotations/)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
---
|
||||
title: "Kubernetes アーキテクチャー"
|
||||
title: "Kubernetesのアーキテクチャー"
|
||||
weight: 30
|
||||
---
|
||||
|
|
|
|||
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
title: "クラスターの管理"
|
||||
weight: 100
|
||||
---
|
||||
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
title: "設定"
|
||||
weight: 80
|
||||
---
|
||||
|
||||
|
|
@ -1,5 +1,4 @@
|
|||
---
|
||||
title: "Containers"
|
||||
title: "コンテナ"
|
||||
weight: 40
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,223 @@
|
|||
---
|
||||
title: カスタムリソース
|
||||
content_template: templates/concept
|
||||
weight: 20
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
*カスタムリソース* はKubernetes APIの拡張です。このページでは、いつKubernetesのクラスターにカスタムリソースを追加するべきなのか、そしていつスタンドアローンのサービスを利用するべきなのかを議論します。カスタムリソースを追加する2つの方法と、それらの選択方法について説明します。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## カスタムリソース
|
||||
|
||||
*リソース* は、[Kubernetes API](/docs/reference/using-api/api-overview/)のエンドポイントで、特定の[APIオブジェクト](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/)のコレクションを保持します。例えば、ビルトインの *Pods* リソースは、Podオブジェクトのコレクションを包含しています。
|
||||
|
||||
*カスタムリソース* は、Kubernetes APIの拡張で、デフォルトのKubernetesインストールでは、必ずしも利用できるとは限りません。つまりそれは、特定のKubernetesインストールのカスタマイズを表します。しかし、今現在、多数のKubernetesのコア機能は、カスタムリソースを用いて作られており、Kubernetesをモジュール化しています。
|
||||
|
||||
カスタムリソースは、稼働しているクラスターに動的に登録され、現れたり、消えたりし、クラスター管理者はクラスター自体とは無関係にカスタムリソースを更新できます。一度、カスタムリソースがインストールされると、ユーザーは[kubectl](/docs/user-guide/kubectl-overview/)を使い、ビルトインのリソースである *Pods* と同じように、オブジェクトを作成、アクセスすることが可能です。
|
||||
|
||||
## カスタムコントローラー
|
||||
|
||||
カスタムリソースそれ自身は、単純に構造化データを格納、取り出す機能を提供します。カスタムリソースを *カスタムコントローラー* と組み合わせることで、カスタムリソースは真の _宣言的API_ を提供します。
|
||||
|
||||
[宣言的API](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetesオブジェクトを理解する)は、リソースのあるべき状態を _宣言_ または指定することを可能にし、Kubernetesオブジェクトの現在の状態を、あるべき状態に同期し続けるように動きます。
|
||||
コントローラーは、構造化データをユーザーが指定したあるべき状態と解釈し、その状態を管理し続けます。
|
||||
|
||||
稼働しているクラスターのライフサイクルとは無関係に、カスタムコントローラーをデプロイ、更新することが可能です。カスタムコントローラーはあらゆるリソースと連携できますが、カスタムリソースと組み合わせると特に効果を発揮します。[オペレーターパターン](https://coreos.com/blog/introducing-operators.html)は、カスタムリソースとカスタムコントローラーの組み合わせです。カスタムコントローラーにより、特定アプリケーションのドメイン知識を、Kubernetes APIの拡張に変換することができます。
|
||||
|
||||
## カスタムリソースをクラスターに追加するべきか？
|
||||
|
||||
新しいAPIを作る場合、[APIをKubernetesクラスターAPIにアグリゲート(集約)する](/ja/docs/concepts/api-extension/apiserver-aggregation/)か、もしくはAPIをスタンドアローンで動かすかを検討します。
|
||||
|
||||
| APIアグリゲーションを使う場合: | スタンドアローンAPIを使う場合: |
|
||||
| ------------------------------ | ---------------------------- |
|
||||
| APIが[宣言的](#宣言的API) | APIが[宣言的](#宣言的API)モデルに適さない |
|
||||
| 新しいリソースを`kubectl`を使い読み込み、書き込みしたい| `kubectl`のサポートは必要ない |
|
||||
| 新しいリソースをダッシュボードのような、Kubernetes UIで他のビルトインリソースと同じように管理したい | Kubernetes UIのサポートは必要ない |
|
||||
| 新しいAPIを開発している | APIを提供し、適切に機能するプログラムが既に存在している |
|
||||
| APIグループ、名前空間というような、RESTリソースパスに割り当てられた、Kubernetesのフォーマット仕様の制限を許容できる([API概要](/ja/docs/concepts/overview/kubernetes-api/)を参照) | 既に定義済みのREST APIと互換性を持っていなければならない |
|
||||
| リソースはクラスターごとか、クラスター内の名前空間に自然に分けることができる | クラスター、または名前空間による分割がリソース管理に適さない。特定のリソースパスに基づいて管理したい |
|
||||
| [Kubernetes APIサポート機能](#一般的な機能)を再利用したい | これらの機能は必要ない |
|
||||
|
||||
### 宣言的API
|
||||
|
||||
宣言的APIは、通常、下記に該当します:
|
||||
|
||||
- APIは、比較的少数の、比較的小さなオブジェクト(リソース)で構成されている
|
||||
- オブジェクトは、アプリケーションの設定、インフラストラクチャーを定義する
|
||||
- オブジェクトは、比較的更新頻度が低い
|
||||
- 人は、オブジェクトの情報をよく読み書きする
|
||||
- オブジェクトに対する主要な手続きは、CRUD(作成、読み込み、更新、削除)になる
|
||||
- 複数オブジェクトをまたいだトランザクションは必要ない: APIは今現在の状態ではなく、あるべき状態を表現する
|
||||
|
||||
命令的APIは、宣言的ではありません。
|
||||
APIが宣言的ではない兆候として、次のものがあります:
|
||||
|
||||
- クライアントから"これを実行"と命令がきて、完了の返答を同期的に受け取る
|
||||
- クライアントから"これを実行"と命令がきて、処理IDを取得する。そして処理が完了したかどうかを、処理IDを利用して別途問い合わせる
|
||||
- リモートプロシージャコール(RPC)という言葉が飛び交っている
|
||||
- 直接、大量のデータを格納している(例、1オブジェクトあたり数kBより大きい、または数千オブジェクトより多い)
|
||||
- 高帯域アクセス(持続的に毎秒数十リクエスト)が必要
|
||||
- エンドユーザーのデータ(画像、PII、その他)を格納している、またはアプリケーションが処理する大量のデータを格納している
|
||||
- オブジェクトに対する処理が、CRUDではない
|
||||
- APIをオブジェクトとして簡単に表現できない
|
||||
- 停止している処理を処理ID、もしくは処理オブジェクトで表現することを選択している
|
||||
|
||||
## ConfigMapとカスタムリソースのどちらを使うべきか?
|
||||
|
||||
下記のいずれかに該当する場合は、ConfigMapを使ってください:
|
||||
|
||||
* `mysql.cnf`、`pom.xml`のような、十分に文書化された設定ファイルフォーマットが既に存在している
|
||||
* 単一キーのConfigMapに、設定ファイルの内容の全てを格納している
|
||||
* 設定ファイルの主な用途は、クラスター上のPodで実行されているプログラムがファイルを読み込み、それ自体を構成することである
|
||||
* ファイルの利用者は、Kubernetes APIよりも、Pod内のファイルまたはPod内の環境変数を介して利用することを好む
|
||||
* ファイルが更新されたときに、Deploymentなどを介してローリングアップデートを行いたい
|
||||
|
||||
{{< note >}}
|
||||
センシティブなデータには、ConfigMapに類似していますがよりセキュアな[secret](/docs/concepts/configuration/secret/)を使ってください
|
||||
{{< /note >}}
|
||||
|
||||
下記のほとんどに該当する場合、カスタムリソース(CRD、またはアグリゲートAPI)を使ってください:
|
||||
|
||||
* 新しいリソースを作成、更新するために、Kubernetesのクライアントライブラリー、CLIを使いたい
|
||||
* kubectlのトップレベルサポートが欲しい(例、`kubectl get my-object object-name`)
|
||||
* 新しい自動化の仕組みを作り、新しいオブジェクトの更新をウォッチしたい、その更新を契機に他のオブジェクトのCRUDを実行したい、またはその逆を行いたい
|
||||
* オブジェクトの更新を取り扱う、自動化の仕組みを書きたい
|
||||
* `.spec`、`.status`、`.metadata`というような、Kubernetes APIの慣習を使いたい
|
||||
* オブジェクトは、制御されたリソースコレクションの抽象化、または他のリソースのサマリーとしたい
|
||||
|
||||
## カスタムリソースを追加する
|
||||
|
||||
Kubernetesは、クラスターへカスタムリソースを追加する2つの方法を提供しています:
|
||||
|
||||
- CRDはシンプルで、プログラミングなしに作成可能
|
||||
- [APIアグリゲーション](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)は、プログラミングが必要だが、データがどのように格納され、APIバージョン間でどのように変換されるかというような、より詳細なAPIの振る舞いを制御できる
|
||||
|
||||
Kubernetesは、さまざまなユーザーのニーズを満たすためにこれら2つのオプションを提供しており、使いやすさや柔軟性が損なわれることはありません。
|
||||
|
||||
アグリゲートAPIは、プロキシーとして機能するプライマリAPIサーバーの背後にある、下位のAPIServerです。このような配置は[APIアグリゲーション](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) (AA)と呼ばれています。ユーザーにとっては、単にAPIサーバーが拡張されているように見えます。
|
||||
|
||||
CRDでは、APIサーバーの追加なしに、ユーザーが新しい種類のリソースを作成できます。CRDを使うには、APIアグリゲーションを理解する必要はありません。
|
||||
|
||||
どのようにインストールされたかに関わらず、新しいリソースはカスタムリソースとして参照され、ビルトインのKubernetesリソース(Podなど)とは区別されます。
|
||||
|
||||
## CustomResourceDefinition
|
||||
|
||||
[CustomResourceDefinition](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)APIリソースは、カスタムリソースを定義します。CRDオブジェクトを定義することで、指定した名前、スキーマで新しいカスタムリソースが作成されます。Kubernetes APIは、作成したカスタムリソースのストレージを提供、および処理します。
|
||||
|
||||
これはカスタムリソースを処理するために、独自のAPIサーバーを書くことから解放してくれますが、一般的な性質として[APIサーバーアグリゲーション](#APIサーバーアグリゲーション)と比べると、柔軟性に欠けます。
|
||||
|
||||
新しいカスタムリソースをどのように登録するか、新しいリソースタイプとの連携、そしてコントローラーを使いイベントを処理する方法例について、[カスタムコントローラー例](https://github.com/kubernetes/sample-controller)を参照してください。
|
||||
|
||||
## APIサーバーアグリゲーション
|
||||
|
||||
通常、Kubernetes APIの各リソースは、RESTリクエストとオブジェクトの永続的なストレージを管理するためのコードが必要です。メインのKubernetes APIサーバーは *Pod* や *Service* のようなビルトインのリソースを処理し、また[CRD](#customresourcedefinition)を通じて、同じ方法でカスタムリソースも管理できます。
|
||||
|
||||
[アグリゲーションレイヤー](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)は、独自のスタンドアローンAPIサーバーを書き、デプロイすることで、カスタムリソースに特化した実装の提供を可能にします。メインのAPIサーバーが、処理したいカスタムリソースへのリクエストを委譲することで、他のクライアントからも利用できるようにします。
|
||||
|
||||
## カスタムリソースの追加方法を選択する
|
||||
|
||||
CRDは簡単に使えます。アグリゲートAPIはより柔軟です。ニーズに最も合う方法を選択してください。
|
||||
|
||||
通常、CRDは下記の場合に適しています:
|
||||
|
||||
* 少数のフィールドしか必要ない
|
||||
* そのリソースは社内のみで利用している、または小さいオープンソースプロジェクトの一部で利用している(商用プロダクトではない)
|
||||
|
||||
### 使いやすさの比較
|
||||
|
||||
CRDは、アグリゲートAPIと比べ、簡単に作れます。
|
||||
|
||||
| CRD | アグリゲートAPI |
|
||||
| -------------------------- | --------------- |
|
||||
| プログラミングが不要で、ユーザーはCRDコントローラーとしてどの言語でも選択可能 | Go言語でプログラミングし、バイナリとイメージの作成が必要。ユーザーはCRDコントローラーとしてどの言語でも選択可能 |
|
||||
| 追加のサービスは不要。カスタムリソースはAPIサーバーで処理される | 追加のサービス作成が必要で、障害が発生する可能性がある |
|
||||
| CRDが作成されると、継続的なサポートは無い。バグ修正は通常のKubernetesマスターのアップグレードで行われる | 定期的にアップストリームからバグ修正の取り込み、リビルド、そしてアグリゲートAPIサーバーの更新が必要かもしれない |
|
||||
| 複数バージョンのAPI管理は不要。例えば、あるリソースを操作するクライアントを管理していた場合、APIのアップグレードと一緒に更新される | 複数バージョンのAPIを管理しなければならない。例えば、世界中に共有されている拡張機能を開発している場合 |
|
||||
|
||||
### 高度な機能、柔軟性
|
||||
|
||||
アグリゲートAPIは、例えばストレージレイヤーのカスタマイズのような、より高度なAPI機能と他の機能のカスタマイズを可能にします。
|
||||
|
||||
| 機能 | 詳細 | CRD | アグリゲートAPI |
|
||||
| ---- | ---- | --- | --------------- |
|
||||
| バリデーション | エラーを予防し、クライアントと無関係にAPIを発達させることができるようになる。これらの機能は多数のクライアントがおり、同時に全てを更新できないときに最も効果を発揮する | はい、ほとんどのバリデーションは[OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation)で、CRDに指定できる。その他のバリデーションは[Webhookのバリデーション](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9)によりサポートされている | はい、任意のバリデーションが可能 |
|
||||
| デフォルト設定 | 上記を参照 | はい、[OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#defaulting)の`default`キーワード(1.16でベータ)、または[Mutating Webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook-beta-in-1-9)を通じて可能 | はい |
|
||||
| 複数バージョニング | 同じオブジェクトを、違うAPIバージョンで利用可能にする。フィールドの名前を変更するなどのAPIの変更を簡単に行うのに役立つ。クライアントのバージョンを管理する場合、重要性は下がる | [はい](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning) | はい |
|
||||
| カスタムストレージ | 異なる性能のストレージが必要な場合(例えば、キーバリューストアの代わりに時系列データベース)または、セキュリティの分離(例えば、機密情報の暗号化、その他)| いいえ | はい |
|
||||
| カスタムビジネスロジック | オブジェクトが作成、読み込み、更新、また削除されるときに任意のチェック、アクションを実行する| はい、[Webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)を利用 | はい |
|
||||
| サブリソースのスケール | HorizontalPodAutoscalerやPodDisruptionBudgetなどのシステムが、新しいリソースと連携できるようにする | [はい](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#scale-subresource) | はい |
|
||||
| サブリソースの状態 | <ul><li>より詳細なアクセスコントロール: ユーザーがspecセクションに書き込み、コントローラーがstatusセクションに書き込む</li><li>カスタムリソースのデータ変換時にオブジェクトの世代を上げられるようにする(リソースがspecと、statusでセクションが分離している必要がある)</li></ul> | [はい](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#status-subresource) | はい |
|
||||
| その他のサブリソース | "logs"や"exec"のような、CRUD以外の処理の追加 | いいえ | はい |
|
||||
| strategic-merge-patch |`Content-Type: application/strategic-merge-patch+json`で、PATCHをサポートする新しいエンドポイント。ローカル、サーバー、どちらでも更新されうるオブジェクトに有用。さらなる情報は["APIオブジェクトをkubectl patchで決まった場所で更新"](/docs/tasks/run-application/update-api-object-kubectl-patch/)を参照 | いいえ | はい |
|
||||
| プロトコルバッファ | プロトコルバッファを使用するクライアントをサポートする新しいリソース | いいえ | はい |
|
||||
| OpenAPIスキーマ | サーバーから動的に取得できる型のOpenAPI(スワッガー)スキーマはあるか、許可されたフィールドのみが設定されるようにすることで、ユーザーはフィールド名のスペルミスから保護されているか、型は強制されているか(言い換えると、「文字列」フィールドに「int」を入れさせない) | はい、[OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation) スキーマがベース(1.16でGA) | はい |
|
||||
|
||||
### 一般的な機能
|
||||
|
||||
CRD、またはアグリゲートAPI、どちらを使ってカスタムリソースを作った場合でも、Kubernetesプラットフォーム外でAPIを実装するのに比べ、多数の機能が提供されます:
|
||||
|
||||
| 機能 | 何を実現するか |
|
||||
| ---- | -------------- |
|
||||
| CRUD | 新しいエンドポイントが、HTTP、`kubectl`を通じて、基本的なCRUD処理をサポート |
|
||||
| Watch | 新しいエンドポイントが、HTTPを通じて、KubernetesのWatch処理をサポート |
|
||||
| Discovery | kubectlやダッシュボードのようなクライアントが、自動的にリソースの一覧表示、個別表示、フィールドの編集処理を提供 |
|
||||
| json-patch | 新しいエンドポイントが`Content-Type: application/json-patch+json`を用いたPATCHをサポート |
|
||||
| merge-patch | 新しいエンドポイントが`Content-Type: application/merge-patch+json`を用いたPATCHをサポート |
|
||||
| HTTPS | 新しいエンドポイントがHTTPSを利用 |
|
||||
| ビルトイン認証 | 拡張機能へのアクセスに認証のため、コアAPIサーバー(アグリゲーションレイヤー)を利用 |
|
||||
| ビルトイン認可 | 拡張機能へのアクセスにコアAPIサーバーで使われている認可機構を再利用(例、RBAC) |
|
||||
| ファイナライザー | 外部リソースの削除が終わるまで、拡張リソースの削除をブロック |
|
||||
| Admission Webhooks | 拡張リソースの作成/更新/削除処理時に、デフォルト値の設定、バリデーションを実施 |
|
||||
| UI/CLI 表示 | kubectl、ダッシュボードで拡張リソースを表示 |
|
||||
| 未設定 vs 空設定 | クライアントは、フィールドの未設定とゼロ値を区別することができる |
|
||||
| クライアントライブラリーの生成 | Kubernetesは、一般的なクライアントライブラリーと、タイプ固有のクライアントライブラリーを生成するツールを提供 |
|
||||
| ラベルとアノテーション | ツールがコアリソースとカスタムリソースの編集方法を知っているオブジェクト間で、共通のメタデータを提供 |
|
||||
|
||||
## カスタムリソースのインストール準備
|
||||
|
||||
クラスターにカスタムリソースを追加する前に、いくつか認識しておくべき事項があります。
|
||||
|
||||
### サードパーティのコードと新しい障害点
|
||||
|
||||
CRDを作成しても、勝手に新しい障害点が追加されてしまうことはありませんが（たとえば、サードパーティのコードをAPIサーバーで実行することによって）、パッケージ（たとえば、チャート）またはその他のインストールバンドルには、多くの場合、CRDと新しいカスタムリソースのビジネスロジックを実装するサードパーティコードが入ったDeploymentが含まれます。
|
||||
|
||||
アグリゲートAPIサーバーのインストールすると、常に新しいDeploymentが付いてきます。
|
||||
|
||||
### ストレージ
|
||||
|
||||
カスタムリソースは、ConfigMapと同じ方法でストレージの容量を消費します。多数のカスタムリソースを作成すると、APIサーバーのストレージ容量を超えてしまうかもしれません。
|
||||
|
||||
アグリゲートAPIサーバーも、メインのAPIサーバーと同じストレージを利用するかもしれません。その場合、同じ問題が発生しえます。
|
||||
|
||||
### 認証、認可、そして監査
|
||||
|
||||
CRDでは、APIサーバーのビルトインリソースと同じ認証、認可、そして監査ロギングの仕組みを利用します。
|
||||
|
||||
もしRBACを使っている場合、ほとんどのRBACのロールは新しいリソースへのアクセスを許可しません。(クラスター管理者ロール、もしくはワイルドカードで作成されたロールを除く)新しいリソースには、明示的にアクセスを許可する必要があります。多くの場合、CRDおよびアグリゲートAPIには、追加するタイプの新しいロール定義がバンドルされています。
|
||||
|
||||
アグリゲートAPIサーバーでは、APIサーバーのビルトインリソースと同じ認証、認可、そして監査の仕組みを使う場合と使わない場合があります。
|
||||
|
||||
## カスタムリソースへのアクセス
|
||||
|
||||
Kubernetesの[クライアントライブラリー](/docs/reference/using-api/client-libraries/)を使い、カスタムリソースにアクセスすることが可能です。全てのクライアントライブラリーがカスタムリソースをサポートしているわけでは無いですが、GoとPythonのライブラリーはサポートしています。
|
||||
|
||||
カスタムリソースは、下記のような方法で操作できます:
|
||||
|
||||
- kubectl
|
||||
- kubernetesの動的クライアント
|
||||
- 自作のRESTクライアント
|
||||
- [Kubernetesクライアント生成ツール](https://github.com/kubernetes/code-generator)を使い生成したクライアント(生成は高度な作業ですが、一部のプロジェクトは、CRDまたはAAとともにクライアントを提供する場合があります)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* [Kubernetes APIをアグリゲーションレイヤーで拡張する方法](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)について学ぶ
|
||||
* [Kubernetes APIをCustomResourceDefinitionで拡張する方法](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)について学ぶ
|
||||
|
||||
{{% /capture %}}
|
||||
|
|
@ -1,5 +1,4 @@
|
|||
---
|
||||
title: "Overview"
|
||||
title: "概要"
|
||||
weight: 20
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,15 @@ card:
|
|||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
Kubernetesをデプロイすると、クラスターが展開されます。
|
||||
{{< glossary_definition term_id="cluster" length="all" prepend="クラスターは、">}}
|
||||
|
||||
このドキュメントでは、Kubernetesクラスターが機能するために必要となるさまざまなコンポーネントの概要を説明します。
|
||||
|
||||
すべてのコンポーネントが結び付けられたKubernetesクラスターの図を次に示します。
|
||||
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
|
@ -106,7 +114,8 @@ Kubernetesによって開始されたコンテナは、DNS検索にこのDNSサ
|
|||
|
||||
{{% /capture %}}
|
||||
{{% capture whatsnext %}}
|
||||
* [ノード](/docs/concepts/architecture/nodes/) について学ぶ
|
||||
* [kube-scheduler](/docs/concepts/scheduling/kube-scheduler/) について学ぶ
|
||||
* etcdの公式 [ドキュメント](https://etcd.io/docs/) を読む
|
||||
* [ノード](/ja/docs/concepts/architecture/nodes/)について学ぶ
|
||||
* [コントローラー](/docs/concepts/architecture/controller/)について学ぶ
|
||||
* [kube-scheduler](/ja/docs/concepts/scheduling/kube-scheduler/)について学ぶ
|
||||
* etcdの公式 [ドキュメント](https://etcd.io/docs/)を読む
|
||||
{{% /capture %}}
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: "Working with Kubernetes Objects"
|
||||
title: "Kubernetesのオブジェクトについて"
|
||||
weight: 40
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,74 @@
|
|||
---
|
||||
title: スケジューラーのパフォーマンスチューニング
|
||||
content_template: templates/concept
|
||||
weight: 70
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
{{< feature-state for_k8s_version="1.14" state="beta" >}}
|
||||
|
||||
[kube-scheduler](/docs/concepts/scheduling/kube-scheduler/#kube-scheduler)はKubernetesのデフォルトのスケジューラーです。クラスター内のノード上にPodを割り当てる責務があります。
|
||||
|
||||
クラスター内に存在するノードで、Podのスケジューリング要求を満たすものはPodに対して_割り当て可能_ なノードと呼ばれます。スケジューラーはPodに対する割り当て可能なノードをみつけ、それらの割り当て可能なノードにスコアをつけます。その中から最も高いスコアのノードを選択し、Podに割り当てるためのいくつかの関数を実行します。スケジューラーは_Binding_ と呼ばれる処理中において、APIサーバーに対して割り当てが決まったノードの情報を通知します。
|
||||
|
||||
このページでは、大規模のKubernetesクラスターにおけるパフォーマンス最適化のためのチューニングについて説明します。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## スコア付けするノードの割合
|
||||
|
||||
Kubernetes 1.12以前では、Kube-schedulerがクラスター内の全てのノードに対して割り当て可能かをチェックし、実際に割り当て可能なノードのスコア付けをしていました。Kubernetes 1.12では新機能を追加し、ある数の割り当て可能なノードが見つかった時点で、割り当て可能なノードの探索を止めれるようになりました。これにより大規模なクラスターにおけるスケジューラーのパフォーマンスが向上しました。その数はクラスターのサイズの割合(%)として指定されます。この割合は`percentageOfNodesToScore`というオプションの設定項目によって指定可能です。この値の範囲は1から100までです。100より大きい値は100%として扱われます。0を指定したときは、この設定オプションを指定しないものとして扱われます。Kubernetes 1.14では、この値が指定されていないときは、スコア付けするノードの割合をクラスターのサイズに基づいて決定するための機構があります。この機構では100ノードのクラスターに対しては50%の割合とするような線形な式を使用します。5000ノードのクラスターに対しては10%となります。自動で算出される割合の最低値は5%となります。言い換えると、クラスターの規模がどれだけ大きくても、ユーザーがこの値を5未満に設定しない限りスケジューラーは少なくても5%のクラスター内のノードをスコア付けすることになります。
|
||||
|
||||
`percentageOfNodesToScore`の値を50%に設定する例は下記のとおりです。
|
||||
|
||||
```yaml
|
||||
apiVersion: kubescheduler.config.k8s.io/v1alpha1
|
||||
kind: KubeSchedulerConfiguration
|
||||
algorithmSource:
|
||||
provider: DefaultProvider
|
||||
|
||||
...
|
||||
|
||||
percentageOfNodesToScore: 50
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
割り当て可能なノードが50未満のクラスターにおいては、割り当て可能なノードの探索を止めるほどノードが多くないため、スケジューラーは全てのノードをチェックします。
|
||||
{{< /note >}}
|
||||
|
||||
**この機能を無効にするためには**、`percentageOfNodesToScore`を100に設定してください。
|
||||
|
||||
|
||||
### percentageOfNodesToScoreのチューニング
|
||||
|
||||
`percentageOfNodesToScore`は1から100の間の範囲である必要があり、デフォルト値はクラスターのサイズに基づいて計算されます。また、クラスターのサイズの最小値は50ノードとハードコードされています。これは数百のノードを持つようなクラスターにおいてこの値を50より低い値に変更しても、スケジューラーが検出する割り当て可能なノードの数に大きな影響を与えないことを意味します。このオプションは意図的なものです。その理由としては、小規模のクラスターにおいてパフォーマンスを著しく改善する可能性が低いためです。1000ノードを超える大規模なクラスターでこの値を低く設定すると、パフォーマンスが著しく改善される可能性があります。
|
||||
|
||||
この値を設定する際に考慮するべき重要な注意事項として、割り当て可能ノードのチェック対象のノードが少ないと、一部のノードはPodの割り当てのためにスコアリングされなくなります。結果として、高いスコアをつけられる可能性のあるノードがスコアリングフェーズに渡されることがありません。これにより、Podの配置が理想的なものでなくなります。したがって、この値をかなり低い割合に設定すべきではありません。一般的な経験則として、この値を10未満に設定しないことです。スケジューラーのスループットがアプリケーションにとって致命的で、ノードのスコアリングが重要でないときのみ、この値を低く設定するべきです。言いかえると、割り当て可能な限り、Podは任意のノード上で稼働させるのが好ましいです。
|
||||
|
||||
クラスターが数百のノードを持つ場合やそれに満たない場合でも、この設定オプションのデフォルト値を低くするのを推奨しません。デフォルト値を低くしてもスケジューラーのパフォーマンスを大幅に改善することはありません。
|
||||
|
||||
### スケジューラーはどのようにノードを探索するか
|
||||
|
||||
このセクションでは、この機能の内部の詳細を理解したい人向けになります。
|
||||
|
||||
クラスター内の全てのノードに対して平等にPodの割り当ての可能性を持たせるため、スケジューラーはラウンドロビン方式でノードを探索します。複数のノードの配列になっているイメージです。スケジューラーはその配列の先頭から探索を開始し、`percentageOfNodesToScore`によって指定された数のノードを検出するまで、割り当て可能かどうかをチェックしていきます。次のPodでは、スケジューラーは前のPodの割り当て処理でチェックしたところから探索を再開します。
|
||||
|
||||
ノードが複数のゾーンに存在するとき、スケジューラーは様々なゾーンのノードを探索して、異なるゾーンのノードが割り当て可能かどうかのチェック対象になるようにします。例えば2つのゾーンに6つのノードがある場合を考えます。
|
||||
|
||||
```
|
||||
Zone 1: Node 1, Node 2, Node 3, Node 4
|
||||
Zone 2: Node 5, Node 6
|
||||
```
|
||||
|
||||
スケジューラーは、下記の順番でノードの割り当て可能性を評価します。
|
||||
|
||||
```
|
||||
Node 1, Node 5, Node 2, Node 6, Node 3, Node 4
|
||||
```
|
||||
|
||||
全てのノードのチェックを終えたら、1番目のノードに戻ってチェックをします。
|
||||
|
||||
{{% /capture %}}
|
||||
|
|
@ -0,0 +1,420 @@
|
|||
---
|
||||
title: サービスとアプリケーションの接続
|
||||
content_template: templates/concept
|
||||
weight: 30
|
||||
---
|
||||
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
## コンテナを接続するためのKubernetesモデル
|
||||
|
||||
継続的に実行され、複製されたアプリケーションの準備ができたので、ネットワーク上で公開することが可能になります。
|
||||
Kubernetesのネットワークのアプローチについて説明する前に、Dockerの「通常の」ネットワーク手法と比較することが重要です。
|
||||
|
||||
デフォルトでは、Dockerはホストプライベートネットワーキングを使用するため、コンテナは同じマシン上にある場合にのみ他のコンテナと通信できます。
|
||||
Dockerコンテナがノード間で通信するには、マシンのIPアドレスにポートを割り当ててから、コンテナに転送またはプロキシする必要があります。
|
||||
これは明らかに、コンテナが使用するポートを非常に慎重に調整するか、ポートを動的に割り当てる必要があることを意味します。
|
||||
|
||||
複数の開発者間でポートを調整することは大規模に行うことは非常に難しく、ユーザーが制御できないクラスターレベルの問題にさらされます。
|
||||
Kubernetesでは、どのホストで稼働するかに関わらず、Podが他のPodと通信できると想定しています。
|
||||
すべてのPodに独自のクラスタープライベートIPアドレスを付与するため、Pod間のリンクを明示的に作成したり、コンテナポートをホストポートにマップしたりする必要はありません。
|
||||
これは、Pod内のコンテナがすべてlocalhostの相互のポートに到達でき、クラスター内のすべてのPodがNATなしで相互に認識できることを意味します。
|
||||
このドキュメントの残りの部分では、このようなネットワークモデルで信頼できるサービスを実行する方法について詳しく説明します。
|
||||
|
||||
このガイドでは、シンプルなnginxサーバーを使用して概念実証を示します。
|
||||
同じ原則が、より完全な[Jenkins CIアプリケーション](https://kubernetes.io/blog/2015/07/strong-simple-ssl-for-kubernetes)で具体化されています。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Podをクラスターに公開する
|
||||
|
||||
前の例でネットワークモデルを紹介しましたが、再度ネットワークの観点に焦点を当てましょう。
|
||||
nginx Podを作成し、コンテナポートの仕様を指定していることに注意してください。
|
||||
|
||||
{{< codenew file="service/networking/run-my-nginx.yaml" >}}
|
||||
|
||||
これにより、クラスター内のどのノードからでもアクセスできるようになります。
|
||||
Podが実行されているノードを確認します:
|
||||
|
||||
```shell
|
||||
kubectl apply -f ./run-my-nginx.yaml
|
||||
kubectl get pods -l run=my-nginx -o wide
|
||||
```
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE IP NODE
|
||||
my-nginx-3800858182-jr4a2 1/1 Running 0 13s 10.244.3.4 kubernetes-minion-905m
|
||||
my-nginx-3800858182-kna2y 1/1 Running 0 13s 10.244.2.5 kubernetes-minion-ljyd
|
||||
```
|
||||
|
||||
PodのIPを確認します:
|
||||
|
||||
```shell
|
||||
kubectl get pods -l run=my-nginx -o yaml | grep podIP
|
||||
podIP: 10.244.3.4
|
||||
podIP: 10.244.2.5
|
||||
```
|
||||
|
||||
クラスター内の任意のノードにSSH接続し、両方のIPにcurl接続できるはずです。
|
||||
コンテナはノードでポート80を使用**していない**ことに注意してください。
|
||||
また、Podにトラフィックをルーティングする特別なNATルールもありません。
|
||||
つまり、同じcontainerPortを使用して同じノードで複数のnginx Podを実行し、IPを使用してクラスター内の他のPodやノードからそれらにアクセスできます。
|
||||
Dockerと同様に、ポートは引き続きホストノードのインターフェイスに公開できますが、ネットワークモデルにより、この必要性は根本的に減少します。
|
||||
|
||||
興味があれば、これを[どのように達成するか](/docs/concepts/cluster-administration/networking/#how-to-achieve-this)について詳しく読むことができます。
|
||||
|
||||
## Serviceを作成する
|
||||
|
||||
そのため、フラットでクラスター全体のアドレス空間でnginxを実行するPodがあります。
|
||||
理論的には、これらのPodと直接通信することができますが、ノードが停止するとどうなりますか？
|
||||
Podはそれで死に、Deploymentは異なるIPを持つ新しいものを作成します。
|
||||
これは、Serviceが解決する問題です。
|
||||
|
||||
Kubernetes Serviceは、クラスター内のどこかで実行されるPodの論理セットを定義する抽象化であり、すべて同じ機能を提供します。
|
||||
作成されると、各Serviceには一意のIPアドレス(clusterIPとも呼ばれます)が割り当てられます。
|
||||
このアドレスはServiceの有効期間に関連付けられており、Serviceが動作している間は変更されません。
|
||||
Podは、Serviceと通信するように構成でき、Serviceへの通信は、ServiceのメンバーであるPodに自動的に負荷分散されることを認識できます。
|
||||
|
||||
2つのnginxレプリカのサービスを`kubectl exposed`で作成できます:
|
||||
|
||||
```shell
|
||||
kubectl expose deployment/my-nginx
|
||||
```
|
||||
```
|
||||
service/my-nginx exposed
|
||||
```
|
||||
|
||||
これは次のyamlを`kubectl apply -f`することと同等です:
|
||||
|
||||
{{< codenew file="service/networking/nginx-svc.yaml" >}}
|
||||
|
||||
この仕様は、`run：my-nginx`ラベルを持つ任意のPodのTCPポート80をターゲットとするサービスを作成し、抽象化されたサービスポートでPodを公開します(`targetPort`:はコンテナがトラフィックを受信するポート、`port`:は抽象化されたServiceのポートであり、他のPodがServiceへのアクセスに使用する任意のポートにすることができます)。
|
||||
サービス定義でサポートされているフィールドのリストは[Service](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core) APIオブジェクトを参照してください。
|
||||
|
||||
Serviceを確認します:
|
||||
|
||||
```shell
|
||||
kubectl get svc my-nginx
|
||||
```
|
||||
```
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
my-nginx ClusterIP 10.0.162.149 <none> 80/TCP 21s
|
||||
```
|
||||
|
||||
前述のように、ServiceはPodのグループによってサポートされています。
|
||||
これらのPodはエンドポイントを通じて公開されます。
|
||||
Serviceのセレクターは継続的に評価され、結果は`my-nginx`という名前のEndpointオブジェクトにPOSTされます。
|
||||
Podが終了すると、エンドポイントから自動的に削除され、Serviceのセレクターに一致する新しいPodが自動的にエンドポイントに追加されます。
|
||||
エンドポイントを確認し、IPが最初のステップで作成されたPodと同じであることを確認します:
|
||||
|
||||
```shell
|
||||
kubectl describe svc my-nginx
|
||||
```
|
||||
```
|
||||
Name: my-nginx
|
||||
Namespace: default
|
||||
Labels: run=my-nginx
|
||||
Annotations: <none>
|
||||
Selector: run=my-nginx
|
||||
Type: ClusterIP
|
||||
IP: 10.0.162.149
|
||||
Port: <unset> 80/TCP
|
||||
Endpoints: 10.244.2.5:80,10.244.3.4:80
|
||||
Session Affinity: None
|
||||
Events: <none>
|
||||
```
|
||||
```shell
|
||||
kubectl get ep my-nginx
|
||||
```
|
||||
```
|
||||
NAME ENDPOINTS AGE
|
||||
my-nginx 10.244.2.5:80,10.244.3.4:80 1m
|
||||
```
|
||||
|
||||
クラスター内の任意のノードから、`<CLUSTER-IP>:<PORT>`でnginx Serviceにcurl接続できるようになりました。
|
||||
Service IPは完全に仮想的なもので、ホスト側のネットワークには接続できないことに注意してください。
|
||||
この仕組みに興味がある場合は、[サービスプロキシー](/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)の詳細をお読みください。
|
||||
|
||||
## Serviceにアクセスする
|
||||
|
||||
Kubernetesは、環境変数とDNSの2つの主要なService検索モードをサポートしています。
|
||||
前者はそのまま使用でき、後者は[CoreDNSクラスタアドオン](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns)を必要とします。
|
||||
{{< note >}}
|
||||
サービス環境変数が望ましくない場合(予想されるプログラム変数と衝突する可能性がある、処理する変数が多すぎる、DNSのみを使用するなど)、[Pod仕様](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)で`enableServiceLinks`フラグを`false`に設定することでこのモードを無効にできます。
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
### 環境変数
|
||||
|
||||
ノードでPodが実行されると、kubeletはアクティブな各サービスの環境変数のセットを追加します。
|
||||
これにより、順序付けの問題が発生します。
|
||||
理由を確認するには、実行中のnginx Podの環境を調べます(Pod名は環境によって異なります):
|
||||
|
||||
```shell
|
||||
kubectl exec my-nginx-3800858182-jr4a2 -- printenv | grep SERVICE
|
||||
```
|
||||
```
|
||||
KUBERNETES_SERVICE_HOST=10.0.0.1
|
||||
KUBERNETES_SERVICE_PORT=443
|
||||
KUBERNETES_SERVICE_PORT_HTTPS=443
|
||||
```
|
||||
|
||||
サービスに言及がないことに注意してください。これは、サービスの前にレプリカを作成したためです。
|
||||
これのもう1つの欠点は、スケジューラーが両方のPodを同じマシンに配置し、サービスが停止した場合にサービス全体がダウンする可能性があることです。
|
||||
2つのPodを強制終了し、Deploymentがそれらを再作成するのを待つことで、これを正しい方法で実行できます。
|
||||
今回は、サービスはレプリカの「前」に存在します。
|
||||
これにより、スケジューラーレベルのサービスがPodに広がり(すべてのノードの容量が等しい場合)、適切な環境変数が提供されます:
|
||||
|
||||
```shell
|
||||
kubectl scale deployment my-nginx --replicas=0; kubectl scale deployment my-nginx --replicas=2;
|
||||
|
||||
kubectl get pods -l run=my-nginx -o wide
|
||||
```
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE IP NODE
|
||||
my-nginx-3800858182-e9ihh 1/1 Running 0 5s 10.244.2.7 kubernetes-minion-ljyd
|
||||
my-nginx-3800858182-j4rm4 1/1 Running 0 5s 10.244.3.8 kubernetes-minion-905m
|
||||
```
|
||||
|
||||
Podは強制終了されて再作成されるため、異なる名前が付いていることに気付くでしょう。
|
||||
|
||||
```shell
|
||||
kubectl exec my-nginx-3800858182-e9ihh -- printenv | grep SERVICE
|
||||
```
|
||||
```
|
||||
KUBERNETES_SERVICE_PORT=443
|
||||
MY_NGINX_SERVICE_HOST=10.0.162.149
|
||||
KUBERNETES_SERVICE_HOST=10.0.0.1
|
||||
MY_NGINX_SERVICE_PORT=80
|
||||
KUBERNETES_SERVICE_PORT_HTTPS=443
|
||||
```
|
||||
|
||||
### DNS
|
||||
|
||||
Kubernetesは、DNS名を他のServiceに自動的に割り当てるDNSクラスターアドオンサービスを提供します。
|
||||
クラスターで実行されているかどうかを確認できます:
|
||||
|
||||
```shell
|
||||
kubectl get services kube-dns --namespace=kube-system
|
||||
```
|
||||
```
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
kube-dns ClusterIP 10.0.0.10 <none> 53/UDP,53/TCP 8m
|
||||
```
|
||||
|
||||
実行されていない場合は、[有効にする](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/README.md#how-do-i-configure-it)ことができます。
|
||||
このセクションの残りの部分では、寿命の長いIP(my-nginx)を持つServiceと、そのIPに名前を割り当てたDNSサーバー(CoreDNSクラスターアドオン)があることを前提としているため、標準的な方法(gethostbynameなど)を使用してクラスター内の任意のPodからServiceに通信できます。
|
||||
curlアプリケーションを実行して、これをテストしてみましょう:
|
||||
|
||||
```shell
|
||||
kubectl run curl --image=radial/busyboxplus:curl -i --tty
|
||||
```
|
||||
```
|
||||
Waiting for pod default/curl-131556218-9fnch to be running, status is Pending, pod ready: false
|
||||
Hit enter for command prompt
|
||||
```
|
||||
|
||||
次に、Enterキーを押して`nslookup my-nginx`を実行します:
|
||||
|
||||
```shell
|
||||
[ root@curl-131556218-9fnch:/ ]$ nslookup my-nginx
|
||||
Server: 10.0.0.10
|
||||
Address 1: 10.0.0.10
|
||||
|
||||
Name: my-nginx
|
||||
Address 1: 10.0.162.149
|
||||
```
|
||||
|
||||
## Serviceを安全にする
|
||||
|
||||
これまでは、クラスター内からnginxサーバーにアクセスしただけでした。
|
||||
サービスをインターネットに公開する前に、通信チャネルが安全であることを確認する必要があります。
|
||||
これには、次のものが必要です:
|
||||
|
||||
* https用の自己署名証明書(既にID証明書を持っている場合を除く)
|
||||
* 証明書を使用するように構成されたnginxサーバー
|
||||
* Podが証明書にアクセスできるようにする[Secret](/docs/concepts/configuration/secret/)
|
||||
|
||||
これらはすべて[nginx httpsの例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/)から取得できます。
|
||||
これにはツールをインストールする必要があります。
|
||||
これらをインストールしたくない場合は、後で手動の手順に従ってください。つまり:
|
||||
|
||||
```shell
|
||||
make keys KEY=/tmp/nginx.key CERT=/tmp/nginx.crt
|
||||
kubectl create secret tls nginxsecret --key /tmp/nginx.key --cert /tmp/nginx.crt
|
||||
```
|
||||
```
|
||||
secret/nginxsecret created
|
||||
```
|
||||
```shell
|
||||
kubectl get secrets
|
||||
```
|
||||
```
|
||||
NAME TYPE DATA AGE
|
||||
default-token-il9rc kubernetes.io/service-account-token 1 1d
|
||||
nginxsecret Opaque 2 1m
|
||||
```
|
||||
以下は、(Windows上など)makeの実行で問題が発生した場合に実行する手動の手順です:
|
||||
|
||||
```shell
|
||||
# 公開秘密鍵ペアを作成します
|
||||
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /d/tmp/nginx.key -out /d/tmp/nginx.crt -subj "/CN=my-nginx/O=my-nginx"
|
||||
# キーをbase64エンコードに変換します
|
||||
cat /d/tmp/nginx.crt | base64
|
||||
cat /d/tmp/nginx.key | base64
|
||||
```
|
||||
前のコマンドの出力を使用して、次のようにyamlファイルを作成します。
|
||||
base64でエンコードされた値はすべて1行である必要があります。
|
||||
|
||||
```yaml
|
||||
apiVersion: "v1"
|
||||
kind: "Secret"
|
||||
metadata:
|
||||
name: "nginxsecret"
|
||||
namespace: "default"
|
||||
data:
|
||||
nginx.crt: "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURIekNDQWdlZ0F3SUJBZ0lKQUp5M3lQK0pzMlpJTUEwR0NTcUdTSWIzRFFFQkJRVUFNQ1l4RVRBUEJnTlYKQkFNVENHNW5hVzU0YzNaak1SRXdEd1lEVlFRS0V3aHVaMmx1ZUhOMll6QWVGdzB4TnpFd01qWXdOekEzTVRKYQpGdzB4T0RFd01qWXdOekEzTVRKYU1DWXhFVEFQQmdOVkJBTVRDRzVuYVc1NGMzWmpNUkV3RHdZRFZRUUtFd2h1CloybHVlSE4yWXpDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBSjFxSU1SOVdWM0IKMlZIQlRMRmtobDRONXljMEJxYUhIQktMSnJMcy8vdzZhU3hRS29GbHlJSU94NGUrMlN5ajBFcndCLzlYTnBwbQppeW1CL3JkRldkOXg5UWhBQUxCZkVaTmNiV3NsTVFVcnhBZW50VWt1dk1vLzgvMHRpbGhjc3paenJEYVJ4NEo5Ci82UVRtVVI3a0ZTWUpOWTVQZkR3cGc3dlVvaDZmZ1Voam92VG42eHNVR0M2QURVODBpNXFlZWhNeVI1N2lmU2YKNHZpaXdIY3hnL3lZR1JBRS9mRTRqakxCdmdONjc2SU90S01rZXV3R0ljNDFhd05tNnNTSzRqYUNGeGpYSnZaZQp2by9kTlEybHhHWCtKT2l3SEhXbXNhdGp4WTRaNVk3R1ZoK0QrWnYvcW1mMFgvbVY0Rmo1NzV3ajFMWVBocWtsCmdhSXZYRyt4U1FVQ0F3RUFBYU5RTUU0d0hRWURWUjBPQkJZRUZPNG9OWkI3YXc1OUlsYkROMzhIYkduYnhFVjcKTUI4R0ExVWRJd1FZTUJhQUZPNG9OWkI3YXc1OUlsYkROMzhIYkduYnhFVjdNQXdHQTFVZEV3UUZNQU1CQWY4dwpEUVlKS29aSWh2Y05BUUVGQlFBRGdnRUJBRVhTMW9FU0lFaXdyMDhWcVA0K2NwTHI3TW5FMTducDBvMm14alFvCjRGb0RvRjdRZnZqeE04Tzd2TjB0clcxb2pGSW0vWDE4ZnZaL3k4ZzVaWG40Vm8zc3hKVmRBcStNZC9jTStzUGEKNmJjTkNUekZqeFpUV0UrKzE5NS9zb2dmOUZ3VDVDK3U2Q3B5N0M3MTZvUXRUakViV05VdEt4cXI0Nk1OZWNCMApwRFhWZmdWQTRadkR4NFo3S2RiZDY5eXM3OVFHYmg5ZW1PZ05NZFlsSUswSGt0ejF5WU4vbVpmK3FqTkJqbWZjCkNnMnlwbGQ0Wi8rUUNQZjl3SkoybFIrY2FnT0R4elBWcGxNSEcybzgvTHFDdnh6elZPUDUxeXdLZEtxaUMwSVEKQ0I5T2wwWW5scE9UNEh1b2hSUzBPOStlMm9KdFZsNUIyczRpbDlhZ3RTVXFxUlU9Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K"
|
||||
nginx.key: "LS0tLS1CRUdJTiBQUklWQVRFIEtFWS0tLS0tCk1JSUV2UUlCQURBTkJna3Foa2lHOXcwQkFRRUZBQVNDQktjd2dnU2pBZ0VBQW9JQkFRQ2RhaURFZlZsZHdkbFIKd1V5eFpJWmVEZWNuTkFhbWh4d1NpeWF5N1AvOE9ta3NVQ3FCWmNpQ0RzZUh2dGtzbzlCSzhBZi9WemFhWm9zcApnZjYzUlZuZmNmVUlRQUN3WHhHVFhHMXJKVEVGSzhRSHA3VkpMcnpLUC9QOUxZcFlYTE0yYzZ3MmtjZUNmZitrCkU1bEVlNUJVbUNUV09UM3c4S1lPNzFLSWVuNEZJWTZMMDUrc2JGQmd1Z0ExUE5JdWFubm9UTWtlZTRuMG4rTDQKb3NCM01ZUDhtQmtRQlAzeE9JNHl3YjREZXUraURyU2pKSHJzQmlIT05Xc0RadXJFaXVJMmdoY1kxeWIyWHI2UAozVFVOcGNSbC9pVG9zQngxcHJHclk4V09HZVdPeGxZZmcvbWIvNnBuOUYvNWxlQlkrZStjSTlTMkQ0YXBKWUdpCkwxeHZzVWtGQWdNQkFBRUNnZ0VBZFhCK0xkbk8ySElOTGo5bWRsb25IUGlHWWVzZ294RGQwci9hQ1Zkank4dlEKTjIwL3FQWkUxek1yall6Ry9kVGhTMmMwc0QxaTBXSjdwR1lGb0xtdXlWTjltY0FXUTM5SjM0VHZaU2FFSWZWNgo5TE1jUHhNTmFsNjRLMFRVbUFQZytGam9QSFlhUUxLOERLOUtnNXNrSE5pOWNzMlY5ckd6VWlVZWtBL0RBUlBTClI3L2ZjUFBacDRuRWVBZmI3WTk1R1llb1p5V21SU3VKdlNyblBESGtUdW1vVlVWdkxMRHRzaG9reUxiTWVtN3oKMmJzVmpwSW1GTHJqbGtmQXlpNHg0WjJrV3YyMFRrdWtsZU1jaVlMbjk4QWxiRi9DSmRLM3QraTRoMTVlR2ZQegpoTnh3bk9QdlVTaDR2Q0o3c2Q5TmtEUGJvS2JneVVHOXBYamZhRGR2UVFLQmdRRFFLM01nUkhkQ1pKNVFqZWFKClFGdXF4cHdnNzhZTjQyL1NwenlUYmtGcVFoQWtyczJxWGx1MDZBRzhrZzIzQkswaHkzaE9zSGgxcXRVK3NHZVAKOWRERHBsUWV0ODZsY2FlR3hoc0V0L1R6cEdtNGFKSm5oNzVVaTVGZk9QTDhPTm1FZ3MxMVRhUldhNzZxelRyMgphRlpjQ2pWV1g0YnRSTHVwSkgrMjZnY0FhUUtCZ1FEQmxVSUUzTnNVOFBBZEYvL25sQVB5VWs1T3lDdWc3dmVyClUycXlrdXFzYnBkSi9hODViT1JhM05IVmpVM25uRGpHVHBWaE9JeXg5TEFrc2RwZEFjVmxvcG9HODhXYk9lMTAKMUdqbnkySmdDK3JVWUZiRGtpUGx1K09IYnRnOXFYcGJMSHBzUVpsMGhucDBYSFNYVm9CMUliQndnMGEyOFVadApCbFBtWmc2d1BRS0JnRHVIUVV2SDZHYTNDVUsxNFdmOFhIcFFnMU16M2VvWTBPQm5iSDRvZUZKZmcraEppSXlnCm9RN3hqWldVR3BIc3AyblRtcHErQWlSNzdyRVhsdlhtOElVU2FsbkNiRGlKY01Pc29RdFBZNS9NczJMRm5LQTQKaENmL0pWb2FtZm1nZEN0ZGtFMXNINE9MR2lJVHdEbTRpb0dWZGIwMllnbzFyb2htNUpLMUI3MkpBb0dBUW01UQpHNDhXOTVhL0w1eSt5dCsyZ3YvUHM2VnBvMjZlTzRNQ3lJazJVem9ZWE9IYnNkODJkaC8xT2sybGdHZlI2K3VuCnc1YytZUXRSTHlhQmd3MUtpbGhFZDBKTWU3cGpUSVpnQWJ0LzVPbnlDak9OVXN2aDJjS2lrQ1Z2dTZsZlBjNkQKckliT2ZIaHhxV0RZK2Q1TGN1YSt2NzJ0RkxhenJsSlBsRzlOZHhrQ2dZRUF5elIzT3UyMDNRVVV6bUlCRkwzZAp4Wm5XZ0JLSEo3TnNxcGFWb2RjL0d5aGVycjFDZzE2MmJaSjJDV2RsZkI0VEdtUjZZdmxTZEFOOFRwUWhFbUtKCnFBLzVzdHdxNWd0WGVLOVJmMWxXK29xNThRNTBxMmk1NVdUTThoSDZhTjlaMTltZ0FGdE5VdGNqQUx2dFYxdEYKWSs4WFJkSHJaRnBIWll2NWkwVW1VbGc9Ci0tLS0tRU5EIFBSSVZBVEUgS0VZLS0tLS0K"
|
||||
```
|
||||
ファイルを使用してSecretを作成します:
|
||||
|
||||
```shell
|
||||
kubectl apply -f nginxsecrets.yaml
|
||||
kubectl get secrets
|
||||
```
|
||||
```
|
||||
NAME TYPE DATA AGE
|
||||
default-token-il9rc kubernetes.io/service-account-token 1 1d
|
||||
nginxsecret Opaque 2 1m
|
||||
```
|
||||
|
||||
次に、nginxレプリカを変更して、シークレットの証明書とServiceを使用してhttpsサーバーを起動し、両方のポート(80と443)を公開します:
|
||||
|
||||
{{< codenew file="service/networking/nginx-secure-app.yaml" >}}
|
||||
|
||||
nginx-secure-appマニフェストに関する注目すべき点:
|
||||
|
||||
- 同じファイルにDeploymentとServiceの両方が含まれています。
|
||||
- [nginxサーバー](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/default.conf)はポート80のHTTPトラフィックと443のHTTPSトラフィックを処理し、nginx Serviceは両方のポートを公開します。
|
||||
- 各コンテナは`/etc/nginx/ssl`にマウントされたボリュームを介してキーにアクセスできます。
|
||||
これは、nginxサーバーが起動する*前に*セットアップされます。
|
||||
|
||||
```shell
|
||||
kubectl delete deployments,svc my-nginx; kubectl create -f ./nginx-secure-app.yaml
|
||||
```
|
||||
|
||||
この時点で、任意のノードからnginxサーバーに到達できます。
|
||||
|
||||
```shell
|
||||
kubectl get pods -o yaml | grep -i podip
|
||||
podIP: 10.244.3.5
|
||||
node $ curl -k https://10.244.3.5
|
||||
...
|
||||
<h1>Welcome to nginx!</h1>
|
||||
```
|
||||
|
||||
最後の手順でcurlに`-k`パラメーターを指定したことに注意してください。
|
||||
これは、証明書の生成時にnginxを実行しているPodについて何も知らないためです。
|
||||
CNameの不一致を無視するようcurlに指示する必要があります。
|
||||
Serviceを作成することにより、証明書で使用されるCNameを、Service検索中にPodで使用される実際のDNS名にリンクしました。
|
||||
これをPodからテストしましょう(簡単にするために同じシークレットを再利用しています。PodはServiceにアクセスするためにnginx.crtのみを必要とします):
|
||||
|
||||
{{< codenew file="service/networking/curlpod.yaml" >}}
|
||||
|
||||
```shell
|
||||
kubectl apply -f ./curlpod.yaml
|
||||
kubectl get pods -l app=curlpod
|
||||
```
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
curl-deployment-1515033274-1410r 1/1 Running 0 1m
|
||||
```
|
||||
```shell
|
||||
kubectl exec curl-deployment-1515033274-1410r -- curl https://my-nginx --cacert /etc/nginx/ssl/nginx.crt
|
||||
...
|
||||
<title>Welcome to nginx!</title>
|
||||
...
|
||||
```
|
||||
|
||||
## Serviceを公開する
|
||||
|
||||
アプリケーションの一部では、Serviceを外部IPアドレスに公開したい場合があります。
|
||||
Kubernetesは、NodePortとLoadBalancerの2つの方法をサポートしています。
|
||||
前のセクションで作成したServiceはすでに`NodePort`を使用しているため、ノードにパブリックIPがあれば、nginx HTTPSレプリカはインターネット上のトラフィックを処理する準備ができています。
|
||||
|
||||
```shell
|
||||
kubectl get svc my-nginx -o yaml | grep nodePort -C 5
|
||||
uid: 07191fb3-f61a-11e5-8ae5-42010af00002
|
||||
spec:
|
||||
clusterIP: 10.0.162.149
|
||||
ports:
|
||||
- name: http
|
||||
nodePort: 31704
|
||||
port: 8080
|
||||
protocol: TCP
|
||||
targetPort: 80
|
||||
- name: https
|
||||
nodePort: 32453
|
||||
port: 443
|
||||
protocol: TCP
|
||||
targetPort: 443
|
||||
selector:
|
||||
run: my-nginx
|
||||
```
|
||||
```shell
|
||||
kubectl get nodes -o yaml | grep ExternalIP -C 1
|
||||
- address: 104.197.41.11
|
||||
type: ExternalIP
|
||||
allocatable:
|
||||
--
|
||||
- address: 23.251.152.56
|
||||
type: ExternalIP
|
||||
allocatable:
|
||||
...
|
||||
|
||||
$ curl https://<EXTERNAL-IP>:<NODE-PORT> -k
|
||||
...
|
||||
<h1>Welcome to nginx!</h1>
|
||||
```
|
||||
|
||||
クラウドロードバランサーを使用するようにサービスを再作成しましょう。
|
||||
`my-nginx`サービスの`Type`を`NodePort`から`LoadBalancer`に変更するだけです:
|
||||
|
||||
```shell
|
||||
kubectl edit svc my-nginx
|
||||
kubectl get svc my-nginx
|
||||
```
|
||||
```
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
my-nginx ClusterIP 10.0.162.149 162.222.184.144 80/TCP,81/TCP,82/TCP 21s
|
||||
```
|
||||
```
|
||||
curl https://<EXTERNAL-IP> -k
|
||||
...
|
||||
<title>Welcome to nginx!</title>
|
||||
```
|
||||
|
||||
`EXTERNAL-IP`列のIPアドレスは、パブリックインターネットで利用可能なものです。
|
||||
`CLUSTER-IP`は、クラスター/プライベートクラウドネットワーク内でのみ使用できます。
|
||||
|
||||
AWSでは、type `LoadBalancer`はIPではなく(長い)ホスト名を使用するELBが作成されます。
|
||||
実際、標準の`kubectl get svc`の出力に収まるには長すぎるので、それを確認するには`kubectl describe service my-nginx`を実行する必要があります。
|
||||
次のようなものが表示されます:
|
||||
|
||||
```shell
|
||||
kubectl describe service my-nginx
|
||||
...
|
||||
LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.elb.amazonaws.com
|
||||
...
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
Kubernetesは、複数のクラスターおよびクラウドプロバイダーにまたがるフェデレーションサービスもサポートし、可用性の向上、フォールトトレランスの向上、サービスのスケーラビリティの向上を実現します。
|
||||
詳細については[フェデレーションサービスユーザーガイド](/docs/concepts/cluster-administration/federation-service-discovery/)を参照してください。
|
||||
|
||||
{{% /capture %}}
|
||||
|
|
@ -0,0 +1,403 @@
|
|||
---
|
||||
title: Ingress
|
||||
content_template: templates/concept
|
||||
weight: 40
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
{{< feature-state for_k8s_version="v1.1" state="beta" >}}
|
||||
{{< glossary_definition term_id="ingress" length="all" >}}
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## 用語
|
||||
|
||||
まずわかりやすくするために、このガイドでは次の用語を定義します。
|
||||
|
||||
- ノード: Kubernetes内のワーカーマシンで、クラスターの一部です。
|
||||
|
||||
- クラスター: Kubernetesによって管理されているコンテナ化されたアプリケーションを実行させるノードのセットです。この例や、多くのKubernetesによるデプロイでは、クラスター内のノードはパブリックインターネットとして公開されていません。
|
||||
|
||||
- エッジルーター: クラスターでファイアウォールのポリシーを強制するルーターです。エッジルーターはクラウドプロバイダーやハードウェアの物理的な一部として管理されたゲートウェイとなります。
|
||||
|
||||
- クラスターネットワーク: 物理的または論理的なリンクのセットで、Kubernetesの[ネットワークモデル](/docs/concepts/cluster-administration/networking/)によって、クラスター内でのコミュニケーションを司るものです。
|
||||
|
||||
- Service: {{< glossary_tooltip text="ラベル" term_id="label" >}}セレクターを使ったPodのセットを特定するKubernetes {{< glossary_tooltip term_id="service" >}}です。特に言及がない限り、Serviceはクラスターネットワーク内でのみ疎通可能な仮想IPを持つと想定されます。
|
||||
|
||||
## Ingressとは何か
|
||||
|
||||
Ingressはクラスター外からクラスター内{{< link text="Service" url="/docs/concepts/services-networking/service/" >}}へのHTTPとHTTPSのルートを公開します。トラフィックのルーティングはIngressリソース上で定義されるルールによって制御されます。
|
||||
|
||||
```none
|
||||
internet
|
||||
|
|
||||
[ Ingress ]
|
||||
--|-----|--
|
||||
[ Services ]
|
||||
```
|
||||
|
||||
IngressはServiceに対して、外部疎通できるURL、負荷分散トラフィック、SSL/TLS終端の機能や、名前ベースの仮想ホスティングを提供するように構成できます。[Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)は通常はロードバランサーを使用してIngressの機能を実現しますが、エッジルーターや、追加のフロントエンドを構成してトラフィックの処理を支援することもできます。
|
||||
|
||||
Ingressは任意のポートやプロトコルを公開しません。HTTPやHTTPS以外のServiceをインターネットに公開するときは、[Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport)や[Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer)のServiceタイプを使用することが多いです。
|
||||
|
||||
## Ingressを使用する上での前提条件
|
||||
|
||||
Ingressの機能を提供するために[Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)を用意する必要があります。Ingressリソースを作成するのみでは何の効果もありません。
|
||||
|
||||
[ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/)のようなIngressコントローラーのデプロイが必要な場合があります。ユーザーはいくつかの[Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)の中から選択できます。
|
||||
|
||||
理想的には、全てのIngressコントローラーはリファレンスの仕様を満たすべきです。しかし実際には、いくつかのIngressコントローラーは微妙に異なる動作をします。
|
||||
|
||||
{{< note >}}
|
||||
Ingressコントローラーのドキュメントを確認して、選択する際の注意点について理解してください。
|
||||
{{< /note >}}
|
||||
|
||||
## Ingressリソース
|
||||
|
||||
Ingressリソースの最小構成の例は下記のとおりです。
|
||||
|
||||
```yaml
|
||||
apiVersion: networking.k8s.io/v1beta1
|
||||
kind: Ingress
|
||||
metadata:
|
||||
name: test-ingress
|
||||
annotations:
|
||||
nginx.ingress.kubernetes.io/rewrite-target: /
|
||||
spec:
|
||||
rules:
|
||||
- http:
|
||||
paths:
|
||||
- path: /testpath
|
||||
backend:
|
||||
serviceName: test
|
||||
servicePort: 80
|
||||
```
|
||||
|
||||
他の全てのKubernetesリソースと同様に、Ingressは`apiVersion`、`kind`や`metadata`フィールドが必要です。設定ファイルの利用に関する一般的な情報は、[アプリケーションのデプロイ](/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナーの設定](/docs/tasks/configure-pod-container/configure-pod-configmap/)、[リソースの管理](/docs/concepts/cluster-administration/manage-deployment/)を参照してください。
|
||||
Ingressでは、Ingressコントローラーに依存しているいくつかのオプションの設定をするためにアノテーションを使うことが多いです。その例としては、[rewrite-targetアノテーション](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)などがあります。
|
||||
[Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)の種類が異なれば、サポートするアノテーションも異なります。サポートされているアノテーションについて学ぶために、ユーザーが使用するIngressコントローラーのドキュメントを確認してください。
|
||||
|
||||
Ingress [Spec](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)は、ロードバランサーやプロキシーサーバーを設定するために必要な全ての情報を持っています。最も重要なものとして、外部からくる全てのリクエストに対して一致したルールのリストを含みます。IngressリソースはHTTPトラフィックに対してのルールのみサポートしています。
|
||||
|
||||
### Ingressのルール
|
||||
|
||||
各HTTPルールは下記の情報を含みます。
|
||||
|
||||
* オプションで設定可能なホスト名。上記のリソースの例では、ホスト名が指定されていないと、そのルールは指定されたIPアドレスを経由する全てのインバウンドHTTPトラフィックに適用されます。ホスト名が指定されていると(例: foo.bar.com)、そのルールはホストに対して適用されます。
|
||||
* パスのリスト(例: `/testpath`)。各パスには`serviceName`と`servicePort`で定義されるバックエンドが関連づけられます。ロードバランサーがトラフィックを関連づけられたServiceに転送するために、外部からくるリクエストのホスト名とパスが条件と一致させる必要があります。
|
||||
* [Serviceドキュメント](/docs/concepts/services-networking/service/)に書かれているように、バックエンドはServiceとポート名の組み合わせとなります。Ingressで設定されたホスト名とパスのルールに一致するHTTP(とHTTPS)のリクエストは、リスト内のバックエンドに対して送信されます。
|
||||
|
||||
Ingressコントローラーでは、デフォルトのバックエンドが設定されていることがあります。これはSpec内で指定されているパスに一致しないようなリクエストのためのバックエンドです。
|
||||
|
||||
### デフォルトのバックエンド
|
||||
|
||||
ルールが設定されていないIngressは、全てのトラフィックをデフォルトのバックエンドに転送します。このデフォルトのバックエンドは、[Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)のオプション設定であり、Ingressリソースでは指定されていません。
|
||||
|
||||
IngressオブジェクトでHTTPリクエストが1つもホスト名とパスの条件に一致しない時、そのトラフィックはデフォルトのバックエンドに転送されます。
|
||||
|
||||
## Ingressのタイプ
|
||||
|
||||
### 単一ServiceのIngress
|
||||
ユーザーは単一のServiceを公開できるという、Kubernetesのコンセプトがあります([Ingressの代替案](#alternatives)を参照してください)。
|
||||
また、Ingressでこれを実現できます。それはルールを設定せずに*デフォルトのバックエンド* を指定することにより可能です。
|
||||
|
||||
{{< codenew file="service/networking/ingress.yaml" >}}
|
||||
|
||||
`kubectl apply -f`を実行してIngressを作成し、その作成したIngressの状態を確認することができます。
|
||||
|
||||
```shell
|
||||
kubectl get ingress test-ingress
|
||||
```
|
||||
|
||||
```
|
||||
NAME HOSTS ADDRESS PORTS AGE
|
||||
test-ingress * 107.178.254.228 80 59s
|
||||
```
|
||||
|
||||
`107.178.254.228`はIngressコントローラーによって割り当てられたIPで、このIngressを利用するためのものです。
|
||||
|
||||
{{< note >}}
|
||||
IngressコントローラーとロードバランサーがIPアドレス割り当てるのに1、2分ほどかかります。この間、ADDRESSの情報は`<pending>`となっているのを確認できます。
|
||||
{{< /note >}}
|
||||
|
||||
### リクエストのシンプルなルーティング
|
||||
|
||||
ファンアウト設定では単一のIPアドレスのトラフィックを、リクエストされたHTTP URIに基づいて1つ以上のServiceに転送します。Ingressによって、ユーザーはロードバランサーの数を少なくできます。例えば、下記のように設定します。
|
||||
|
||||
```none
|
||||
foo.bar.com -> 178.91.123.132 -> / foo service1:4200
|
||||
/ bar service2:8080
|
||||
```
|
||||
|
||||
Ingressを下記のように設定します。
|
||||
|
||||
```yaml
|
||||
apiVersion: networking.k8s.io/v1beta1
|
||||
kind: Ingress
|
||||
metadata:
|
||||
name: simple-fanout-example
|
||||
annotations:
|
||||
nginx.ingress.kubernetes.io/rewrite-target: /
|
||||
spec:
|
||||
rules:
|
||||
- host: foo.bar.com
|
||||
http:
|
||||
paths:
|
||||
- path: /foo
|
||||
backend:
|
||||
serviceName: service1
|
||||
servicePort: 4200
|
||||
- path: /bar
|
||||
backend:
|
||||
serviceName: service2
|
||||
servicePort: 8080
|
||||
```
|
||||
|
||||
Ingressを`kubectl apply -f`によって作成したとき:
|
||||
|
||||
```shell
|
||||
kubectl describe ingress simple-fanout-example
|
||||
```
|
||||
|
||||
```
|
||||
Name: simple-fanout-example
|
||||
Namespace: default
|
||||
Address: 178.91.123.132
|
||||
Default backend: default-http-backend:80 (10.8.2.3:8080)
|
||||
Rules:
|
||||
Host Path Backends
|
||||
---- ---- --------
|
||||
foo.bar.com
|
||||
/foo service1:4200 (10.8.0.90:4200)
|
||||
/bar service2:8080 (10.8.0.91:8080)
|
||||
Annotations:
|
||||
nginx.ingress.kubernetes.io/rewrite-target: /
|
||||
Events:
|
||||
Type Reason Age From Message
|
||||
---- ------ ---- ---- -------
|
||||
Normal ADD 22s loadbalancer-controller default/test
|
||||
```
|
||||
|
||||
IngressコントローラーはService(`service1`、`service2`)が存在する限り、Ingressの条件を満たす実装固有のロードバランサーを構築します。
|
||||
構築が完了すると、ADDRESSフィールドでロードバランサーのアドレスを確認できます。
|
||||
|
||||
{{< note >}}
|
||||
ユーザーが使用している[Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)に依存しますが、ユーザーはdefault-http-backend[Service](/docs/concepts/services-networking/service/)の作成が必要な場合があります。
|
||||
{{< /note >}}
|
||||
|
||||
### 名前ベースの仮想ホスティング
|
||||
|
||||
名前ベースの仮想ホストは、HTTPトラフィックを同一のIPアドレスの複数のホスト名に転送することをサポートしています。
|
||||
|
||||
```none
|
||||
foo.bar.com --| |-> foo.bar.com service1:80
|
||||
| 178.91.123.132 |
|
||||
bar.foo.com --| |-> bar.foo.com service2:80
|
||||
```
|
||||
|
||||
下記のIngress設定は、ロードバランサーに対して、[Hostヘッダー](https://tools.ietf.org/html/rfc7230#section-5.4)に基づいてリクエストを転送するように指示するものです。
|
||||
|
||||
```yaml
|
||||
apiVersion: networking.k8s.io/v1beta1
|
||||
kind: Ingress
|
||||
metadata:
|
||||
name: name-virtual-host-ingress
|
||||
spec:
|
||||
rules:
|
||||
- host: foo.bar.com
|
||||
http:
|
||||
paths:
|
||||
- backend:
|
||||
serviceName: service1
|
||||
servicePort: 80
|
||||
- host: bar.foo.com
|
||||
http:
|
||||
paths:
|
||||
- backend:
|
||||
serviceName: service2
|
||||
servicePort: 80
|
||||
```
|
||||
|
||||
rules項目でのホストの設定がないIngressを作成すると、IngressコントローラーのIPアドレスに対するwebトラフィックは、要求されている名前ベースの仮想ホストなしにマッチさせることができます。
|
||||
|
||||
例えば、下記のIngressリソースは`first.bar.com`に対するトラフィックを`service1`へ、`second.foo.com`に対するトラフィックを`service2`へ、リクエストにおいてホスト名が指定されていない(リクエストヘッダーがないことを意味します)トラフィックは`service3`へ転送します。
|
||||
|
||||
```yaml
|
||||
apiVersion: networking.k8s.io/v1beta1
|
||||
kind: Ingress
|
||||
metadata:
|
||||
name: name-virtual-host-ingress
|
||||
spec:
|
||||
rules:
|
||||
- host: first.bar.com
|
||||
http:
|
||||
paths:
|
||||
- backend:
|
||||
serviceName: service1
|
||||
servicePort: 80
|
||||
- host: second.foo.com
|
||||
http:
|
||||
paths:
|
||||
- backend:
|
||||
serviceName: service2
|
||||
servicePort: 80
|
||||
- http:
|
||||
paths:
|
||||
- backend:
|
||||
serviceName: service3
|
||||
servicePort: 80
|
||||
```
|
||||
|
||||
### TLS
|
||||
|
||||
TLSの秘密鍵と証明書を含んだ{{< glossary_tooltip term_id="secret" >}}を指定することにより、Ingressをセキュアにできます。現在Ingressは単一のTLSポートである443番ポートのみサポートし、TLS終端を行うことを想定しています。IngressのTLS設定のセクションで異なるホストを指定すると、それらのホストはSNI TLSエクステンション(IngressコントローラーがSNIをサポートしている場合)を介して指定されたホスト名に対し、同じポート上で多重化されます。TLSのSecretは`tls.crt`と`tls.key`というキーを含む必要があり、TLSを使用するための証明書と秘密鍵を含む値となります。下記が例となります。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: testsecret-tls
|
||||
namespace: default
|
||||
data:
|
||||
tls.crt: base64 encoded cert
|
||||
tls.key: base64 encoded key
|
||||
type: kubernetes.io/tls
|
||||
```
|
||||
|
||||
IngressでこのSecretを参照すると、クライアントとロードバランサー間の通信にTLSを使用するようIngressコントローラーに指示することになります。作成したTLS Secretは、`sslexample.foo.com`の完全修飾ドメイン名(FQDN)とも呼ばれる共通名(CN)を含む証明書から作成したものであることを確認する必要があります。
|
||||
|
||||
```yaml
|
||||
apiVersion: networking.k8s.io/v1beta1
|
||||
kind: Ingress
|
||||
metadata:
|
||||
name: tls-example-ingress
|
||||
spec:
|
||||
tls:
|
||||
- hosts:
|
||||
- sslexample.foo.com
|
||||
secretName: testsecret-tls
|
||||
rules:
|
||||
- host: sslexample.foo.com
|
||||
http:
|
||||
paths:
|
||||
- path: /
|
||||
backend:
|
||||
serviceName: service1
|
||||
servicePort: 80
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
Ingressコントローラーによって、サポートされるTLSの機能に違いがあります。利用する環境でTLSがどのように動作するかを理解するために、[nginx](https://git.k8s.io/ingress-nginx/README.md#https)や、[GCE](https://git.k8s.io/ingress-gce/README.md#frontend-https)、他のプラットフォーム固有のIngressコントローラーのドキュメントを確認してください。
|
||||
{{< /note >}}
|
||||
|
||||
### 負荷分散
|
||||
|
||||
Ingressコントローラーは、負荷分散アルゴリズムやバックエンドの重みスキームなど、すべてのIngressに適用されるいくつかの負荷分散ポリシーの設定とともにブートストラップされます。発展した負荷分散のコンセプト(例: セッションの永続化、動的重み付けなど)はIngressによってサポートされていません。代わりに、それらの機能はService用のロードバランサーを介して利用できます。
|
||||
|
||||
Ingressによってヘルスチェックの機能が直接に公開されていない場合でも、Kubernetesにおいて、同等の機能を提供する[Readiness Probe](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)のようなコンセプトが存在することは注目に値します。コントローラーがどのようにヘルスチェックを行うかについては、コントローラーのドキュメントを参照してください([nginx](https://git.k8s.io/ingress-nginx/README.md)、[GCE](https://git.k8s.io/ingress-gce/README.md#health-checks))。
|
||||
|
||||
## Ingressの更新
|
||||
|
||||
リソースを編集することで、既存のIngressに対して新しいホストを追加することができます。
|
||||
|
||||
```shell
|
||||
kubectl describe ingress test
|
||||
```
|
||||
|
||||
```
|
||||
Name: test
|
||||
Namespace: default
|
||||
Address: 178.91.123.132
|
||||
Default backend: default-http-backend:80 (10.8.2.3:8080)
|
||||
Rules:
|
||||
Host Path Backends
|
||||
---- ---- --------
|
||||
foo.bar.com
|
||||
/foo service1:80 (10.8.0.90:80)
|
||||
Annotations:
|
||||
nginx.ingress.kubernetes.io/rewrite-target: /
|
||||
Events:
|
||||
Type Reason Age From Message
|
||||
---- ------ ---- ---- -------
|
||||
Normal ADD 35s loadbalancer-controller default/test
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl edit ingress test
|
||||
```
|
||||
|
||||
このコマンドを実行すると既存の設定をYAMLフォーマットで編集するエディターが表示されます。新しいホストを追加するために、リソースを修正してください。
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
rules:
|
||||
- host: foo.bar.com
|
||||
http:
|
||||
paths:
|
||||
- backend:
|
||||
serviceName: service1
|
||||
servicePort: 80
|
||||
path: /foo
|
||||
- host: bar.baz.com
|
||||
http:
|
||||
paths:
|
||||
- backend:
|
||||
serviceName: service2
|
||||
servicePort: 80
|
||||
path: /foo
|
||||
..
|
||||
```
|
||||
|
||||
変更を保存した後、kubectlはAPIサーバー内のリソースを更新し、Ingressコントローラーに対してロードバランサーの再設定を指示します。
|
||||
|
||||
変更内容を確認してください。
|
||||
|
||||
```shell
|
||||
kubectl describe ingress test
|
||||
```
|
||||
|
||||
```
|
||||
Name: test
|
||||
Namespace: default
|
||||
Address: 178.91.123.132
|
||||
Default backend: default-http-backend:80 (10.8.2.3:8080)
|
||||
Rules:
|
||||
Host Path Backends
|
||||
---- ---- --------
|
||||
foo.bar.com
|
||||
/foo service1:80 (10.8.0.90:80)
|
||||
bar.baz.com
|
||||
/foo service2:80 (10.8.0.91:80)
|
||||
Annotations:
|
||||
nginx.ingress.kubernetes.io/rewrite-target: /
|
||||
Events:
|
||||
Type Reason Age From Message
|
||||
---- ------ ---- ---- -------
|
||||
Normal ADD 45s loadbalancer-controller default/test
|
||||
```
|
||||
|
||||
修正されたIngressのYAMLファイルに対して`kubectl replace -f`を実行することで、同様の結果を得られます。
|
||||
|
||||
## アベイラビリティーゾーンをまたいだ障害について
|
||||
|
||||
障害のあるドメインをまたいでトラフィックを分散する手法は、クラウドプロバイダーによって異なります。詳細に関して、[Ingress コントローラー](/docs/concepts/services-networking/ingress-controllers)のドキュメントを参照してください。複数のクラスターにおいてIngressをデプロイする方法の詳細に関しては[Kubernetes Cluster Federationのドキュメント](https://github.com/kubernetes-sigs/federation-v2)を参照してください。
|
||||
|
||||
## 将来追加予定の内容
|
||||
|
||||
Ingressと関連するリソースの今後の開発については[SIG Network](https://github.com/kubernetes/community/tree/master/sig-network)で行われている議論を確認してください。様々なIngressコントローラーの開発については[Ingress リポジトリー](https://github.com/kubernetes/ingress/tree/master)を確認してください。
|
||||
|
||||
## Ingressの代替案 {#alternatives}
|
||||
|
||||
Ingressリソースに直接関与しない複数の方法でServiceを公開できます。
|
||||
|
||||
下記の2つの使用を検討してください。
|
||||
* [Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer)
|
||||
* [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
* [Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers/)について学ぶ
|
||||
* [MinikubeとNGINXコントローラーでIngressのセットアップを行う](/docs/tasks/access-application-cluster/ingress-minikube)
|
||||
{{% /capture %}}
|
||||
|
|
@ -134,6 +134,13 @@ link-local (169.254.0.0/16 and 224.0.0.0/24 for IPv4, fe80::/64 for IPv6)に設
|
|||
|
||||
ExternalName Serviceはセレクターの代わりにDNS名を使用する特殊なケースのServiceです。さらなる情報は、このドキュメントの後で紹介する[ExternalName](#externalname)を参照ください。
|
||||
|
||||
### エンドポイントスライス
|
||||
{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
|
||||
|
||||
エンドポイントスライスは、Endpointsに対してよりスケーラブルな代替手段を提供できるAPIリソースです。概念的にはEndpointsに非常に似ていますが、エンドポイントスライスを使用すると、ネットワークエンドポイントを複数のリソースに分割できます。デフォルトでは、エンドポイントスライスは、100個のエンドポイントに到達すると「いっぱいである」と見なされ、その時点で追加のエンドポイントスライスが作成され、追加のエンドポイントが保存されます。
|
||||
|
||||
エンドポイントスライスは、[エンドポイントスライスのドキュメント](/docs/concepts/services-networking/endpoint-slices/)にて詳しく説明されている追加の属性と機能を提供します。
|
||||
|
||||
## 仮想IPとサービスプロキシー {#virtual-ips-and-service-proxies}
|
||||
|
||||
Kubernetesクラスターの各Nodeは`kube-proxy`を稼働させています。`kube-proxy`は[`ExternalName`](#externalname)タイプ以外の`Service`用に仮想IPを実装する責務があります。
|
||||
|
|
@ -149,12 +156,6 @@ Serviceにおいてプロキシーを使う理由はいくつかあります。
|
|||
* いくつかのアプリケーションではDNSルックアップを1度だけ行い、その結果を無期限にキャッシュする。
|
||||
* アプリケーションとライブラリーが適切なDNS名の再解決を行ったとしても、DNSレコード上の0もしくは低い値のTTLがDNSに負荷をかけることがあり、管理が難しい。
|
||||
|
||||
### バージョン互換性
|
||||
|
||||
Kubernetes v1.0から、[user-spaceプロキシーモード](#proxy-mode-userspace)を利用できるようになっています。
|
||||
v1.1ではiptablesモードでのプロキシーを追加し、v1.2では、kube-proxyにおいてiptablesモードがデフォルトとなりました。
|
||||
v1.8では、ipvsプロキシーモードが追加されました。
|
||||
|
||||
### user-spaceプロキシーモード {#proxy-mode-userspace}
|
||||
|
||||
このモードでは、kube-proxyはServiceやEndpointオブジェクトの追加・削除をチェックするために、Kubernetes Masterを監視します。
|
||||
|
|
@ -389,12 +390,11 @@ spec:
|
|||
port: 80
|
||||
targetPort: 9376
|
||||
clusterIP: 10.0.171.239
|
||||
loadBalancerIP: 78.11.24.19
|
||||
type: LoadBalancer
|
||||
status:
|
||||
loadBalancer:
|
||||
ingress:
|
||||
- ip: 146.148.47.155
|
||||
- ip: 192.0.2.127
|
||||
```
|
||||
|
||||
外部のロードバランサーからのトラフィックはバックエンドのPodに直接転送されます。クラウドプロバイダーはどのようにそのリクエストをバランシングするかを決めます。
|
||||
|
|
@ -437,9 +437,6 @@ metadata:
|
|||
cloud.google.com/load-balancer-type: "Internal"
|
||||
[...]
|
||||
```
|
||||
|
||||
Kubernetes1.7.0から1.7.3のMasterに対しては、`cloud.google.com/load-balancer-type: "internal"`を使用します。
|
||||
さらなる情報については、[docs](https://cloud.google.com/kubernetes-engine/docs/internal-load-balancing)を参照してください。
|
||||
{{% /tab %}}
|
||||
{{% tab name="AWS" %}}
|
||||
```yaml
|
||||
|
|
@ -481,6 +478,15 @@ metadata:
|
|||
[...]
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="Tencent Cloud" %}}
|
||||
```yaml
|
||||
[...]
|
||||
metadata:
|
||||
annotations:
|
||||
service.kubernetes.io/qcloud-loadbalancer-internal-subnetid: subnet-xxxxx
|
||||
[...]
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
|
||||
|
|
@ -630,13 +636,11 @@ AWS上でのELB Service用のアクセスログを管理するためにはいく
|
|||
# ELBに追加される予定のセキュリティーグループのリスト
|
||||
```
|
||||
|
||||
#### AWSでのNetwork Load Balancerのサポート [α版] {#aws-nlb-support}
|
||||
#### AWSでのNetwork Load Balancerのサポート {#aws-nlb-support}
|
||||
|
||||
{{< warning >}}
|
||||
これはα版の機能で、プロダクション環境でのクラスターでの使用はまだ推奨しません。
|
||||
{{< /warning >}}
|
||||
{{< feature-state for_k8s_version="v1.15" state="beta" >}}
|
||||
|
||||
Kubernetes v1.9.0から、ServiceとAWS Network Load Balancer(NLB)を組み合わせることができます。AWSでのネットワークロードバランサーを使用するためには、`service.beta.kubernetes.io/aws-load-balancer-type`というアノテーションの値を`nlb`に設定してください。
|
||||
AWSでNetwork Load Balancerを使用するには、値を`nlb`に設定してアノテーション`service.beta.kubernetes.io/aws-load-balancer-type`を付与します。
|
||||
|
||||
```yaml
|
||||
metadata:
|
||||
|
|
@ -681,6 +685,38 @@ spec:
|
|||
|
||||
{{< /note >}}
|
||||
|
||||
#### Tencent Kubernetes Engine（TKE）におけるその他のCLBアノテーション
|
||||
|
||||
以下に示すように、TKEでCloud Load Balancerを管理するためのその他のアノテーションがあります。
|
||||
|
||||
```yaml
|
||||
metadata:
|
||||
name: my-service
|
||||
annotations:
|
||||
# 指定したノードでロードバランサーをバインドします
|
||||
service.kubernetes.io/qcloud-loadbalancer-backends-label: key in (value1, value2)
|
||||
# 既存のロードバランサーのID
|
||||
service.kubernetes.io/tke-existed-lbid：lb-6swtxxxx
|
||||
|
||||
# ロードバランサー(LB)のカスタムパラメーターは、LBタイプの変更をまだサポートしていません
|
||||
service.kubernetes.io/service.extensiveParameters: ""
|
||||
|
||||
# LBリスナーのカスタムパラメーター
|
||||
service.kubernetes.io/service.listenerParameters: ""
|
||||
|
||||
# ロードバランサーのタイプを指定します
|
||||
# 有効な値: classic(Classic Cloud Load Balancer)またはapplication(Application Cloud Load Balancer)
|
||||
service.kubernetes.io/loadbalance-type: xxxxx
|
||||
# パブリックネットワーク帯域幅の課金方法を指定します
|
||||
# 有効な値: TRAFFIC_POSTPAID_BY_HOUR(bill-by-traffic)およびBANDWIDTH_POSTPAID_BY_HOUR(bill-by-bandwidth)
|
||||
service.kubernetes.io/qcloud-loadbalancer-internet-charge-type: xxxxxx
|
||||
# 帯域幅の値を指定します(値の範囲：[1-2000] Mbps)。
|
||||
service.kubernetes.io/qcloud-loadbalancer-internet-max-bandwidth-out: "10"
|
||||
# この注釈が設定されている場合、ロードバランサーはポッドが実行されているノードのみを登録します
|
||||
# そうでない場合、すべてのノードが登録されます
|
||||
service.kubernetes.io/local-svc-only-bind-node-with-pod: true
|
||||
```
|
||||
|
||||
### ExternalName タイプ {#externalname}
|
||||
|
||||
ExternalNameタイプのServiceは、ServiceをDNS名とマッピングし、`my-service`や`cassandra`というような従来のラベルセレクターとはマッピングしません。
|
||||
|
|
@ -708,6 +744,12 @@ IPアドレスをハードコードする場合、[Headless Service](#headless-s
|
|||
`my-service`へのアクセスは、他のServiceと同じ方法ですが、再接続する際はプロキシーや転送を介して行うよりも、DNSレベルで行われることが決定的に異なる点となります。
|
||||
後にユーザーが使用しているデータベースをクラスター内に移行することになった後は、Podを起動させ、適切なラベルセレクターやEndpointを追加し、Serviceの`type`を変更します。
|
||||
|
||||
{{< warning >}}
|
||||
HTTPやHTTPSなどの一般的なプロトコルでExternalNameを使用する際に問題が発生する場合があります。ExternalNameを使用する場合、クラスター内のクライアントが使用するホスト名は、ExternalNameが参照する名前とは異なります。
|
||||
|
||||
ホスト名を使用するプロトコルの場合、この違いによりエラーまたは予期しない応答が発生する場合があります。HTTPリクエストには、オリジンサーバーが認識しない`Host:`ヘッダーがあります。TLSサーバーは、クライアントが接続したホスト名に一致する証明書を提供できません。
|
||||
{{< /warning >}}
|
||||
|
||||
{{< note >}}
|
||||
このセクションは、[Alen Komljen](https://akomljen.com/)による[Kubernetes Tips - Part1](https://akomljen.com/kubernetes-tips-part-1/)というブログポストを参考にしています。
|
||||
|
||||
|
|
@ -905,5 +947,6 @@ Kubernetesプロジェクトは、現在利用可能なClusterIP、NodePortやLo
|
|||
|
||||
* [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)を参照してください。
|
||||
* [Ingress](/docs/concepts/services-networking/ingress/)を参照してください。
|
||||
* [Endpoint Slices](/docs/concepts/services-networking/endpoint-slices/)を参照してください。
|
||||
|
||||
{{% /capture %}}
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: "Storage"
|
||||
title: "ストレージ"
|
||||
weight: 70
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: "Workloads"
|
||||
title: "ワークロード"
|
||||
weight: 50
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,4 @@
|
|||
---
|
||||
title: "Controllers"
|
||||
title: "コントローラー"
|
||||
weight: 20
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,999 @@
|
|||
---
|
||||
title: Deployment
|
||||
feature:
|
||||
title: 自動化されたロールアウトとロールバック
|
||||
description: >
|
||||
Kubernetesはアプリケーションや設定への変更を段階的に行い、アプリケーションの状態を監視しながら、全てのインスタンスが同時停止しないようにします。更新に問題が起きたとき、Kubernetesは変更のロールバックを行います。進化を続けるDeploymnetのエコシステムを活用してください。
|
||||
|
||||
content_template: templates/concept
|
||||
weight: 30
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
_Deployment_ コントローラーは[Pod](/docs/concepts/workloads/pods/pod/)と[ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)の宣言的なアップデート機能を提供します。
|
||||
|
||||
ユーザーはDeploymentにおいて_理想的な状態_ を定義し、Deploymentコントローラーは指定された頻度で現在の状態を理想的な状態に変更させます。ユーザーはDeploymentを定義して、新しいReplicaSetを作成したり、既存のDeploymentを削除して新しいDeploymentで全てのリソースを適用できます。
|
||||
|
||||
{{< note >}}
|
||||
Deploymentによって作成されたReplicaSetを管理しないでください。ユーザーのユースケースが下記の項目をカバーできていない場合はメインのKubernetesリポジトリーにイシューを作成することを検討してください。
|
||||
{{< /note >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## ユースケース
|
||||
|
||||
下記の項目はDeploymentの典型的なユースケースです。
|
||||
|
||||
* ReplicaSetをロールアウトするために[Deploymentの作成](#creating-a-deployment)を行う: ReplicaSetはバックグラウンドでPodを作成します。Podの作成が完了したかどうかは、ロールアウトのステータスを確認してください。
|
||||
* DeploymentのPodTemplateSpecを更新することにより[Podの新しい状態を宣言する](#updating-a-deployment): 新しいReplicaSetが作成され、Deploymentは指定された頻度で古いReplicaSetから新しいReplicaSetへのPodの移行を管理します。新しいReplicaSetはDeploymentのリビジョンを更新します。
|
||||
* Deploymentの現在の状態が不安定な場合、[Deploymentのロールバック](#rolling-back-a-deployment)をする: ロールバックによる各更新作業は、Deploymentのリビジョンを更新します。
|
||||
* より多くの負荷をさばけるように、[Deploymentをスケールアップ](#scaling-a-deployment)する
|
||||
* PodTemplateSpecに対する複数の修正を適用するために[Deploymentを停止(Pause)し](#pausing-and-resuming-a-deployment)、それを再開して新しいロールアウトを開始する。
|
||||
* 今後必要としない[古いReplicaSetのクリーンアップ](#clean-up-policy)
|
||||
|
||||
## Deploymentの作成 {#creating-a-deployment}
|
||||
|
||||
下記の内容はDeploymentの例です。これは`nginx`Podのレプリカを3つ持つReplicaSetを作成します。
|
||||
|
||||
{{< codenew file="controllers/nginx-deployment.yaml" >}}
|
||||
|
||||
この例において、
|
||||
|
||||
* `nginx-deployment`という名前のDeploymentが作成され、`.metadata.name`フィールドで名前を指定します。
|
||||
* Deploymentは3つのレプリカPodを作成し、`replicas`フィールドによってレプリカ数を指定します。
|
||||
* `selector`フィールドは、Deploymentが管理するPodのラベルを定義します。このケースにおいて、ユーザーはPodテンプレートにて定義されたラベル(`app: nginx`)を選択します。しかし、PodTemplate自体がそのルールを満たす限り、さらに洗練された方法でセレクターを指定することができます。
|
||||
{{< note >}}
|
||||
`matchLabels`フィールドは、キーとバリューのペアのマップとなります。`matchLabels`マップにおいて、{key, value}というペアは、keyというフィールドの値が"key"で、その演算子が"In"で、値の配列が"value"のみ含むような`matchExpressions`の要素と等しいです。
|
||||
`matchLabels`と`matchExpressions`の両方が設定された場合、条件に一致するには両方とも満たす必要があります。
|
||||
{{< /note >}}
|
||||
* `template`フィールドは、下記のサブフィールドを持ちます。:
|
||||
* Podは`labels`フィールドによって指定された`app: nginx`というラベルがつけられる
|
||||
* PodTemplateの仕様もしくは、`.template.spec`フィールドは、このPodは`nginx`という名前のコンテナーを1つ稼働させ、それは`nginx`というさせ、[Docker Hub](https://hub.docker.com/)にある`nginx`のバージョン1.7.9を使うことを示します
|
||||
* 1つのコンテナを作成し、`name`フィールドを使って`nginx`という名前をつけます
|
||||
|
||||
上記のDeploymentを作成するために、以下に示すステップにしたがってください。
|
||||
作成を始める前に、ユーザーのKubernetesクラスターが稼働していることを確認してください。
|
||||
|
||||
1. 下記のコマンドを実行してDeploymentを作成してください。
|
||||
|
||||
{{< note >}}
|
||||
実行したコマンドを`kubernetes.io/change-cause`というアノテーションに記録するために`--record`フラグを指定できます。これは将来的な問題の調査のために有効です。例えば、各Deploymentのリビジョンにおいて実行されたコマンドを見るときに便利です。
|
||||
{{< /note >}}
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
|
||||
```
|
||||
|
||||
2. Deploymentが作成されたことを確認するために、`kubectl get deployment`を実行してください。Deploymentがまだ作成中の場合、コマンドの実行結果は下記のとおりです。
|
||||
```shell
|
||||
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
|
||||
nginx-deployment 3 0 0 0 1s
|
||||
```
|
||||
ユーザーのクラスターにおいてDeploymentを調査するとき、下記のフィールドが出力されます。
|
||||
|
||||
* `NAME` クラスター内のDeploymentの名前を表示する
|
||||
* `DESIRED` アプリケーションの理想的な_replicas_ の値を表示する: これはDeploymentを作成したときに定義したもので、これが_理想的な状態_ と呼ばれるものです。
|
||||
* `CURRENT` 現在稼働中のレプリカ数
|
||||
* `UP-TO-DATE` 理想的な状態にするために、アップデートが完了したレプリカ数
|
||||
* `AVAILABLE` ユーザーが利用可能なレプリカ数
|
||||
* `AGE` アプリケーションが稼働してからの時間
|
||||
|
||||
上記のyamlの例だと、`.spec.replicas`フィールドの値によると、理想的なレプリカ数は3です。
|
||||
|
||||
3. Deploymentのロールアウトステータスを確認するために、`kubectl rollout status deployment.v1.apps/nginx-deployment`を実行してください。コマンドの実行結果は下記のとおりです。
|
||||
```shell
|
||||
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
|
||||
deployment.apps/nginx-deployment successfully rolled out
|
||||
```
|
||||
|
||||
4. 数秒後、再度`kubectl get deployments`を実行してください。コマンドの実行結果は下記のとおりです。
|
||||
```shell
|
||||
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
|
||||
nginx-deployment 3 3 3 3 18s
|
||||
```
|
||||
Deploymentが3つ全てのレプリカを作成して、全てのレプリカが最新(Podが最新のPodテンプレートを含んでいる)になり、利用可能となっていることを確認してください。
|
||||
|
||||
5. Deploymentによって作成されたReplicaSet (`rs`)を確認するには`kubectl get rs`を実行してください。コマンドの実行結果は下記のとおりです。
|
||||
|
||||
```shell
|
||||
NAME DESIRED CURRENT READY AGE
|
||||
nginx-deployment-75675f5897 3 3 3 18s
|
||||
```
|
||||
ReplicaSetの名前は`[Deployment名]-[ランダム文字列]`という形式になることに注意してください。ランダム文字列はランダムに生成され、pod-template-hashをシードとして使用します。
|
||||
|
||||
6. 各Podにラベルが自動的に付けられるのを確認するには`kubectl get pods --show-labels`を実行してください。コマンドの実行結果は下記のとおりです。
|
||||
```shell
|
||||
NAME READY STATUS RESTARTS AGE LABELS
|
||||
nginx-deployment-75675f5897-7ci7o 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453
|
||||
nginx-deployment-75675f5897-kzszj 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453
|
||||
nginx-deployment-75675f5897-qqcnn 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453
|
||||
```
|
||||
作成されたReplicaSetは`nginx`Podを3つ作成することを保証します。
|
||||
|
||||
{{< note >}}
|
||||
Deploymentに対して適切なセレクターとPodテンプレートのラベルを設定する必要があります(このケースでは`app: nginx`)。ラベルやセレクターを他のコントローラーと重複させないでください(他のDeploymentやStatefulSetを含む)。Kubernetesはユーザがラベルを重複させることを止めないため、複数のコントローラーでセレクターの重複が発生すると、コントローラー間で衝突し予期せぬふるまいをすることになります。
|
||||
{{< /note >}}
|
||||
|
||||
### pod-template-hashラベル
|
||||
|
||||
{{< note >}}
|
||||
このラベルを変更しないでください。
|
||||
{{< /note >}}
|
||||
|
||||
`pod-template-hash`ラベルはDeploymentコントローラーによってDeploymentが作成し適用した各ReplicaSetに対して追加されます。
|
||||
|
||||
このラベルはDeploymentが管理するReplicaSetが重複しないことを保証します。このラベルはReplicaSetの`PodTemplate`をハッシュ化することにより生成され、生成されたハッシュ値はラベル値としてReplicaSetセレクター、Podテンプレートラベル、ReplicaSetが作成した全てのPodに対して追加されます。
|
||||
|
||||
## Deploymentの更新
|
||||
|
||||
{{< note >}}
|
||||
Deploymentのロールアウトは、DeploymentのPodテンプレート(この場合`.spec.template`)が変更された場合にのみトリガーされます。例えばテンプレートのラベルもしくはコンテナーイメージが更新された場合です。Deploymentのスケールのような更新では、ロールアウトはトリガーされません。
|
||||
{{< /note >}}
|
||||
|
||||
Deploymentを更新するには下記のステップに従ってください。
|
||||
|
||||
1. nginxのPodで、`nginx:1.7.9`イメージの代わりに`nginx:1.9.1`を使うように更新します。
|
||||
|
||||
```shell
|
||||
kubectl --record deployment.apps/nginx-deployment set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1
|
||||
```
|
||||
|
||||
実行結果は下記のとおりです。
|
||||
```
|
||||
deployment.apps/nginx-deployment image updated
|
||||
```
|
||||
|
||||
また、Deploymentを`編集`して、`.spec.template.spec.containers[0].image`を`nginx:1.7.9`から`nginx:1.9.1`に変更することができます。
|
||||
|
||||
```shell
|
||||
kubectl edit deployment.v1.apps/nginx-deployment
|
||||
```
|
||||
|
||||
実行結果は下記のとおりです。
|
||||
```
|
||||
deployment.apps/nginx-deployment edited
|
||||
```
|
||||
|
||||
2. ロールアウトのステータスを確認するには、下記のコマンドを実行してください。
|
||||
|
||||
```shell
|
||||
kubectl rollout status deployment.v1.apps/nginx-deployment
|
||||
```
|
||||
|
||||
実行結果は下記のとおりです。
|
||||
```
|
||||
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
|
||||
```
|
||||
もしくは
|
||||
```
|
||||
deployment.apps/nginx-deployment successfully rolled out
|
||||
```
|
||||
|
||||
更新されたDeploymentのさらなる情報を取得するには、下記を確認してください。
|
||||
|
||||
* ロールアウトが成功したあと、`kubectl get deployments`を実行してDeploymentを確認できます。
|
||||
実行結果は下記のとおりです。
|
||||
```
|
||||
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
|
||||
nginx-deployment 3 3 3 3 36s
|
||||
```
|
||||
|
||||
* Deploymentが新しいReplicaSetを作成してPodを更新させたり、新しいReplicaSetのレプリカを3にスケールアップさせたり、古いReplicaSetのレプリカを0にスケールダウンさせるのを確認するには`kubectl get rs`を実行してください。
|
||||
|
||||
```shell
|
||||
kubectl get rs
|
||||
```
|
||||
|
||||
実行結果は下記のとおりです。
|
||||
```
|
||||
NAME DESIRED CURRENT READY AGE
|
||||
nginx-deployment-1564180365 3 3 3 6s
|
||||
nginx-deployment-2035384211 0 0 0 36s
|
||||
```
|
||||
|
||||
* `get pods`を実行させると、新しいPodのみ確認できます。
|
||||
|
||||
```shell
|
||||
kubectl get pods
|
||||
```
|
||||
|
||||
実行結果は下記のとおりです。
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
nginx-deployment-1564180365-khku8 1/1 Running 0 14s
|
||||
nginx-deployment-1564180365-nacti 1/1 Running 0 14s
|
||||
nginx-deployment-1564180365-z9gth 1/1 Running 0 14s
|
||||
```
|
||||
|
||||
次にPodを更新させたいときは、DeploymentのPodテンプレートを再度更新するだけです。
|
||||
|
||||
Deploymentは、Podが更新されている間に特定の数のPodのみ停止状態になることを保証します。デフォルトでは、目標とするPod数の少なくとも25%が停止状態になることを保証します(25% max unavailable)。
|
||||
|
||||
また、DeploymentはPodが更新されている間に、目標とするPod数を特定の数まで超えてPodを稼働させることを保証します。デフォルトでは、目標とするPod数に対して最大でも25%を超えてPodを稼働させることを保証します(25% max surge)。
|
||||
|
||||
例えば、上記で説明したDeploymentの状態を注意深く見ると、最初に新しいPodが作成され、次に古いPodが削除されるのを確認できます。十分な数の新しいPodが稼働するまでは、Deploymentは古いPodを削除しません。また十分な数の古いPodが削除しない限り新しいPodは作成されません。少なくとも2つのPodが利用可能で、最大でもトータルで4つのPodが利用可能になっていることを保証します。
|
||||
|
||||
* Deploymentの詳細情報を取得します。
|
||||
```shell
|
||||
kubectl describe deployments
|
||||
```
|
||||
実行結果は下記のとおりです。
|
||||
```
|
||||
Name: nginx-deployment
|
||||
Namespace: default
|
||||
CreationTimestamp: Thu, 30 Nov 2017 10:56:25 +0000
|
||||
Labels: app=nginx
|
||||
Annotations: deployment.kubernetes.io/revision=2
|
||||
Selector: app=nginx
|
||||
Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable
|
||||
StrategyType: RollingUpdate
|
||||
MinReadySeconds: 0
|
||||
RollingUpdateStrategy: 25% max unavailable, 25% max surge
|
||||
Pod Template:
|
||||
Labels: app=nginx
|
||||
Containers:
|
||||
nginx:
|
||||
Image: nginx:1.9.1
|
||||
Port: 80/TCP
|
||||
Environment: <none>
|
||||
Mounts: <none>
|
||||
Volumes: <none>
|
||||
Conditions:
|
||||
Type Status Reason
|
||||
---- ------ ------
|
||||
Available True MinimumReplicasAvailable
|
||||
Progressing True NewReplicaSetAvailable
|
||||
OldReplicaSets: <none>
|
||||
NewReplicaSet: nginx-deployment-1564180365 (3/3 replicas created)
|
||||
Events:
|
||||
Type Reason Age From Message
|
||||
---- ------ ---- ---- -------
|
||||
Normal ScalingReplicaSet 2m deployment-controller Scaled up replica set nginx-deployment-2035384211 to 3
|
||||
Normal ScalingReplicaSet 24s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 1
|
||||
Normal ScalingReplicaSet 22s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 2
|
||||
Normal ScalingReplicaSet 22s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 2
|
||||
Normal ScalingReplicaSet 19s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 1
|
||||
Normal ScalingReplicaSet 19s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 3
|
||||
Normal ScalingReplicaSet 14s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 0
|
||||
```
|
||||
最初にDeploymentを作成した時、ReplicaSet(nginx-deployment-2035384211)を作成してすぐにレプリカ数を3にスケールするのを確認できます。Deploymentを更新すると新しいReplicaSet(nginx-deployment-1564180365)を作成してレプリカ数を1にスケールアップし、古いReplicaSeetを2にスケールダウンさせます。これは常に最低でも2つのPodが利用可能で、かつ最大4つのPodが作成されている状態にするためです。Deploymentは同じローリングアップ戦略に従って新しいReplicaSetのスケールアップと古いReplicaSetのスケールダウンを続けます。最終的に新しいReplicaSetを3にスケールアップさせ、古いReplicaSetを0にスケールダウンさせます。
|
||||
|
||||
### ロールオーバー (リアルタイムでの複数のPodの更新)
|
||||
|
||||
Deploymentコントローラーにより、新しいDeploymentが観測される度にReplicaSetが作成され、理想とするレプリカ数のPodを作成します。Deploymentが更新されると、既存のReplicaSetが管理するPodのラベルが`.spec.selector`にマッチするが、テンプレートが`.spec.template`にマッチしない場合はスケールダウンされます。最終的に、新しいReplicaSetは`.spec.replicas`の値にスケールアップされ、古いReplicaSetは0にスケールダウンされます。
|
||||
|
||||
Deploymentのロールアウトが進行中にDeploymentを更新すると、Deploymentは更新する毎に新しいReplicaSetを作成してスケールアップさせ、以前にスケールアップしたReplicaSetのロールオーバーを行います。Deploymentは更新前のReplicaSetを古いReplicaSetのリストに追加し、スケールダウンを開始します。
|
||||
|
||||
例えば、5つのレプリカを持つ`nginx:1.7.9`のDeploymentを作成し、`nginx:1.7.9`の3つのレプリカが作成されているときに5つのレプリカを持つ`nginx:1.9.1`に更新します。このケースではDeploymentは作成済みの`nginx:1.7.9`の3つのPodをすぐに削除し、`nginx:1.9.1`のPodの作成を開始します。`nginx:1.7.9`の5つのレプリカを全て作成するのを待つことはありません。
|
||||
|
||||
### ラベルセレクターの更新
|
||||
|
||||
通常、ラベルセレクターを更新することは推奨されません。事前にラベルセレクターの使い方を計画しておきましょう。いかなる場合であっても更新が必要なときは十分に注意を払い、変更時の影響範囲を把握しておきましょう。
|
||||
|
||||
{{< note >}}
|
||||
`apps/v1`API バージョンにおいて、Deploymentのラベルセレクターは作成後に不変となります。
|
||||
{{< /note >}}
|
||||
|
||||
* セレクターの追加は、Deployment Specのテンプレートラベルも新しいラベルで更新する必要があります。そうでない場合はバリデーションエラーが返されます。この変更は重複がない更新となります。これは新しいセレクターは古いセレクターを持つReplicaSetとPodを選択せず、結果として古い全てのReplicaSetがみなし子状態になり、新しいReplicaSetを作成することを意味します。
|
||||
* セレクターの更新により、セレクターキー内の既存の値が変更されます。これにより、セレクターの追加と同じふるまいをします。
|
||||
* セレクターの削除により、Deploymentのセレクターから存在している値を削除します。これはPodテンプレートのラベルに関する変更を要求しません。既存のReplicaSetはみなし子状態にならず、新しいReplicaSetは作成されませんが、削除されたラベルは既存のPodとReplicaSetでは残り続けます。
|
||||
|
||||
## Deploymentのロールバック {#rolling-back-a-deployment}
|
||||
|
||||
Deploymentのロールバックを行いたい場合があります。例えば、Deploymentがクラッシュ状態になりそれがループしたりする不安定なときです。デフォルトではユーザーがいつでもロールバックできるようにDeploymentの全てのロールアウト履歴がシステムに保持されます(リビジョン履歴の上限は設定することで変更可能です)。
|
||||
|
||||
{{< note >}}
|
||||
Deploymentのリビジョンは、Deploymentのロールアウトがトリガーされた時に作成されます。これはDeploymentのPodテンプレート(`.spec.template`)が変更されたときのみ新しいリビジョンが作成されることを意味します。Deploymentのスケーリングなど、他の種類の更新においてはDeploymentのリビジョンは作成されません。これは手動もしくはオートスケーリングを同時に行うことができるようにするためです。これは過去のリビジョンにロールバックするとき、DeploymentのPodテンプレートの箇所のみロールバックされることを意味します。
|
||||
{{< /note >}}
|
||||
|
||||
* `nginx:1.9.1`の代わりに`nginx:1.91`というイメージに更新して、Deploymentの更新中にタイプミスをしたと仮定します。
|
||||
|
||||
```shell
|
||||
kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.91 --record=true
|
||||
```
|
||||
|
||||
実行結果は下記のとおりです。
|
||||
```
|
||||
deployment.apps/nginx-deployment image updated
|
||||
```
|
||||
|
||||
* このロールアウトはうまくいきません。ユーザーロールアウトのステータスを見ることでロールアウトがうまくいくか確認できます。
|
||||
|
||||
```shell
|
||||
kubectl rollout status deployment.v1.apps/nginx-deployment
|
||||
```
|
||||
|
||||
実行結果は下記のとおりです。
|
||||
```
|
||||
Waiting for rollout to finish: 1 out of 3 new replicas have been updated...
|
||||
```
|
||||
|
||||
* ロールアウトのステータスの確認は、Ctrl-Cを押すことで停止できます。ロールアウトがうまく行かないときは、[Deploymentのステータス](#deployment-status)を読んでさらなる情報を得てください。
|
||||
|
||||
* 古いレプリカ数(`nginx-deployment-1564180365` and `nginx-deployment-2035384211`)が2になっていることを確認でき、新しいレプリカ数(nginx-deployment-3066724191)は1になっています。
|
||||
|
||||
```shell
|
||||
kubectl get rs
|
||||
```
|
||||
|
||||
実行結果は下記のとおりです。
|
||||
```
|
||||
NAME DESIRED CURRENT READY AGE
|
||||
nginx-deployment-1564180365 3 3 3 25s
|
||||
nginx-deployment-2035384211 0 0 0 36s
|
||||
nginx-deployment-3066724191 1 1 0 6s
|
||||
```
|
||||
|
||||
* 作成されたPodを確認していると、新しいReplicaSetによって作成された1つのPodはコンテナイメージのpullに失敗し続けているのがわかります。
|
||||
|
||||
```shell
|
||||
kubectl get pods
|
||||
```
|
||||
|
||||
実行結果は下記のとおりです。
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
nginx-deployment-1564180365-70iae 1/1 Running 0 25s
|
||||
nginx-deployment-1564180365-jbqqo 1/1 Running 0 25s
|
||||
nginx-deployment-1564180365-hysrc 1/1 Running 0 25s
|
||||
nginx-deployment-3066724191-08mng 0/1 ImagePullBackOff 0 6s
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
Deploymentコントローラーは、この悪い状態のロールアウトを自動的に停止し、新しいReplicaSetのスケールアップを止めます。これはユーザーが指定したローリングアップデートに関するパラメータ(特に`maxUnavailable`)に依存します。デフォルトではKubernetesがこの値を25%に設定します。
|
||||
{{< /note >}}
|
||||
|
||||
* Deploymentの詳細情報を取得します。
|
||||
```shell
|
||||
kubectl describe deployment
|
||||
```
|
||||
|
||||
実行結果は下記のとおりです。
|
||||
```
|
||||
Name: nginx-deployment
|
||||
Namespace: default
|
||||
CreationTimestamp: Tue, 15 Mar 2016 14:48:04 -0700
|
||||
Labels: app=nginx
|
||||
Selector: app=nginx
|
||||
Replicas: 3 desired | 1 updated | 4 total | 3 available | 1 unavailable
|
||||
StrategyType: RollingUpdate
|
||||
MinReadySeconds: 0
|
||||
RollingUpdateStrategy: 25% max unavailable, 25% max surge
|
||||
Pod Template:
|
||||
Labels: app=nginx
|
||||
Containers:
|
||||
nginx:
|
||||
Image: nginx:1.91
|
||||
Port: 80/TCP
|
||||
Host Port: 0/TCP
|
||||
Environment: <none>
|
||||
Mounts: <none>
|
||||
Volumes: <none>
|
||||
Conditions:
|
||||
Type Status Reason
|
||||
---- ------ ------
|
||||
Available True MinimumReplicasAvailable
|
||||
Progressing True ReplicaSetUpdated
|
||||
OldReplicaSets: nginx-deployment-1564180365 (3/3 replicas created)
|
||||
NewReplicaSet: nginx-deployment-3066724191 (1/1 replicas created)
|
||||
Events:
|
||||
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
|
||||
--------- -------- ----- ---- ------------- -------- ------ -------
|
||||
1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-2035384211 to 3
|
||||
22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 1
|
||||
22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 2
|
||||
22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 2
|
||||
21s 21s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 1
|
||||
21s 21s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 3
|
||||
13s 13s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 0
|
||||
13s 13s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-3066724191 to 1
|
||||
```
|
||||
|
||||
これを修正するために、Deploymentを安定した状態の過去のリビジョンに更新する必要があります。
|
||||
|
||||
### Deploymentのロールアウト履歴の確認
|
||||
|
||||
ロールアウトの履歴を確認するには、下記の手順に従って下さい。
|
||||
|
||||
1. 最初に、Deploymentのリビジョンを確認します。
|
||||
```shell
|
||||
kubectl rollout history deployment.v1.apps/nginx-deployment
|
||||
```
|
||||
実行結果は下記のとおりです。
|
||||
```
|
||||
deployments "nginx-deployment"
|
||||
REVISION CHANGE-CAUSE
|
||||
1 kubectl apply --filename=https://k8s.io/examples/controllers/nginx-deployment.yaml --record=true
|
||||
2 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true
|
||||
3 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.91 --record=true
|
||||
```
|
||||
|
||||
`CHANGE-CAUSE`はリビジョンの作成時にDeploymentの`kubernetes.io/change-cause`アノテーションからリビジョンにコピーされます。下記の手段により`CHANGE-CAUSE`メッセージを指定できます。
|
||||
|
||||
* `kubectl annotate deployment.v1.apps/nginx-deployment kubernetes.io/change-cause="image updated to 1.9.1"`の実行によりアノテーションを追加する。
|
||||
* リソースの変更時に`kubectl`コマンドの内容を記録するために`--record`フラグを追加する。
|
||||
* リソースのマニフェストを手動で編集する。
|
||||
|
||||
2. 各リビジョンの詳細を確認するためには下記のコマンドを実行してください。
|
||||
```shell
|
||||
kubectl rollout history deployment.v1.apps/nginx-deployment --revision=2
|
||||
```
|
||||
|
||||
実行結果は下記のとおりです。
|
||||
```
|
||||
deployments "nginx-deployment" revision 2
|
||||
Labels: app=nginx
|
||||
pod-template-hash=1159050644
|
||||
Annotations: kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true
|
||||
Containers:
|
||||
nginx:
|
||||
Image: nginx:1.9.1
|
||||
Port: 80/TCP
|
||||
QoS Tier:
|
||||
cpu: BestEffort
|
||||
memory: BestEffort
|
||||
Environment Variables: <none>
|
||||
No volumes.
|
||||
```
|
||||
|
||||
### 過去のリビジョンにロールバックする {#rolling-back-to-a-previous-revision}
|
||||
現在のリビジョンから過去のリビジョン(リビジョン番号2)にロールバックさせるには、下記の手順に従ってください。
|
||||
|
||||
1. 現在のリビジョンから過去のリビジョンにロールバックします。
|
||||
```shell
|
||||
kubectl rollout undo deployment.v1.apps/nginx-deployment
|
||||
```
|
||||
|
||||
実行結果は下記のとおりです。
|
||||
```
|
||||
deployment.apps/nginx-deployment
|
||||
```
|
||||
その他に、`--to-revision`を指定することにより特定のリビジョンにロールバックできます。
|
||||
|
||||
```shell
|
||||
kubectl rollout undo deployment.v1.apps/nginx-deployment --to-revision=2
|
||||
```
|
||||
|
||||
実行結果は下記のとおりです。
|
||||
```
|
||||
deployment.apps/nginx-deployment
|
||||
```
|
||||
|
||||
ロールアウトに関連したコマンドのさらなる情報は[`kubectl rollout`](/docs/reference/generated/kubectl/kubectl-commands#rollout)を参照してください。
|
||||
|
||||
Deploymentが過去の安定したリビジョンにロールバックされました。Deploymentコントローラーによって、リビジョン番号2にロールバックする`DeploymentRollback`イベントが作成されたのを確認できます。
|
||||
|
||||
2. ロールバックが成功し、Deploymentが正常に稼働していることを確認するために、下記のコマンドを実行してください。
|
||||
```shell
|
||||
kubectl get deployment nginx-deployment
|
||||
```
|
||||
|
||||
実行結果は下記のとおりです。
|
||||
```
|
||||
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
|
||||
nginx-deployment 3 3 3 3 30m
|
||||
```
|
||||
3. Deploymentの詳細情報を取得します。
|
||||
```shell
|
||||
kubectl describe deployment nginx-deployment
|
||||
```
|
||||
実行結果は下記のとおりです。
|
||||
```
|
||||
Name: nginx-deployment
|
||||
Namespace: default
|
||||
CreationTimestamp: Sun, 02 Sep 2018 18:17:55 -0500
|
||||
Labels: app=nginx
|
||||
Annotations: deployment.kubernetes.io/revision=4
|
||||
kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true
|
||||
Selector: app=nginx
|
||||
Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable
|
||||
StrategyType: RollingUpdate
|
||||
MinReadySeconds: 0
|
||||
RollingUpdateStrategy: 25% max unavailable, 25% max surge
|
||||
Pod Template:
|
||||
Labels: app=nginx
|
||||
Containers:
|
||||
nginx:
|
||||
Image: nginx:1.9.1
|
||||
Port: 80/TCP
|
||||
Host Port: 0/TCP
|
||||
Environment: <none>
|
||||
Mounts: <none>
|
||||
Volumes: <none>
|
||||
Conditions:
|
||||
Type Status Reason
|
||||
---- ------ ------
|
||||
Available True MinimumReplicasAvailable
|
||||
Progressing True NewReplicaSetAvailable
|
||||
OldReplicaSets: <none>
|
||||
NewReplicaSet: nginx-deployment-c4747d96c (3/3 replicas created)
|
||||
Events:
|
||||
Type Reason Age From Message
|
||||
---- ------ ---- ---- -------
|
||||
Normal ScalingReplicaSet 12m deployment-controller Scaled up replica set nginx-deployment-75675f5897 to 3
|
||||
Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-c4747d96c to 1
|
||||
Normal ScalingReplicaSet 11m deployment-controller Scaled down replica set nginx-deployment-75675f5897 to 2
|
||||
Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-c4747d96c to 2
|
||||
Normal ScalingReplicaSet 11m deployment-controller Scaled down replica set nginx-deployment-75675f5897 to 1
|
||||
Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-c4747d96c to 3
|
||||
Normal ScalingReplicaSet 11m deployment-controller Scaled down replica set nginx-deployment-75675f5897 to 0
|
||||
Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-595696685f to 1
|
||||
Normal DeploymentRollback 15s deployment-controller Rolled back deployment "nginx-deployment" to revision 2
|
||||
Normal ScalingReplicaSet 15s deployment-controller Scaled down replica set nginx-deployment-595696685f to 0
|
||||
```
|
||||
|
||||
## Deploymentのスケーリング {#scaling-a-deployment}
|
||||
下記のコマンドを実行させてDeploymentをスケールできます。
|
||||
|
||||
```shell
|
||||
kubectl scale deployment.v1.apps/nginx-deployment --replicas=10
|
||||
```
|
||||
|
||||
実行結果は下記のとおりです。
|
||||
```
|
||||
deployment.apps/nginx-deployment scaled
|
||||
```
|
||||
|
||||
クラスター内で[水平Podオートスケーラー](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)が有効になっていると仮定します。ここでDeploymentのオートスケーラーを設定し、稼働しているPodのCPU使用量に基づいて、ユーザーが稼働させたいPodのレプリカ数の最小値と最大値を設定できます。
|
||||
|
||||
```shell
|
||||
kubectl autoscale deployment.v1.apps/nginx-deployment --min=10 --max=15 --cpu-percent=80
|
||||
```
|
||||
実行結果は下記のとおりです。
|
||||
```
|
||||
deployment.apps/nginx-deployment scaled
|
||||
```
|
||||
|
||||
### 比例スケーリング
|
||||
|
||||
Deploymentのローリングアップデートは、同時に複数のバージョンのアプリケーションの稼働をサポートします。ユーザーやオートスケーラーがロールアウト中(更新中もしくは一時停止中)のDeploymentのローリングアップデートを行うとき、Deploymentコントローラーはリスクを削減するために既存のアクティブなReplicaSetのレプリカのバランシングを行います。これを*比例スケーリング* と呼びます。
|
||||
|
||||
レプリカ数が10、[maxSurge](#max-surge)=3、[maxUnavailable](#max-unavailable)=2であるDeploymentが稼働している例です。
|
||||
|
||||
* Deployment内で10のレプリカが稼働していることを確認します。
|
||||
```shell
|
||||
kubectl get deploy
|
||||
```
|
||||
実行結果は下記のとおりです。
|
||||
|
||||
```
|
||||
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
|
||||
nginx-deployment 10 10 10 10 50s
|
||||
```
|
||||
|
||||
* クラスター内で、解決できない新しいイメージに更新します。
|
||||
* You update to a new image which happens to be unresolvable from inside the cluster.
|
||||
```shell
|
||||
kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:sometag
|
||||
```
|
||||
|
||||
実行結果は下記のとおりです。
|
||||
The output is similar to this:
|
||||
```
|
||||
deployment.apps/nginx-deployment image updated
|
||||
```
|
||||
|
||||
* イメージの更新は新しいReplicaSet nginx-deployment-1989198191へのロールアウトを開始させます。しかしロールアウトは、上述した`maxUnavailable`の要求によりブロックされます。ここでロールアウトのステータスを確認します。
|
||||
```shell
|
||||
kubectl get rs
|
||||
```
|
||||
実行結果は下記のとおりです。
|
||||
```
|
||||
NAME DESIRED CURRENT READY AGE
|
||||
nginx-deployment-1989198191 5 5 0 9s
|
||||
nginx-deployment-618515232 8 8 8 1m
|
||||
```
|
||||
|
||||
* 次にDeploymentのスケーリングをするための新しい要求が発生します。オートスケーラーはDeploymentのレプリカ数を15に増やします。Deploymentコントローラーは新しい5つのレプリカをどこに追加するか決める必要がでてきます。比例スケーリングを使用していない場合、5つのレプリカは全て新しいReplicaSetに追加されます。比例スケーリングでは、追加されるレプリカは全てのReplicaSetに分散されます。比例割合が大きいものはレプリカ数の大きいReplicaSetとなり、比例割合が低いときはレプリカ数の小さいReplicaSetとなります。残っているレプリカはもっとも大きいレプリカ数を持つReplicaSetに追加されます。レプリカ数が0のReplicaSetはスケールアップされません。
|
||||
|
||||
上記の例では、3つのレプリカが古いReplicaSetに追加され、2つのレプリカが新しいReplicaSetに追加されました。ロールアウトの処理では、新しいレプリカ数のPodが正常になったと仮定すると、最終的に新しいReplicaSetに全てのレプリカを移動させます。これを確認するためには下記のコマンドを実行して下さい。
|
||||
|
||||
```shell
|
||||
kubectl get deploy
|
||||
```
|
||||
実行結果は下記のとおりです。
|
||||
```
|
||||
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
|
||||
nginx-deployment 15 18 7 8 7m
|
||||
```
|
||||
ロールアウトのステータスでレプリカがどのように各ReplicaSetに追加されるか確認できます。
|
||||
```shell
|
||||
kubectl get rs
|
||||
```
|
||||
実行結果は下記のとおりです。
|
||||
```
|
||||
NAME DESIRED CURRENT READY AGE
|
||||
nginx-deployment-1989198191 7 7 0 7m
|
||||
nginx-deployment-618515232 11 11 11 7m
|
||||
```
|
||||
|
||||
## Deployment更新の一時停止と再開 {#pausing-and-resuming-a-deployment}
|
||||
|
||||
ユーザーは1つ以上の更新処理をトリガーする前に更新の一時停止と再開ができます。これにより、不必要なロールアウトを実行することなく一時停止と再開を行う間に複数の修正を反映できます。
|
||||
|
||||
* 例えば、作成直後のDeploymentを考えます。
|
||||
Deploymentの詳細情報を確認します。
|
||||
```shell
|
||||
kubectl get deploy
|
||||
```
|
||||
実行結果は下記のとおりです。
|
||||
```
|
||||
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
|
||||
nginx 3 3 3 3 1m
|
||||
```
|
||||
ロールアウトのステータスを確認します。
|
||||
```shell
|
||||
kubectl get rs
|
||||
```
|
||||
実行結果は下記のとおりです。
|
||||
```
|
||||
NAME DESIRED CURRENT READY AGE
|
||||
nginx-2142116321 3 3 3 1m
|
||||
```
|
||||
|
||||
* 下記のコマンドを実行して更新処理の一時停止を行います。
|
||||
```shell
|
||||
kubectl rollout pause deployment.v1.apps/nginx-deployment
|
||||
```
|
||||
|
||||
実行結果は下記のとおりです。
|
||||
```
|
||||
deployment.apps/nginx-deployment paused
|
||||
```
|
||||
|
||||
* 次にDeploymentのイメージを更新します。
|
||||
```shell
|
||||
kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1
|
||||
```
|
||||
|
||||
実行結果は下記のとおりです。
|
||||
```
|
||||
deployment.apps/nginx-deployment image updated
|
||||
```
|
||||
|
||||
* 新しいロールアウトが開始されていないことを確認します。
|
||||
```shell
|
||||
kubectl rollout history deployment.v1.apps/nginx-deployment
|
||||
```
|
||||
|
||||
実行結果は下記のとおりです。
|
||||
```
|
||||
deployments "nginx"
|
||||
REVISION CHANGE-CAUSE
|
||||
1 <none>
|
||||
```
|
||||
* Deploymentの更新に成功したことを確認するためにロールアウトのステータスを確認します。
|
||||
```shell
|
||||
kubectl get rs
|
||||
```
|
||||
実行結果は下記のとおりです。
|
||||
```
|
||||
NAME DESIRED CURRENT READY AGE
|
||||
nginx-2142116321 3 3 3 2m
|
||||
```
|
||||
|
||||
* ユーザーは何度も更新を行えます。例えばDeploymentが使用するリソースを更新します。
|
||||
```shell
|
||||
kubectl set resources deployment.v1.apps/nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi
|
||||
```
|
||||
|
||||
実行結果は下記のとおりです。
|
||||
```
|
||||
deployment.apps/nginx-deployment resource requirements updated
|
||||
```
|
||||
一時停止する前の初期状態では更新処理は機能しますが、Deploymentが一時停止されている間は新しい更新処理は反映されません。
|
||||
|
||||
* 最後に、Deploymentの稼働を再開させ、新しいReplicaSetが更新内容を全て反映させているのを確認します。
|
||||
```shell
|
||||
kubectl rollout resume deployment.v1.apps/nginx-deployment
|
||||
```
|
||||
実行結果は下記のとおりです。
|
||||
```
|
||||
deployment.apps/nginx-deployment resumed
|
||||
```
|
||||
* 更新処理が完了するまでロールアウトのステータスを確認します。
|
||||
```shell
|
||||
kubectl get rs -w
|
||||
```
|
||||
実行結果は下記のとおりです。
|
||||
```
|
||||
NAME DESIRED CURRENT READY AGE
|
||||
nginx-2142116321 2 2 2 2m
|
||||
nginx-3926361531 2 2 0 6s
|
||||
nginx-3926361531 2 2 1 18s
|
||||
nginx-2142116321 1 2 2 2m
|
||||
nginx-2142116321 1 2 2 2m
|
||||
nginx-3926361531 3 2 1 18s
|
||||
nginx-3926361531 3 2 1 18s
|
||||
nginx-2142116321 1 1 1 2m
|
||||
nginx-3926361531 3 3 1 18s
|
||||
nginx-3926361531 3 3 2 19s
|
||||
nginx-2142116321 0 1 1 2m
|
||||
nginx-2142116321 0 1 1 2m
|
||||
nginx-2142116321 0 0 0 2m
|
||||
nginx-3926361531 3 3 3 20s
|
||||
```
|
||||
* 最新のロールアウトのステータスを確認します。
|
||||
```shell
|
||||
kubectl get rs
|
||||
```
|
||||
|
||||
実行結果は下記のとおりです。
|
||||
```
|
||||
NAME DESIRED CURRENT READY AGE
|
||||
nginx-2142116321 0 0 0 2m
|
||||
nginx-3926361531 3 3 3 28s
|
||||
```
|
||||
{{< note >}}
|
||||
一時停止したDeploymentの稼働を再開させない限り、ユーザーはDeploymentのロールバックはできません。
|
||||
{{< /note >}}
|
||||
|
||||
## Deploymentのステータス {#deployment-status}
|
||||
|
||||
Deploymentは、そのライフサイクルの間に様々な状態に遷移します。新しいReplicaSetへのロールアウト中は[進行中](#progressing-deployment)になり、その後は[完了](#complete-deployment)し、また[失敗](#failed-deployment)にもなります。
|
||||
|
||||
### Deploymentの更新処理 {#progressing-deployment}
|
||||
|
||||
下記のタスクが実行中のとき、KubernetesはDeploymentの状態を_progressing_ にします。
|
||||
|
||||
* Deploymentが新しいReplicaSetを作成する。
|
||||
* Deploymentが新しいReplicaSetをスケールアップさせている。
|
||||
* Deploymentが古いReplicaSetをスケールダウンさせている。
|
||||
* 新しいPodが準備中もしくは利用可能な状態になる(少なくとも[MinReadySeconds](#min-ready-seconds)の間は準備中になります)。
|
||||
|
||||
ユーザーは`kubectl rollout status`を実行してDeploymentの進行状態を確認できます。
|
||||
|
||||
### Deploymentの更新処理の完了 {#complete-deployment}
|
||||
|
||||
Deploymentが下記の状態になったとき、KubernetesはDeploymentのステータスを_complete_ にします。
|
||||
|
||||
* Deploymentの全てのレプリカが、指定された最新のバージョンに更新される。これはユーザーが指定した更新処理が完了したことを意味します。
|
||||
* Deploymentの全てのレプリカが利用可能になる。
|
||||
* Deploymentの古いレプリカが1つも稼働していない。
|
||||
|
||||
`kubectl rollout status`を実行して、Deploymentの更新が完了したことを確認できます。ロールアウトが正常に完了すると`kubectl rollout status`の終了コードが0で返されます。
|
||||
|
||||
```shell
|
||||
kubectl rollout status deployment.v1.apps/nginx-deployment
|
||||
```
|
||||
実行結果は下記のとおりです。
|
||||
```
|
||||
Waiting for rollout to finish: 2 of 3 updated replicas are available...
|
||||
deployment.apps/nginx-deployment successfully rolled out
|
||||
$ echo $?
|
||||
0
|
||||
```
|
||||
|
||||
### Deploymentの更新処理の失敗 {#failed-deployment}
|
||||
|
||||
新しいReplicaSetのデプロイが完了せず、更新処理が止まる場合があります。これは主に下記の要因によるものです。
|
||||
|
||||
* 不十分なリソースの割り当て
|
||||
* ReadinessProbeの失敗
|
||||
* コンテナイメージの取得ができない
|
||||
* 不十分なパーミッション
|
||||
* リソースリミットのレンジ
|
||||
* アプリケーションランタイムの設定の不備
|
||||
|
||||
このような状況を検知する1つの方法として、Deploymentのリソース定義でデッドラインのパラメータを指定します([`.spec.progressDeadlineSeconds`](#progress-deadline-seconds))。`.spec.progressDeadlineSeconds`はDeploymentの更新が停止したことを示す前にDeploymentコントローラーが待つ秒数を示します。
|
||||
|
||||
下記の`kubectl`コマンドでリソース定義に`progressDeadlineSeconds`を設定します。これはDeploymentの更新が止まってから10分後に、コントローラーが失敗を通知させるためです。
|
||||
|
||||
```shell
|
||||
kubectl patch deployment.v1.apps/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}'
|
||||
```
|
||||
実行結果は下記のとおりです。
|
||||
```
|
||||
deployment.apps/nginx-deployment patched
|
||||
```
|
||||
一度デッドラインを超過すると、DeploymentコントローラーはDeploymentの`.status.conditions`に下記のDeploymentConditionを追加します。
|
||||
|
||||
* Type=Progressing
|
||||
* Status=False
|
||||
* Reason=ProgressDeadlineExceeded
|
||||
|
||||
ステータスの状態に関するさらなる情報は[Kubernetes APIの規則](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties)を参照してください。
|
||||
|
||||
{{< note >}}
|
||||
Kubernetesは停止状態のDeploymentに対して、ステータス状態を報告する以外のアクションを実行しません。高レベルのオーケストレーターはこれを利用して、状態に応じて行動できます。例えば、前のバージョンへのDeploymentのロールバックが挙げられます。
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
Deploymentを停止すると、Kubernetesはユーザーが指定したデッドラインを超えたかどうかチェックしません。ユーザーはロールアウトのとゆうでもDeploymentを安全に一時停止でき、デッドラインを超えたイベントをトリガーすることなく再開できます。
|
||||
{{< /note >}}
|
||||
|
||||
設定したタイムアウトの秒数が小さかったり、一時的なエラーとして扱える他の種類のエラーが原因となり、Deploymentで一時的なエラーが出る場合があります。例えば、リソースの割り当てが不十分な場合を考えます。Deploymentの詳細情報を確認すると、下記のセクションが表示されます。
|
||||
|
||||
```shell
|
||||
kubectl describe deployment nginx-deployment
|
||||
```
|
||||
実行結果は下記のとおりです。
|
||||
```
|
||||
<...>
|
||||
Conditions:
|
||||
Type Status Reason
|
||||
---- ------ ------
|
||||
Available True MinimumReplicasAvailable
|
||||
Progressing True ReplicaSetUpdated
|
||||
ReplicaFailure True FailedCreate
|
||||
<...>
|
||||
```
|
||||
|
||||
`kubectl get deployment nginx-deployment -o yaml`を実行すると、Deploymentのステータスは下記のようになります。
|
||||
|
||||
```
|
||||
status:
|
||||
availableReplicas: 2
|
||||
conditions:
|
||||
- lastTransitionTime: 2016-10-04T12:25:39Z
|
||||
lastUpdateTime: 2016-10-04T12:25:39Z
|
||||
message: Replica set "nginx-deployment-4262182780" is progressing.
|
||||
reason: ReplicaSetUpdated
|
||||
status: "True"
|
||||
type: Progressing
|
||||
- lastTransitionTime: 2016-10-04T12:25:42Z
|
||||
lastUpdateTime: 2016-10-04T12:25:42Z
|
||||
message: Deployment has minimum availability.
|
||||
reason: MinimumReplicasAvailable
|
||||
status: "True"
|
||||
type: Available
|
||||
- lastTransitionTime: 2016-10-04T12:25:39Z
|
||||
lastUpdateTime: 2016-10-04T12:25:39Z
|
||||
message: 'Error creating: pods "nginx-deployment-4262182780-" is forbidden: exceeded quota:
|
||||
object-counts, requested: pods=1, used: pods=3, limited: pods=2'
|
||||
reason: FailedCreate
|
||||
status: "True"
|
||||
type: ReplicaFailure
|
||||
observedGeneration: 3
|
||||
replicas: 2
|
||||
unavailableReplicas: 2
|
||||
```
|
||||
|
||||
最後に、一度Deploymentの更新処理のデッドラインを越えると、KubernetesはDeploymentのステータスと進行中の状態を更新します。
|
||||
|
||||
```
|
||||
Conditions:
|
||||
Type Status Reason
|
||||
---- ------ ------
|
||||
Available True MinimumReplicasAvailable
|
||||
Progressing False ProgressDeadlineExceeded
|
||||
ReplicaFailure True FailedCreate
|
||||
```
|
||||
|
||||
Deploymentか他のリソースコントローラーのスケールダウンを行うか、使用している名前空間内でリソースの割り当てを増やすことで、リソースの割り当て不足の問題に対処できます。割り当て条件を満たすと、DeploymentコントローラーはDeploymentのロールアウトを完了させ、Deploymentのステータスが成功状態になるのを確認できます(`Status=True`と`Reason=NewReplicaSetAvailable`)。
|
||||
|
||||
```
|
||||
Conditions:
|
||||
Type Status Reason
|
||||
---- ------ ------
|
||||
Available True MinimumReplicasAvailable
|
||||
Progressing True NewReplicaSetAvailable
|
||||
```
|
||||
|
||||
`Status=True`の`Type=Available`は、Deploymentが最小可用性の状態であることを意味します。最小可用性は、Deploymentの更新戦略において指定されているパラメータにより決定されます。`Status=True`の`Type=Progressing`は、Deploymentのロールアウトの途中で、更新処理が進行中であるか、更新処理が完了し、必要な最小数のレプリカが利用可能であることを意味します(各TypeのReason項目を確認してください。このケースでは、`Reason=NewReplicaSetAvailable`はDeploymentの更新が完了したことを意味します)。
|
||||
|
||||
`kubectl rollout status`を実行してDeploymentが更新に失敗したかどうかを確認できます。`kubectl rollout status`はDeploymentが更新処理のデッドラインを超えたときに0以外の終了コードを返します。
|
||||
|
||||
```shell
|
||||
kubectl rollout status deployment.v1.apps/nginx-deployment
|
||||
```
|
||||
実行結果は下記のとおりです。
|
||||
```
|
||||
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
|
||||
error: deployment "nginx" exceeded its progress deadline
|
||||
$ echo $?
|
||||
1
|
||||
```
|
||||
|
||||
### 失敗したDeploymentの操作
|
||||
|
||||
更新完了したDeploymentに適用した全てのアクションは、更新失敗したDeploymentに対しても適用されます。スケールアップ、スケールダウンができ、前のリビジョンへのロールバックや、Deploymentのテンプレートに複数の更新を適用させる必要があるときは一時停止もできます。
|
||||
|
||||
## 古いリビジョンのクリーンアップポリシー {#clean-up-policy}
|
||||
|
||||
Deploymentが管理する古いReplicaSetをいくつ保持するかを指定するために、`.spec.revisionHistoryLimit`フィールドを設定できます。この値を超えた古いReplicaSetはバックグラウンドでガーベージコレクションの対象となって削除されます。デフォルトではこの値は10です。
|
||||
|
||||
{{< note >}}
|
||||
このフィールドを明示的に0に設定すると、Deploymentの全ての履歴を削除します。従って、Deploymentはロールバックできません。
|
||||
{{< /note >}}
|
||||
|
||||
## カナリアパターンによるデプロイ
|
||||
|
||||
Deploymentを使って一部のユーザーやサーバーに対してリリースのロールアウトをしたいとき、[リソースの管理](/docs/concepts/cluster-administration/manage-deployment/#canary-deployments)に記載されているカナリアパターンに従って、リリース毎に1つずつ、複数のDeploymentを作成できます。
|
||||
|
||||
## Deployment Specの記述
|
||||
|
||||
他の全てのKubernetesの設定と同様に、Deploymentは`apiVersion`、`kind`や`metadata`フィールドを必要とします。設定ファイルの利用に関する情報は[アプリケーションのデプロイ](/docs/tutorials/stateless-application/run-stateless-application-deployment/)を参照してください。コンテナーの設定に関しては[リソースを管理するためのkubectlの使用](/docs/concepts/overview/working-with-objects/object-management/)を参照してください。
|
||||
|
||||
Deploymentは[`.spec`セクション](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)も必要とします。
|
||||
|
||||
### Podテンプレート
|
||||
|
||||
`.spec.template`と`.spec.selector`は`.spec`における必須のフィールドです。
|
||||
|
||||
`.spec.template`は[Podテンプレート](/docs/concepts/workloads/pods/pod-overview/#pod-templates)です。これは.spec内でネストされていないことと、`apiVersion`や`kind`を持たないことを除いては[Pod](/docs/concepts/workloads/pods/pod/)と同じスキーマとなります。
|
||||
|
||||
Podの必須フィールドに加えて、Deployment内のPodテンプレートでは適切なラベルと再起動ポリシーを設定しなくてはなりません。ラベルは他のコントローラーと重複しないようにしてください。ラベルについては、[セレクター](#selector)を参照してください。
|
||||
|
||||
[`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)が`Always`に等しいときのみ許可されます。これはテンプレートで指定されていない場合のデフォルト値です。
|
||||
|
||||
### レプリカ数
|
||||
|
||||
`.spec.replias`は理想的なPodの数を指定するオプションのフィールドです。デフォルトは1です。
|
||||
|
||||
### セレクター {#selector}
|
||||
|
||||
`.spec.selector`は必須フィールドで、Deploymentによって対象とされるPodの[ラベルセレクター](/docs/concepts/overview/working-with-objects/labels/)を指定します。
|
||||
|
||||
`.spec.selector`は`.spec.template.metadata.labels`と一致している必要があり、一致しない場合はAPIによって拒否されます。
|
||||
|
||||
`apps/v1`バージョンにおいて、`.spec.selector`と`.metadata.labels`が指定されていない場合、`.spec.template.metadata.labels`の値に初期化されません。そのため`.spec.selector`と`.metadata.labels`を明示的に指定する必要があります。また`apps/v1`のDeploymentにおいて`.spec.selector`は作成後に不変になります。
|
||||
|
||||
Deploymentのテンプレートが`.spec.template`と異なる場合や、`.spec.replicas`の値を超えてPodが稼働している場合、Deploymentはセレクターに一致するラベルを持つPodを削除します。Podの数が理想状態より少ない場合Deploymentは`.spec.template`をもとに新しいPodを作成します。
|
||||
|
||||
{{< note >}}
|
||||
ユーザーは、Deploymentのセレクターに一致するラベルを持つPodを、直接作成したり他のDeploymentやReplicaSetやReplicationControllerによって作成するべきではありません。作成した場合は最初のDeploymentが、ラベルに一致する新しいPodを作成したとみなしてしまいます。Kubernetesはユーザーがこれを行ってもエラーなどを出さず、処理を止めません。
|
||||
{{< /note >}}
|
||||
|
||||
セレクターが重複する複数のコントローラーを持つとき、そのコントローラーは互いに競合状態となり、正しくふるまいません。
|
||||
|
||||
### 更新戦略
|
||||
|
||||
`.spec.strategy`は古いPodから新しいPodに置き換える際の更新戦略を指定します。`.spec.strategy.type`は"Recreate"もしくは"RollingUpdate"を指定できます。デフォルトは"RollingUpdate"です。
|
||||
|
||||
#### Deploymentの再作成
|
||||
|
||||
`.spec.strategy.type==Recreate`と指定されているとき、既存の全てのPodは新しいPodが作成される前に削除されます。
|
||||
|
||||
#### Deploymentのローリングアップデート
|
||||
|
||||
`.spec.strategy.type==RollingUpdate`と指定されているとき、Deploymentは[ローリングアップデート](/docs/tasks/run-application/rolling-update-replication-controller/)によりPodを更新します。ローリングアップデートの処理をコントロールするために`maxUnavailable`と`maxSurge`を指定できます。
|
||||
|
||||
##### maxUnavailable
|
||||
|
||||
`.spec.strategy.rollingUpdate.maxUnavailable`はオプションのフィールドで、更新処理において利用不可となる最大のPod数を指定します。値は絶対値(例: 5)を指定するか、理想状態のPodのパーセンテージを指定します(例: 10%)。パーセンテージを指定した場合、絶対値は小数切り捨てされて計算されます。`.spec.strategy.rollingUpdate.maxSurge`が0に指定されている場合、この値を0にできません。デフォルトでは25%です。
|
||||
|
||||
例えば、この値が30%と指定されているとき、ローリングアップデートが開始すると古いReplicaSetはすぐに理想状態の70%にスケールダウンされます。一度新しいPodが稼働できる状態になると、古いReplicaSetはさらにスケールダウンされ、続いて新しいReplicaSetがスケールアップされます。この間、利用可能なPodの総数は理想状態のPodの少なくとも70%以上になるように保証されます。
|
||||
|
||||
##### maxSurge
|
||||
|
||||
`.spec.strategy.rollingUpdate.maxSurge`はオプションのフィールドで、理想状態のPod数を超えて作成できる最大のPod数を指定します。値は絶対値(例: 5)を指定するか、理想状態のPodのパーセンテージを指定します(例: 10%)。パーセンテージを指定した場合、絶対値は小数切り上げで計算されます。`MaxUnavailable`が0に指定されている場合、この値を0にできません。デフォルトでは25%です。
|
||||
|
||||
例えば、この値が30%と指定されているとき、ローリングアップデートが開始すると新しいReplicaSetはすぐに更新されます。このとき古いPodと新しいPodの総数は理想状態の130%を超えないように更新されます。一度古いPodが削除されると、新しいReplicaSetはさらにスケールアップされます。この間、利用可能なPodの総数は理想状態のPodに対して最大130%になるように保証されます。
|
||||
|
||||
### progressDeadlineSeconds
|
||||
|
||||
`.spec.progressDeadlineSeconds`はオプションのフィールドで、システムがDeploymentの[更新に失敗](#failed-deployment)したと判断するまでに待つ秒数を指定します。更新に失敗したと判断されたとき、リソースのステータスは`Type=Progressing`、`Status=False`かつ`Reason=ProgressDeadlineExceeded`となるのを確認できます。DeploymentコントローラーはDeploymentの更新のリトライし続けます。今後、自動的なロールバックが実装されたとき、更新失敗状態になるとすぐにDeploymentコントローラーがロールバックを行うようになります。
|
||||
|
||||
この値が指定されているとき、`.spec.minReadySeconds`より大きい値を指定する必要があります。
|
||||
|
||||
### minReadySeconds {#min-ready-seconds}
|
||||
|
||||
`.spec.minReadySeconds`はオプションのフィールドで、新しく作成されたPodが利用可能となるために、最低どれくらいの秒数コンテナーがクラッシュすることなく稼働し続ければよいかを指定するものです。デフォルトでは0です(Podは作成されるとすぐに利用可能と判断されます)。Podが利用可能と判断された場合についてさらに学ぶために[Container Probes](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)を参照してください。
|
||||
|
||||
### rollbackTo
|
||||
|
||||
`.spec.rollbackTo`は、`extensions/v1beta1`と`apps/v1beta1`のAPIバージョンにおいて非推奨で、`apps/v1beta2`以降のAPIバージョンではサポートされません。かわりに、[前のリビジョンへのロールバック](#rolling-back-to-a-previous-revision)で説明されているように`kubectl rollout undo`を使用するべきです。
|
||||
|
||||
### リビジョン履歴の保持上限
|
||||
|
||||
Deploymentのリビジョン履歴は、Deploymentが管理するReplicaSetに保持されています。
|
||||
|
||||
`.spec.revisionHistoryLimit`はオプションのフィールドで、ロールバック可能な古いReplicaSetの数を指定します。この古いReplicaSetは`etcd`内のリソースを消費し、`kubectl get rs`の出力結果を見にくくします。Deploymentの各リビジョンの設定はReplicaSetに保持されます。このため一度古いReplicaSetが削除されると、そのリビジョンのDeploymentにロールバックすることができなくなります。デフォルトでは10もの古いReplicaSetが保持されます。しかし、この値の最適値は新しいDeploymnetの更新頻度と安定性に依存します。
|
||||
|
||||
さらに詳しく言うと、この値を0にすると、0のレプリカを持つ古い全てのReplicaSetが削除されます。このケースでは、リビジョン履歴が完全に削除されているため新しいDeploymentのロールアウトを完了することができません。
|
||||
|
||||
### paused
|
||||
|
||||
`.spec.paused`はオプションのboolean値で、Deploymentの一時停止と再開のための値です。一時停止されているものと、そうでないものとの違いは、一時停止されているDeploymentはPodTemplateSpecのいかなる変更があってもロールアウトがトリガーされないことです。デフォルトではDeploymentは一時停止していない状態で作成されます。
|
||||
|
||||
## Deploymentの代替案
|
||||
### kubectl rolling update
|
||||
|
||||
[`kubectl rolling update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update)によって、同様の形式でPodとReplicationControllerを更新できます。しかしDeploymentの使用が推奨されます。なぜならDeploymentの作成は宣言的であり、ローリングアップデートが更新された後に過去のリビジョンにロールバックできるなど、いくつかの追加機能があります。
|
||||
|
||||
{{% /capture %}}
|
||||
|
|
@ -1,5 +1,4 @@
|
|||
---
|
||||
title: "Pods"
|
||||
title: "Pod"
|
||||
weight: 10
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -17,11 +17,11 @@ card:
|
|||
{{% capture body %}}
|
||||
## Podについて理解する
|
||||
|
||||
*Pod* は、Kubernetesの基本的なビルディングブロックとなります。Kubernetesオブジェクトモデルの中で、ユーザーが作成し、デプロイ可能なシンプルで最も最小のユニットです。単一のPodはクラスター上で稼働する単一のプロセスを表現します。
|
||||
*Pod* は、Kubernetesアプリケーションの基本的な実行単位です。これは、作成またはデプロイするKubernetesオブジェクトモデルの中で最小かつ最も単純な単位です。Podは、{{< glossary_tooltip term_id="cluster" >}}で実行されているプロセスを表します。
|
||||
|
||||
単一のPodは、アプリケーションコンテナ（いくつかの場合においては複数のコンテナ）や、ストレージリソース、ユニークなネットワークIPや、コンテナがどのように稼働すべきか統制するためのオプションをカプセル化します。単一のPodは、ある単一のDeploymentのユニット(単一のコンテナもしくはリソースを共有する、密接に連携された少数のコンテナ群を含むような*Kubernetes内でのアプリケーションの単一のインスタンス*) を表現します。
|
||||
Podは、アプリケーションのコンテナ(いくつかの場合においては複数のコンテナ)、ストレージリソース、ユニークなネットワークIP、およびコンテナの実行方法を管理するオプションをカプセル化します。Podはデプロイメントの単位、すなわち*Kubernetesのアプリケーションの単一インスタンス* で、単一の{{< glossary_tooltip term_id="container" >}}または密結合なリソースを共有する少数のコンテナで構成される場合があります。
|
||||
|
||||
> [Docker](https://www.docker.com)はKubernetesのPod内で使われる最も一般的なコンテナランタイムですが、Podは他のコンテナランタイムも同様にサポートしています。
|
||||
[Docker](https://www.docker.com)はKubernetesのPod内で使われる最も一般的なコンテナランタイムですが、Podは他の[コンテナランタイム](/ja/docs/setup/production-environment/container-runtimes/)も同様にサポートしています。
|
||||
|
||||
Kubernetesクラスター内でのPodは2つの主な方法で使うことができます。
|
||||
|
||||
|
|
@ -30,11 +30,10 @@ Kubernetesクラスター内でのPodは2つの主な方法で使うことがで
|
|||
* **協調して稼働させる必要がある複数のコンテナを稼働させるPod** : 単一のPodは、リソースを共有する必要があるような、密接に連携した複数の同じ環境にあるコンテナからなるアプリケーションをカプセル化することもできます。 これらの同じ環境にあるコンテナ群は、サービスの結合力の強いユニットを構成することができます。
|
||||
-- 1つのコンテナが、共有されたボリュームからファイルをパブリックな場所に送信し、一方では分割された*サイドカー* コンテナがそれらのファイルを更新します。そのPodはそれらのコンテナとストレージリソースを、単一の管理可能なエンティティとしてまとめます。
|
||||
|
||||
[Kubernetes Blog](http://kubernetes.io/blog)にて、Podのユースケースに関するいくつかの追加情報を見ることができます。
|
||||
さらなる情報を得たい場合は、下記のページを参照ください。
|
||||
[Kubernetes Blog](http://kubernetes.io/blog)にて、Podのユースケースに関するいくつかの追加情報を見ることができます。さらなる情報を得たい場合は、下記のページを参照ください。
|
||||
|
||||
* [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)
|
||||
* [Container Design Patterns](https://kubernetes.io/blog/2016/06/container-design-patterns)
|
||||
* [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)
|
||||
* [Container Design Patterns](https://kubernetes.io/blog/2016/06/container-design-patterns)
|
||||
|
||||
各Podは、与えられたアプリケーションの単一のインスタンスを稼働するためのものです。もしユーザーのアプリケーションを水平にスケールさせたい場合(例: 複数インスタンスを稼働させる)、複数のPodを使うべきです。1つのPodは各インスタンスに対応しています。
|
||||
Kubernetesにおいて、これは一般的に_レプリケーション_ と呼ばれます。
|
||||
|
|
@ -50,7 +49,6 @@ Podは凝集性の高いサービスのユニットを構成するような複
|
|||
ユーザーは、コンテナ群が密接に連携するような、特定のインスタンスにおいてのみこのパターンを使用するべきです。
|
||||
例えば、ユーザーが共有ボリューム内にあるファイル用のWebサーバとして稼働するコンテナと、下記のダイアグラムにあるような、リモートのソースからファイルを更新するような分離された*サイドカー* コンテナを持っているような場合です。
|
||||
|
||||
|
||||
{{< figure src="/images/docs/pod.svg" alt="Podのダイアグラム" width="50%" >}}
|
||||
|
||||
Podは、Podによって構成されたコンテナ群のために2種類の共有リソースを提供します。 *ネットワーキング* と*ストレージ* です。
|
||||
|
|
@ -61,24 +59,24 @@ Podは、Podによって構成されたコンテナ群のために2種類の共
|
|||
|
||||
#### ストレージ
|
||||
|
||||
単一のPodは共有されたストレージ*ボリューム* のセットを指定できます。Pod内の全てのコンテナは、その共有されたボリュームにアクセスでき、コンテナ間でデータを共有することを可能にします。ボリュームもまた、もしPod内のコンテナの1つが再起動が必要になった場合に備えて、データを永続化できます。
|
||||
単一のPodは共有されたストレージ{{< glossary_tooltip term_id="volume" >}}のセットを指定できます。Pod内の全てのコンテナは、その共有されたボリュームにアクセスでき、コンテナ間でデータを共有することを可能にします。ボリュームもまた、もしPod内のコンテナの1つが再起動が必要になった場合に備えて、データを永続化できます。
|
||||
単一のPod内での共有ストレージをKubernetesがどう実装しているかについてのさらなる情報については、[Volumes](/docs/concepts/storage/volumes/)を参照してください。
|
||||
|
||||
## Podを利用する
|
||||
|
||||
ユーザーはまれに、Kubenetes内で独立したPodを直接作成する場合があります(シングルトンPodなど)。
|
||||
これはPodが比較的、一時的な使い捨てエンティティとしてデザインされているためです。Podが作成された時（ユーザーによって直接的、またはコントローラーによって間接的に作成された場合）、ユーザーのクラスター内の単一のNode上で稼働するようにスケジューリングされます。そのPodはプロセスが停止されたり、Podオブジェクトが削除されたり、Podがリソースの欠如のために*追い出され* たり、Nodeが故障するまでNode上に残り続けます。
|
||||
これはPodが比較的、一時的な使い捨てエンティティとしてデザインされているためです。Podが作成された時（ユーザーによって直接的、またはコントローラーによって間接的に作成された場合）、ユーザーのクラスター内の単一の{{< glossary_tooltip term_id="node" >}}上で稼働するようにスケジューリングされます。そのPodはプロセスが停止されたり、Podオブジェクトが削除されたり、Podがリソースの欠如のために*追い出され* たり、ノードが故障するまでノード上に残り続けます。
|
||||
|
||||
{{< note >}}
|
||||
単一のPod内でのコンテナを再起動することと、そのPodを再起動することを混同しないでください。Podはそれ自体は実行されませんが、コンテナが実行される環境であり、削除されるまで存在し続けます。
|
||||
{{< /note >}}
|
||||
|
||||
Podは、Podそれ自体によって自己修復しません。もし、稼働されていないNode上にPodがスケジュールされた場合や、スケジューリング操作自体が失敗した場合、Podが削除されます。同様に、Podはリソースの欠如や、Nodeのメンテナンスによる追い出しがあった場合はそこで停止します。Kubernetesは*コントローラー* と呼ばれる高レベルの抽象概念を使用し、それは比較的使い捨て可能なPodインスタンスの管理を行います。
|
||||
Podは、Podそれ自体によって自己修復しません。もし、稼働されていないノード上にPodがスケジュールされた場合や、スケジューリング操作自体が失敗した場合、Podが削除されます。同様に、Podはリソースの欠如や、ノードのメンテナンスによる追い出しがあった場合はそこで停止します。Kubernetesは*コントローラー* と呼ばれる高レベルの抽象概念を使用し、それは比較的使い捨て可能なPodインスタンスの管理を行います。
|
||||
このように、Podを直接使うのは可能ですが、コントローラーを使用したPodを管理する方がより一般的です。KubernetesがPodのスケーリングと修復機能を実現するためにコントローラーをどのように使うかに関する情報は[Podとコントローラー](#pods-and-controllers)を参照してください。
|
||||
|
||||
### Podとコントローラー
|
||||
|
||||
単一のコントローラーは、ユーザーのために複数のPodを作成・管理し、レプリケーションやロールアウト、クラスターのスコープ内で自己修復の機能をハンドリングします。例えば、もしNodeが故障した場合、コントローラーは異なるNode上にPodを置き換えるようにスケジューリングすることで、自動的にリプレース可能となります。
|
||||
単一のコントローラーは、ユーザーのために複数のPodを作成・管理し、レプリケーションやロールアウト、クラスターのスコープ内で自己修復の機能をハンドリングします。例えば、もしノードが故障した場合、コントローラーは異なるノード上にPodを置き換えるようにスケジューリングすることで、自動的にリプレース可能となります。
|
||||
|
||||
1つまたはそれ以上のPodを含むコントローラーの例は下記の通りです。
|
||||
|
||||
|
|
@ -115,7 +113,8 @@ spec:
|
|||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
* Podの振る舞いに関して学ぶには下記を参照してください。
|
||||
* [Podの停止](/docs/concepts/workloads/pods/pod/#termination-of-pods)
|
||||
* [Podのライフサイクル](/docs/concepts/workloads/pods/pod-lifecycle/)
|
||||
* [Pod](/ja/docs/concepts/workloads/pods/pod/)について更に学びましょう
|
||||
* Podの振る舞いに関して学ぶには下記を参照してください
|
||||
* [Podの停止](/ja/docs/concepts/workloads/pods/pod/#podの終了)
|
||||
* [Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)
|
||||
{{% /capture %}}
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: リファレンス
|
||||
linkTitle: "Reference"
|
||||
linkTitle: "リファレンス"
|
||||
main_menu: true
|
||||
weight: 70
|
||||
content_template: templates/concept
|
||||
|
|
@ -14,15 +14,15 @@ content_template: templates/concept
|
|||
|
||||
{{% capture body %}}
|
||||
|
||||
## API Reference
|
||||
## APIリファレンス
|
||||
|
||||
* [Kubernetes API概要](/docs/reference/using-api/api-overview/) - Kubernetes APIの概要です。
|
||||
* Kubernetes APIバージョン
|
||||
* [1.16](/docs/reference/generated/kubernetes-api/v1.16/)
|
||||
* [1.15](/docs/reference/generated/kubernetes-api/v1.15/)
|
||||
* [1.14](/docs/reference/generated/kubernetes-api/v1.14/)
|
||||
* [1.13](/docs/reference/generated/kubernetes-api/v1.13/)
|
||||
* [1.12](/docs/reference/generated/kubernetes-api/v1.12/)
|
||||
* [1.11](/docs/reference/generated/kubernetes-api/v1.11/)
|
||||
|
||||
## APIクライアントライブラリー
|
||||
|
||||
|
|
@ -47,8 +47,6 @@ content_template: templates/concept
|
|||
* [kube-controller-manager](/docs/admin/kube-controller-manager/) - Kubernetesに同梱された、コアのコントロールループを埋め込むデーモンです。
|
||||
* [kube-proxy](/docs/admin/kube-proxy/) - 単純なTCP/UDPストリームのフォワーディングや、一連のバックエンド間でTCP/UDPのラウンドロビンでのフォワーディングを実行できます。
|
||||
* [kube-scheduler](/docs/admin/kube-scheduler/) - 可用性、パフォーマンス、およびキャパシティを管理するスケジューラーです。
|
||||
* [federation-apiserver](/docs/admin/federation-apiserver/) - 連合クラスターのためのAPIサーバーです。
|
||||
* [federation-controller-manager](/docs/admin/federation-controller-manager/) - 連合Kubernetesクラスターに同梱された、コアのコントロールループを埋め込むデーモンです。
|
||||
|
||||
## 設計のドキュメント
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
title: コマンドラインツールのリファレンス
|
||||
weight: 60
|
||||
toc-hide: true
|
||||
---
|
||||
|
|
@ -6,17 +6,16 @@ content_template: templates/concept
|
|||
|
||||
{{% capture overview %}}
|
||||
このページでは管理者がそれぞれのKubernetesコンポーネントで指定できるさまざまなフィーチャーゲートの概要について説明しています。
|
||||
|
||||
各機能におけるステージの説明については、[機能のステージ](#feature-stages)を参照してください。
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## 概要
|
||||
|
||||
フィーチャーゲートはアルファ機能または実験的機能を記述するkey=valueのペアのセットです。
|
||||
フィーチャーゲートはアルファ機能または実験的機能を記述するkey=valueのペアのセットです。管理者は各コンポーネントで`--feature-gates`コマンドラインフラグを使用することで機能をオンまたはオフにできます。
|
||||
|
||||
管理者は各コンポーネントで`--feature-gates`コマンドラインフラグを使用することで機能をオンまたはオフにできます。各コンポーネントはそれぞれのコンポーネント固有のフィーチャーゲートの設定をサポートします。
|
||||
すべてのコンポーネントのフィーチャーゲートの全リストを表示するには`-h`フラグを使用します。
|
||||
kubeletなどのコンポーネントにフィーチャーゲートを設定するには以下のようにリストの機能ペアを`--feature-gates`フラグを使用して割り当てます。
|
||||
各コンポーネントはそれぞれのコンポーネント固有のフィーチャーゲートの設定をサポートします。すべてのコンポーネントのフィーチャーゲートの全リストを表示するには`-h`フラグを使用します。kubeletなどのコンポーネントにフィーチャーゲートを設定するには以下のようにリストの機能ペアを`--feature-gates`フラグを使用して割り当てます。
|
||||
|
||||
```shell
|
||||
--feature-gates="...,DynamicKubeletConfig=true"
|
||||
|
|
@ -26,23 +25,24 @@ kubeletなどのコンポーネントにフィーチャーゲートを設定す
|
|||
|
||||
- 「導入開始バージョン」列は機能が導入されたとき、またはリリース段階が変更されたときのKubernetesリリースバージョンとなります。
|
||||
- 「最終利用可能バージョン」列は空ではない場合はフィーチャーゲートを使用できる最後のKubernetesリリースバージョンとなります。
|
||||
- アルファまたはベータ状態の機能は[AlphaまたはBetaのフィーチャーゲート](#feature-gates-for-alpha-or-beta-features)に載っています。
|
||||
- 安定している機能は、[graduatedまたはdeprecatedのフィーチャーゲート](#feature-gates-for-graduated-or-deprecated-features)に載っています。
|
||||
- graduatedまたはdeprecatedのフィーチャーゲートには、非推奨および廃止された機能もリストされています。
|
||||
|
||||
### AlphaまたはBetaのフィーチャーゲート {#feature-gates-for-alpha-or-beta-features}
|
||||
|
||||
{{< table caption="AlphaまたはBetaのフィーチャーゲート" >}}
|
||||
|
||||
| 機能名 | デフォルト値 | ステージ | 導入開始バージョン | 最終利用可能バージョン |
|
||||
|---------|---------|-------|-------|-------|
|
||||
| `Accelerators` | `false` | Alpha | 1.6 | 1.10 |
|
||||
| `AdvancedAuditing` | `false` | Alpha | 1.7 | 1.7 |
|
||||
| `AdvancedAuditing` | `true` | Beta | 1.8 | 1.11 |
|
||||
| `AdvancedAuditing` | `true` | GA | 1.12 | - |
|
||||
| `AffinityInAnnotations` | `false` | Alpha | 1.6 | 1.7 |
|
||||
| `AllowExtTrafficLocalEndpoints` | `false` | Beta | 1.4 | 1.6 |
|
||||
| `AllowExtTrafficLocalEndpoints` | `true` | GA | 1.7 | - |
|
||||
| `APIListChunking` | `false` | Alpha | 1.8 | 1.8 |
|
||||
| `APIListChunking` | `true` | Beta | 1.9 | |
|
||||
| `APIResponseCompression` | `false` | Alpha | 1.7 | |
|
||||
| `AppArmor` | `true` | Beta | 1.4 | |
|
||||
| `AttachVolumeLimit` | `true` | Alpha | 1.11 | 1.11 |
|
||||
| `AttachVolumeLimit` | `true` | Beta | 1.12 | |
|
||||
| `BlockVolume` | `false` | Alpha | 1.9 | |
|
||||
| `BalanceAttachedNodeVolumes` | `false` | Alpha | 1.11 | |
|
||||
| `BlockVolume` | `false` | Alpha | 1.9 | 1.12 |
|
||||
| `BlockVolume` | `true` | Beta | 1.13 | - |
|
||||
| `BoundServiceAccountTokenVolume` | `false` | Alpha | 1.13 | |
|
||||
| `CPUManager` | `false` | Alpha | 1.8 | 1.9 |
|
||||
|
|
@ -53,7 +53,8 @@ kubeletなどのコンポーネントにフィーチャーゲートを設定す
|
|||
| `CSIBlockVolume` | `true` | Beta | 1.14 | |
|
||||
| `CSIDriverRegistry` | `false` | Alpha | 1.12 | 1.13 |
|
||||
| `CSIDriverRegistry` | `true` | Beta | 1.14 | |
|
||||
| `CSIInlineVolume` | `false` | Alpha | 1.15 | - |
|
||||
| `CSIInlineVolume` | `false` | Alpha | 1.15 | 1.15 |
|
||||
| `CSIInlineVolume` | `true` | Beta | 1.16 | - |
|
||||
| `CSIMigration` | `false` | Alpha | 1.14 | |
|
||||
| `CSIMigrationAWS` | `false` | Alpha | 1.14 | |
|
||||
| `CSIMigrationAzureDisk` | `false` | Alpha | 1.15 | |
|
||||
|
|
@ -62,99 +63,67 @@ kubeletなどのコンポーネントにフィーチャーゲートを設定す
|
|||
| `CSIMigrationOpenStack` | `false` | Alpha | 1.14 | |
|
||||
| `CSINodeInfo` | `false` | Alpha | 1.12 | 1.13 |
|
||||
| `CSINodeInfo` | `true` | Beta | 1.14 | |
|
||||
| `CSIPersistentVolume` | `false` | Alpha | 1.9 | 1.9 |
|
||||
| `CSIPersistentVolume` | `true` | Beta | 1.10 | 1.12 |
|
||||
| `CSIPersistentVolume` | `true` | GA | 1.13 | - |
|
||||
| `CustomCPUCFSQuotaPeriod` | `false` | Alpha | 1.12 | |
|
||||
| `CustomPodDNS` | `false` | Alpha | 1.9 | 1.9 |
|
||||
| `CustomPodDNS` | `true` | Beta| 1.10 | 1.13 |
|
||||
| `CustomPodDNS` | `true` | GA | 1.14 | - |
|
||||
| `CustomResourcePublishOpenAPI` | `false` | Alpha| 1.14 | 1.14 |
|
||||
| `CustomResourcePublishOpenAPI` | `true` | Beta| 1.15 | |
|
||||
| `CustomResourceSubresources` | `false` | Alpha | 1.10 | 1.11 |
|
||||
| `CustomResourceSubresources` | `true` | Beta | 1.11 | - |
|
||||
| `CustomResourceValidation` | `false` | Alpha | 1.8 | 1.8 |
|
||||
| `CustomResourceValidation` | `true` | Beta | 1.9 | |
|
||||
| `CustomResourceWebhookConversion` | `false` | Alpha | 1.13 | 1.14 |
|
||||
| `CustomResourceWebhookConversion` | `true` | Beta | 1.15 | |
|
||||
| `DebugContainers` | `false` | Alpha | 1.10 | |
|
||||
| `CustomResourceDefaulting` | `false` | Alpha| 1.15 | 1.15 |
|
||||
| `CustomResourceDefaulting` | `true` | Beta | 1.16 | |
|
||||
| `DevicePlugins` | `false` | Alpha | 1.8 | 1.9 |
|
||||
| `DevicePlugins` | `true` | Beta | 1.10 | |
|
||||
| `DryRun` | `false` | Alpha | 1.12 | 1.12 |
|
||||
| `DryRun` | `true` | Beta | 1.13 | |
|
||||
| `DynamicAuditing` | `false` | Alpha | 1.13 | |
|
||||
| `DynamicKubeletConfig` | `false` | Alpha | 1.4 | 1.10 |
|
||||
| `DynamicKubeletConfig` | `true` | Beta | 1.11 | |
|
||||
| `DynamicProvisioningScheduling` | `false` | Alpha | 1.11 | 1.11 |
|
||||
| `DynamicVolumeProvisioning` | `true` | Alpha | 1.3 | 1.7 |
|
||||
| `DynamicVolumeProvisioning` | `true` | GA | 1.8 | |
|
||||
| `EnableEquivalenceClassCache` | `false` | Alpha | 1.8 | |
|
||||
| `ExpandCSIVolumes` | `false` | Alpha | 1.14 | |
|
||||
| `EndpointSlice` | `false` | Alpha | 1.16 | |
|
||||
| `EphemeralContainers` | `false` | Alpha | 1.16 | |
|
||||
| `ExpandCSIVolumes` | `false` | Alpha | 1.14 | 1.15 |
|
||||
| `ExpandCSIVolumes` | `true` | Beta | 1.16 | |
|
||||
| `ExpandInUsePersistentVolumes` | `false` | Alpha | 1.11 | 1.14 |
|
||||
| `ExpandInUsePersistentVolumes` | `true` | Beta | 1.15 | |
|
||||
| `ExpandPersistentVolumes` | `false` | Alpha | 1.8 | 1.10 |
|
||||
| `ExpandPersistentVolumes` | `true` | Beta | 1.11 | |
|
||||
| `ExperimentalCriticalPodAnnotation` | `false` | Alpha | 1.5 | |
|
||||
| `ExperimentalHostUserNamespaceDefaulting` | `false` | Beta | 1.5 | |
|
||||
| `GCERegionalPersistentDisk` | `true` | Beta | 1.10 | 1.12 |
|
||||
| `GCERegionalPersistentDisk` | `true` | GA | 1.13 | - |
|
||||
| `HugePages` | `false` | Alpha | 1.8 | 1.9 |
|
||||
| `HugePages` | `true` | Beta| 1.10 | 1.13 |
|
||||
| `HugePages` | `true` | GA | 1.14 | |
|
||||
| `EvenPodsSpread` | `false` | Alpha | 1.16 | |
|
||||
| `HPAScaleToZero` | `false` | Alpha | 1.16 | |
|
||||
| `HyperVContainer` | `false` | Alpha | 1.10 | |
|
||||
| `Initializers` | `false` | Alpha | 1.7 | 1.13 |
|
||||
| `Initializers` | - | Deprecated | 1.14 | |
|
||||
| `KubeletConfigFile` | `false` | Alpha | 1.8 | 1.9 |
|
||||
| `KubeletPluginsWatcher` | `false` | Alpha | 1.11 | 1.11 |
|
||||
| `KubeletPluginsWatcher` | `true` | Beta | 1.12 | 1.12 |
|
||||
| `KubeletPluginsWatcher` | `true` | GA | 1.13 | - |
|
||||
| `KubeletPodResources` | `false` | Alpha | 1.13 | 1.14 |
|
||||
| `KubeletPodResources` | `true` | Beta | 1.15 | |
|
||||
| `LegacyNodeRoleBehavior` | `true` | Alpha | 1.16 | |
|
||||
| `LocalStorageCapacityIsolation` | `false` | Alpha | 1.7 | 1.9 |
|
||||
| `LocalStorageCapacityIsolation` | `true` | Beta| 1.10 | |
|
||||
| `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | Alpha| 1.15 | |
|
||||
| `LocalStorageCapacityIsolation` | `true` | Beta | 1.10 | |
|
||||
| `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | Alpha | 1.15 | |
|
||||
| `MountContainers` | `false` | Alpha | 1.9 | |
|
||||
| `MountPropagation` | `false` | Alpha | 1.8 | 1.9 |
|
||||
| `MountPropagation` | `true` | Beta | 1.10 | 1.11 |
|
||||
| `MountPropagation` | `true` | GA | 1.12 | |
|
||||
| `NodeDisruptionExclusion` | `false` | Alpha | 1.16 | |
|
||||
| `NodeLease` | `false` | Alpha | 1.12 | 1.13 |
|
||||
| `NodeLease` | `true` | Beta | 1.14 | |
|
||||
| `NonPreemptingPriority` | `false` | Alpha | 1.15 | |
|
||||
| `PersistentLocalVolumes` | `false` | Alpha | 1.7 | 1.9 |
|
||||
| `PersistentLocalVolumes` | `true` | Beta | 1.10 | 1.13 |
|
||||
| `PersistentLocalVolumes` | `true` | GA | 1.14 | |
|
||||
| `PodPriority` | `false` | Alpha | 1.8 | 1.10 |
|
||||
| `PodPriority` | `true` | Beta | 1.11 | 1.13 |
|
||||
| `PodPriority` | `true` | GA | 1.14 | |
|
||||
| `PodReadinessGates` | `false` | Alpha | 1.11 | 1.11 |
|
||||
| `PodReadinessGates` | `true` | Beta | 1.12 | 1.13 |
|
||||
| `PodReadinessGates` | `true` | GA | 1.14 | - |
|
||||
| `PodShareProcessNamespace` | `false` | Alpha | 1.10 | |
|
||||
| `PodOverhead` | `false` | Alpha | 1.16 | - |
|
||||
| `PodShareProcessNamespace` | `false` | Alpha | 1.10 | 1.11 |
|
||||
| `PodShareProcessNamespace` | `true` | Beta | 1.12 | |
|
||||
| `ProcMountType` | `false` | Alpha | 1.12 | |
|
||||
| `PVCProtection` | `false` | Alpha | 1.9 | 1.9 |
|
||||
| `QOSReserved` | `false` | Alpha | 1.11 | |
|
||||
| `RemainingItemCount` | `false` | Alpha | 1.15 | |
|
||||
| `ResourceLimitsPriorityFunction` | `false` | Alpha | 1.9 | |
|
||||
| `RequestManagement` | `false` | Alpha | 1.15 | |
|
||||
| `ResourceLimitsPriorityFunction` | `false` | Alpha | 1.9 | |
|
||||
| `ResourceQuotaScopeSelectors` | `false` | Alpha | 1.11 | 1.11 |
|
||||
| `ResourceQuotaScopeSelectors` | `true` | Beta | 1.12 | |
|
||||
| `RotateKubeletClientCertificate` | `true` | Beta | 1.8 | |
|
||||
| `RotateKubeletServerCertificate` | `false` | Alpha | 1.7 | 1.11 |
|
||||
| `RotateKubeletServerCertificate` | `true` | Beta | 1.12 | |
|
||||
| `RunAsGroup` | `true` | Beta | 1.14 | |
|
||||
| `RuntimeClass` | `false` | Alpha | 1.12 | 1.13 |
|
||||
| `RuntimeClass` | `true` | Beta | 1.14 | |
|
||||
| `ScheduleDaemonSetPods` | `false` | Alpha | 1.11 | 1.11 |
|
||||
| `ScheduleDaemonSetPods` | `true` | Beta | 1.12 | |
|
||||
| `SCTPSupport` | `false` | Alpha | 1.12 | |
|
||||
| `ServerSideApply` | `false` | Alpha | 1.14 | |
|
||||
| `ServerSideApply` | `false` | Alpha | 1.14 | 1.15 |
|
||||
| `ServerSideApply` | `true` | Beta | 1.16 | |
|
||||
| `ServiceLoadBalancerFinalizer` | `false` | Alpha | 1.15 | |
|
||||
| `ServiceNodeExclusion` | `false` | Alpha | 1.8 | |
|
||||
| `StorageObjectInUseProtection` | `true` | Beta | 1.10 | 1.10 |
|
||||
| `StorageObjectInUseProtection` | `true` | GA | 1.11 | |
|
||||
| `StartupProbe` | `false` | Alpha | 1.16 | |
|
||||
| `StorageVersionHash` | `false` | Alpha | 1.14 | 1.14 |
|
||||
| `StorageVersionHash` | `true` | Beta | 1.15 | |
|
||||
| `StreamingProxyRedirects` | `true` | Beta | 1.5 | |
|
||||
| `SupportIPVSProxyMode` | `false` | Alpha | 1.8 | 1.8 |
|
||||
| `SupportIPVSProxyMode` | `false` | Beta | 1.9 | 1.9 |
|
||||
| `SupportIPVSProxyMode` | `true` | Beta | 1.10 | 1.10 |
|
||||
| `SupportIPVSProxyMode` | `true` | GA | 1.11 | |
|
||||
| `StreamingProxyRedirects` | `false` | Beta | 1.5 | 1.5 |
|
||||
| `StreamingProxyRedirects` | `true` | Beta | 1.6 | |
|
||||
| `SupportNodePidsLimit` | `false` | Alpha | 1.14 | 1.14 |
|
||||
| `SupportNodePidsLimit` | `true` | Beta | 1.15 | |
|
||||
| `SupportPodPidsLimit` | `false` | Alpha | 1.10 | 1.13 |
|
||||
|
|
@ -169,24 +138,106 @@ kubeletなどのコンポーネントにフィーチャーゲートを設定す
|
|||
| `TokenRequestProjection` | `false` | Alpha | 1.11 | 1.11 |
|
||||
| `TokenRequestProjection` | `true` | Beta | 1.12 | |
|
||||
| `TTLAfterFinished` | `false` | Alpha | 1.12 | |
|
||||
| `VolumePVCDataSource` | `false` | Alpha | 1.15 | |
|
||||
| `VolumeScheduling` | `false` | Alpha | 1.9 | 1.9 |
|
||||
| `VolumeScheduling` | `true` | Beta | 1.10 | 1.12 |
|
||||
| `VolumeScheduling` | `true` | GA | 1.13 | |
|
||||
| `TopologyManager` | `false` | Alpha | 1.16 | |
|
||||
| `ValidateProxyRedirects` | `false` | Alpha | 1.10 | 1.13 |
|
||||
| `ValidateProxyRedirects` | `true` | Beta | 1.14 | |
|
||||
| `VolumePVCDataSource` | `false` | Alpha | 1.15 | 1.15 |
|
||||
| `VolumePVCDataSource` | `true` | Beta | 1.16 | |
|
||||
| `VolumeSubpathEnvExpansion` | `false` | Alpha | 1.14 | 1.14 |
|
||||
| `VolumeSubpathEnvExpansion` | `true` | Beta | 1.15 | |
|
||||
| `VolumeSnapshotDataSource` | `false` | Alpha | 1.12 | - |
|
||||
| `ScheduleDaemonSetPods` | `false` | Alpha | 1.11 | 1.11 |
|
||||
| `ScheduleDaemonSetPods` | `true` | Beta | 1.12 | |
|
||||
| `WatchBookmark` | `false` | Alpha | 1.15 | |
|
||||
| `WatchBookmark` | `false` | Alpha | 1.15 | 1.15 |
|
||||
| `WatchBookmark` | `true` | Beta | 1.16 | |
|
||||
| `WindowsGMSA` | `false` | Alpha | 1.14 | |
|
||||
| `WindowsGMSA` | `true` | Beta | 1.16 | |
|
||||
| `WinDSR` | `false` | Alpha | 1.14 | |
|
||||
| `WinOverlay` | `false` | Alpha | 1.14 | |
|
||||
{{< /table >}}
|
||||
|
||||
### GraduatedまたはDeprecatedのフィーチャーゲート {#feature-gates-for-graduated-or-deprecated-features}
|
||||
|
||||
{{< table caption="GraduatedまたはDeprecatedのフィーチャーゲート" >}}
|
||||
|
||||
| 機能名 | デフォルト値 | ステージ | 導入開始バージョン | 最終利用可能バージョン |
|
||||
|---------|---------|-------|-------|-------|
|
||||
| `Accelerators` | `false` | Alpha | 1.6 | 1.10 |
|
||||
| `Accelerators` | - | Deprecated | 1.11 | - |
|
||||
| `AdvancedAuditing` | `false` | Alpha | 1.7 | 1.7 |
|
||||
| `AdvancedAuditing` | `true` | Beta | 1.8 | 1.11 |
|
||||
| `AdvancedAuditing` | `true` | GA | 1.12 | - |
|
||||
| `AffinityInAnnotations` | `false` | Alpha | 1.6 | 1.7 |
|
||||
| `AffinityInAnnotations` | - | Deprecated | 1.8 | - |
|
||||
| `AllowExtTrafficLocalEndpoints` | `false` | Beta | 1.4 | 1.6 |
|
||||
| `AllowExtTrafficLocalEndpoints` | `true` | GA | 1.7 | - |
|
||||
| `CSIPersistentVolume` | `false` | Alpha | 1.9 | 1.9 |
|
||||
| `CSIPersistentVolume` | `true` | Beta | 1.10 | 1.12 |
|
||||
| `CSIPersistentVolume` | `true` | GA | 1.13 | - |
|
||||
| `CustomPodDNS` | `false` | Alpha | 1.9 | 1.9 |
|
||||
| `CustomPodDNS` | `true` | Beta| 1.10 | 1.13 |
|
||||
| `CustomPodDNS` | `true` | GA | 1.14 | - |
|
||||
| `CustomResourcePublishOpenAPI` | `false` | Alpha| 1.14 | 1.14 |
|
||||
| `CustomResourcePublishOpenAPI` | `true` | Beta| 1.15 | 1.15 |
|
||||
| `CustomResourcePublishOpenAPI` | `true` | GA | 1.16 | - |
|
||||
| `CustomResourceSubresources` | `false` | Alpha | 1.10 | 1.10 |
|
||||
| `CustomResourceSubresources` | `true` | Beta | 1.11 | 1.15 |
|
||||
| `CustomResourceSubresources` | `true` | GA | 1.16 | - |
|
||||
| `CustomResourceValidation` | `false` | Alpha | 1.8 | 1.8 |
|
||||
| `CustomResourceValidation` | `true` | Beta | 1.9 | 1.15 |
|
||||
| `CustomResourceValidation` | `true` | GA | 1.16 | - |
|
||||
| `CustomResourceWebhookConversion` | `false` | Alpha | 1.13 | 1.14 |
|
||||
| `CustomResourceWebhookConversion` | `true` | Beta | 1.15 | 1.15 |
|
||||
| `CustomResourceWebhookConversion` | `true` | GA | 1.16 | - |
|
||||
| `DynamicProvisioningScheduling` | `false` | Alpha | 1.11 | 1.11 |
|
||||
| `DynamicProvisioningScheduling` | - | Deprecated| 1.12 | - |
|
||||
| `DynamicVolumeProvisioning` | `true` | Alpha | 1.3 | 1.7 |
|
||||
| `DynamicVolumeProvisioning` | `true` | GA | 1.8 | - |
|
||||
| `EnableEquivalenceClassCache` | `false` | Alpha | 1.8 | 1.14 |
|
||||
| `EnableEquivalenceClassCache` | - | Deprecated | 1.15 | - |
|
||||
| `ExperimentalCriticalPodAnnotation` | `false` | Alpha | 1.5 | 1.12 |
|
||||
| `ExperimentalCriticalPodAnnotation` | `false` | Deprecated | 1.13 | - |
|
||||
| `GCERegionalPersistentDisk` | `true` | Beta | 1.10 | 1.12 |
|
||||
| `GCERegionalPersistentDisk` | `true` | GA | 1.13 | - |
|
||||
| `HugePages` | `false` | Alpha | 1.8 | 1.9 |
|
||||
| `HugePages` | `true` | Beta| 1.10 | 1.13 |
|
||||
| `HugePages` | `true` | GA | 1.14 | - |
|
||||
| `Initializers` | `false` | Alpha | 1.7 | 1.13 |
|
||||
| `Initializers` | - | Deprecated | 1.14 | - |
|
||||
| `KubeletConfigFile` | `false` | Alpha | 1.8 | 1.9 |
|
||||
| `KubeletConfigFile` | - | Deprecated | 1.10 | - |
|
||||
| `KubeletPluginsWatcher` | `false` | Alpha | 1.11 | 1.11 |
|
||||
| `KubeletPluginsWatcher` | `true` | Beta | 1.12 | 1.12 |
|
||||
| `KubeletPluginsWatcher` | `true` | GA | 1.13 | - |
|
||||
| `MountPropagation` | `false` | Alpha | 1.8 | 1.9 |
|
||||
| `MountPropagation` | `true` | Beta | 1.10 | 1.11 |
|
||||
| `MountPropagation` | `true` | GA | 1.12 | - |
|
||||
| `PersistentLocalVolumes` | `false` | Alpha | 1.7 | 1.9 |
|
||||
| `PersistentLocalVolumes` | `true` | Beta | 1.10 | 1.13 |
|
||||
| `PersistentLocalVolumes` | `true` | GA | 1.14 | - |
|
||||
| `PodPriority` | `false` | Alpha | 1.8 | 1.10 |
|
||||
| `PodPriority` | `true` | Beta | 1.11 | 1.13 |
|
||||
| `PodPriority` | `true` | GA | 1.14 | - |
|
||||
| `PodReadinessGates` | `false` | Alpha | 1.11 | 1.11 |
|
||||
| `PodReadinessGates` | `true` | Beta | 1.12 | 1.13 |
|
||||
| `PodReadinessGates` | `true` | GA | 1.14 | - |
|
||||
| `PVCProtection` | `false` | Alpha | 1.9 | 1.9 |
|
||||
| `PVCProtection` | - | Deprecated | 1.10 | - |
|
||||
| `StorageObjectInUseProtection` | `true` | Beta | 1.10 | 1.10 |
|
||||
| `StorageObjectInUseProtection` | `true` | GA | 1.11 | - |
|
||||
| `SupportIPVSProxyMode` | `false` | Alpha | 1.8 | 1.8 |
|
||||
| `SupportIPVSProxyMode` | `false` | Beta | 1.9 | 1.9 |
|
||||
| `SupportIPVSProxyMode` | `true` | Beta | 1.10 | 1.10 |
|
||||
| `SupportIPVSProxyMode` | `true` | GA | 1.11 | - |
|
||||
| `VolumeScheduling` | `false` | Alpha | 1.9 | 1.9 |
|
||||
| `VolumeScheduling` | `true` | Beta | 1.10 | 1.12 |
|
||||
| `VolumeScheduling` | `true` | GA | 1.13 | - |
|
||||
| `VolumeSubpath` | `true` | GA | 1.13 | - |
|
||||
{{< /table >}}
|
||||
|
||||
## 機能を使用する
|
||||
|
||||
### 機能ステージ
|
||||
### 機能のステージ {#feature-stages}
|
||||
|
||||
機能には *Alpha* 、 *Beta* 、 *GA* の段階があります。
|
||||
*Alpha* 機能とは：
|
||||
機能には*Alpha* 、*Beta* 、*GA* の段階があります。*Alpha* 機能とは：
|
||||
|
||||
* デフォルトでは無効になっています。
|
||||
* バグがあるかもしれません。機能を有効にするとバグが発生する可能性があります。
|
||||
|
|
@ -207,8 +258,9 @@ kubeletなどのコンポーネントにフィーチャーゲートを設定す
|
|||
GAになってからさらなる変更を加えることは現実的ではない場合があります。
|
||||
{{< /note >}}
|
||||
|
||||
*GA* 機能とは(*GA* 機能は *安定版* 機能とも呼ばれます):
|
||||
*GA* 機能とは(*GA* 機能は*安定版* 機能とも呼ばれます):
|
||||
|
||||
* 機能は常に有効となり、無効にすることはできません。
|
||||
* フィーチャーゲートの設定は不要になります。
|
||||
* 機能の安定版は後続バージョンでリリースされたソフトウェアで使用されます。
|
||||
|
||||
|
|
@ -224,6 +276,7 @@ GAになってからさらなる変更を加えることは現実的ではない
|
|||
- `APIResponseCompression`:`LIST`や`GET`リクエストのAPIレスポンスを圧縮します。
|
||||
- `AppArmor`: Dockerを使用する場合にLinuxノードでAppArmorによる強制アクセスコントロールを有効にします。詳細は[AppArmorチュートリアル](/docs/tutorials/clusters/apparmor/)で確認できます。
|
||||
- `AttachVolumeLimit`: ボリュームプラグインを有効にすることでノードにアタッチできるボリューム数の制限を設定できます。
|
||||
- `BalanceAttachedNodeVolumes`: スケジューリング中にバランスのとれたリソース割り当てを考慮するノードのボリュームカウントを含めます。判断を行う際に、CPU、メモリー使用率、およびボリュームカウントが近いノードがスケジューラーによって優先されます。
|
||||
- `BlockVolume`: PodでRawブロックデバイスの定義と使用を有効にします。詳細は[Rawブロックボリュームのサポート](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)で確認できます。
|
||||
- `BoundServiceAccountTokenVolume`: ServiceAccountTokenVolumeProjectionによって構成される計画ボリュームを使用するにはServiceAccountボリュームを移行します。詳細は[Service Account Token Volumes](https://git.k8s.io/community/contributors/design-proposals/storage/svcacct-token-volume-source.md)で確認できます。
|
||||
- `CPUManager`: コンテナレベルのCPUアフィニティサポートを有効します。[CPUマネジメントポリシー](/docs/tasks/administer-cluster/cpu-management-policies/)を見てください。
|
||||
|
|
@ -242,39 +295,49 @@ GAになってからさらなる変更を加えることは現実的ではない
|
|||
詳細については[`csi`ボリュームタイプ](/docs/concepts/storage/volumes/#csi)ドキュメントを確認してください。
|
||||
- `CustomCPUCFSQuotaPeriod`: ノードがCPUCFSQuotaPeriodを変更できるようにします。
|
||||
- `CustomPodDNS`: `dnsConfig`プロパティを使用したPodのDNS設定のカスタマイズを有効にします。詳細は[PodのDNS構成](/docs/concepts/services-networking/dns-pod-service/#pods-dns-config)で確認できます。
|
||||
- `CustomResourceDefaulting`: OpenAPI v3バリデーションスキーマにおいて、デフォルト値のCRDサポートを有効にします。
|
||||
- `CustomResourcePublishOpenAPI`: CRDのOpenAPI仕様での公開を有効にします。
|
||||
- `CustomResourceSubresources`: [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/)から作成されたリソースの`/status`および`/scale`サブリソースを有効にします。
|
||||
- `CustomResourceValidation`: [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/)から作成されたリソースのスキーマによる検証を有効にする。
|
||||
- `CustomResourceValidation`: [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/)から作成されたリソースのスキーマによる検証を有効にします。
|
||||
- `CustomResourceWebhookConversion`: [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/)から作成されたリソースのWebhookベースの変換を有効にします。
|
||||
- `DebugContainers`: Podのネームスペースで「デバッグ」コンテナを実行できるようにして実行中のPodのトラブルシューティングを行います。
|
||||
- `DevicePlugins`: [device-plugins](/docs/concepts/cluster-administration/device-plugins/)によるノードでのリソースプロビジョニングを有効にします。
|
||||
- `DryRun`: サーバーサイドでの[dry run](/docs/reference/using-api/api-concepts/#dry-run)リクエストを有効にします。
|
||||
- `DynamicAuditing`: [動的監査](/docs/tasks/debug-application-cluster/audit/#dynamic-backend)を有効にします。
|
||||
- `DynamicKubeletConfig`: kubeletの動的構成を有効にします。[kubeletの再設定](/docs/tasks/administer-cluster/reconfigure-kubelet/)を参照してください。
|
||||
- `DynamicProvisioningScheduling`: デフォルトのスケジューラーを拡張してボリュームトポロジーを認識しPVプロビジョニングを処理します。この機能は、v1.12の`VolumeScheduling`機能に完全に置き換えられました。
|
||||
- `DynamicVolumeProvisioning`(*非推奨*): Podへの永続ボリュームの[動的プロビジョニング](/docs/concepts/storage/dynamic-provisioning/)を有効にします。
|
||||
- `EnableAggregatedDiscoveryTimeout` (*非推奨*): 集約されたディスカバリーコールで5秒のタイムアウトを有効にします。
|
||||
- `EnableEquivalenceClassCache`: Podをスケジュールするときにスケジューラーがノードの同等をキャッシュできるようにします。
|
||||
- `EphemeralContainers`: 稼働するPodに{{< glossary_tooltip text="ephemeral containers" term_id="ephemeral-container" >}}を追加する機能を有効にします。
|
||||
- `EvenPodsSpread`: Podをトポロジードメイン全体で均等にスケジュールできるようにします。[Even Pods Spread](/docs/concepts/configuration/even-pods-spread)をご覧ください。
|
||||
- `ExpandInUsePersistentVolumes`: 使用中のPVCのボリューム拡張を有効にします。[使用中のPersistentVolumeClaimのサイズ変更](/docs/concepts/storage/persistent-volumes/#resizing-an-in-use-persistentvolumeclaim)を参照してください。
|
||||
- `ExpandPersistentVolumes`: 永続ボリュームの拡張を有効にします。[永続ボリューム要求の拡張](/docs/concepts/storage/persistent-volumes/#expanding-persistent-volumes-claims)を参照してください。
|
||||
- `ExperimentalCriticalPodAnnotation`: [スケジューリングが保証されるよう](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/)に特定のpodへの *クリティカル* の注釈を加える設定を有効にします。
|
||||
- `ExperimentalHostUserNamespaceDefaultingGate`: ホストするデフォルトのユーザー名前空間を有効にします。これは他のホストの名前空間やホストのマウントを使用しているコンテナ、特権を持つコンテナ、または名前空間のない特定の機能（たとえば`MKNODE`、`SYS_MODULE`など）を使用しているコンテナ用です。これはDockerデーモンでユーザー名前空間の再マッピングが有効になっている場合にのみ有効にすべきです。
|
||||
- `EndpointSlice`: よりスケーラブルで拡張可能なネットワークエンドポイントのエンドポイントスライスを有効にします。対応するAPIとコントローラーを有効にする必要があります。[Enabling Endpoint Slices](/docs/tasks/administer-cluster/enabling-endpoint-slices/)をご覧ください。
|
||||
- `GCERegionalPersistentDisk`: GCEでリージョナルPD機能を有効にします。
|
||||
- `HugePages`: 事前に割り当てられた[huge pages](/docs/tasks/manage-hugepages/scheduling-hugepages/)の割り当てと消費を有効にします。
|
||||
- `HyperVContainer`: Windowsコンテナの[Hyper-Vによる分離](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container)を有効にします。
|
||||
- `HPAScaleToZero`: カスタムメトリクスまたは外部メトリクスを使用するときに、`HorizontalPodAutoscaler`リソースの`minReplicas`を0に設定できるようにします。
|
||||
- `KubeletConfigFile`: 設定ファイルを使用して指定されたファイルからのkubelet設定の読み込みを有効にします。詳細は[設定ファイルによるkubeletパラメーターの設定](/docs/tasks/administer-cluster/kubelet-config-file/)で確認できます。
|
||||
- `KubeletPluginsWatcher`: 調査ベースのプラグイン監視ユーティリティを有効にしてkubeletが[CSIボリュームドライバー](/docs/concepts/storage/volumes/#csi)などのプラグインを検出できるようにします。
|
||||
- `KubeletPodResources`: kubeletのpodのリソースgrpcエンドポイントを有効にします。詳細は[デバイスモニタリングのサポート](https://git.k8s.io/community/keps/sig-node/compute-device-assignment.md)で確認できます。
|
||||
- `LegacyNodeRoleBehavior`: 無効にすると、サービスロードバランサーの従来の動作とノードの中断により機能固有のラベルが優先され、`node-role.kubernetes.io/master`ラベルが無視されます。
|
||||
- `LocalStorageCapacityIsolation`: [ローカルの一時ストレージ](/docs/concepts/configuration/manage-compute-resources-container/)の消費を有効にして、[emptyDirボリューム](/docs/concepts/storage/volumes/#emptydir)の`sizeLimit`プロパティも有効にします。
|
||||
- `LocalStorageCapacityIsolationFSQuotaMonitoring`: `LocalStorageCapacityIsolation`が[ローカルの一時ストレージ](/docs/concepts/configuration/manage-compute-resources-container/)で有効になっていて、[emptyDirボリューム](/docs/concepts/storage/volumes/#emptydir)のbacking filesystemがプロジェクトクォータをサポートし有効になっている場合、プロジェクトクォータを使用して、パフォーマンスと精度を向上させるために、ファイルシステムへのアクセスではなく[emptyDirボリューム](/docs/concepts/storage/volumes/#emptydir)ストレージ消費を監視します。
|
||||
- `MountContainers`: ホスト上のユーティリティコンテナをボリュームマウンターとして使用できるようにします。
|
||||
- `MountPropagation`: あるコンテナによってマウントされたボリュームを他のコンテナまたはpodに共有できるようにします。詳細は[マウントの伝播](/docs/concepts/storage/volumes/#mount-propagation)で確認できます。
|
||||
- `NodeDisruptionExclusion`: ノードラベル`node.kubernetes.io/exclude-disruption`の使用を有効にします。これにより、ゾーン障害時にノードが退避するのを防ぎます。
|
||||
- `NodeLease`: 新しいLease APIを有効にしてノードヘルスシグナルとして使用できるノードのハートビートをレポートします。
|
||||
- `NonPreemptingPriority`: PriorityClassとPodのNonPreemptingオプションを有効にします。
|
||||
- `PersistentLocalVolumes`: Podで`local`ボリュームタイプの使用を有効にします。`local`ボリュームを要求する場合、podアフィニティを指定する必要があります。
|
||||
- `PodOverhead`: [PodOverhead](/docs/concepts/configuration/pod-overhead/)機能を有効にして、Podのオーバーヘッドを考慮するようにします。
|
||||
- `PodPriority`: [優先度](/docs/concepts/configuration/pod-priority-preemption/)に基づいてPodの再スケジューリングとプリエンプションを有効にします。
|
||||
- `PodReadinessGates`: Podのreadinessの評価を拡張するために`PodReadinessGate`フィールドの設定を有効にします。詳細は[Pod readiness gate](/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)で確認できます。
|
||||
- `PodShareProcessNamespace`: Podで実行されているコンテナ間で単一のプロセス名前空間を共有するには、Podで`shareProcessNamespace`の設定を有効にします。 詳細については、[Pod内のコンテナ間でプロセス名前空間を共有する](/docs/tasks/configure-pod-container/share-process-namespace/)をご覧ください。
|
||||
- `ProcMountType`: コンテナのProcMountTypeの制御を有効にします。
|
||||
- `PVCProtection`: 永続ボリューム要求（PVC）がPodでまだ使用されているときに削除されないようにします。詳細は[ここ](/docs/tasks/administer-cluster/storage-object-in-use-protection/)で確認できます。
|
||||
- `QOSReserved`: QoSレベルでのリソース予約を許可して、低いQoSレベルのポッドが高いQoSレベルで要求されたリソースにバーストするのを防ぎます（現時点ではメモリのみ）。
|
||||
- `ResourceLimitsPriorityFunction`: 入力したPodのCPU制限とメモリ制限の少なくとも1つを満たすノードに対して最低スコアを1に割り当てるスケジューラー優先機能を有効にします。その目的は同じスコアを持つノード間の関係を断つことです。
|
||||
- `RequestManagement`: 各サーバーで優先順位付けと公平性を備えたリクエストの並行性の管理機能を有効にしました。
|
||||
- `ResourceQuotaScopeSelectors`: リソース割当のスコープセレクターを有効にします。
|
||||
|
|
@ -287,6 +350,7 @@ GAになってからさらなる変更を加えることは現実的ではない
|
|||
- `ServerSideApply`: APIサーバーで[サーバーサイドApply(SSA)](/docs/reference/using-api/api-concepts/#server-side-apply)のパスを有効にします。
|
||||
- `ServiceLoadBalancerFinalizer`: サービスロードバランサーのファイナライザー保護を有効にします。
|
||||
- `ServiceNodeExclusion`: クラウドプロバイダーによって作成されたロードバランサーからのノードの除外を有効にします。"`alpha.service-controller.kubernetes.io/exclude-balancer`"キーでラベル付けされている場合ノードは除外の対象となります。
|
||||
- `StartupProbe`: kubeletで[startup](/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-startup-probe)プローブを有効にします。
|
||||
- `StorageObjectInUseProtection`: PersistentVolumeまたはPersistentVolumeClaimオブジェクトがまだ使用されている場合、それらの削除を延期します。
|
||||
- `StorageVersionHash`: apiserversがディスカバリーでストレージのバージョンハッシュを公開できるようにします。
|
||||
- `StreamingProxyRedirects`: ストリーミングリクエストのバックエンド(kubelet)からのリダイレクトをインターセプト（およびフォロー）するようAPIサーバーに指示します。ストリーミングリクエストの例には`exec`、`attach`、`port-forward`リクエストが含まれます。
|
||||
|
|
@ -304,5 +368,10 @@ GAになってからさらなる変更を加えることは現実的ではない
|
|||
- `VolumeSubpathEnvExpansion`: 環境変数を`subPath`に展開するための`subPathExpr`フィールドを有効にします。
|
||||
- `WatchBookmark`: ブックマークイベントの監視サポートを有効にします。
|
||||
- `WindowsGMSA`: GMSA資格仕様をpodからコンテナランタイムに渡せるようにします。
|
||||
- `WinDSR`: kube-proxyがWindows用のDSRロードバランサーを作成できるようにします。
|
||||
- `WinOverlay`: kube-proxyをWindowsのオーバーレイモードで実行できるようにします。
|
||||
|
||||
{{% /capture %}}
|
||||
{{% capture whatsnext %}}
|
||||
* Kubernetesの[非推奨ポリシー](/docs/reference/using-api/deprecation-policy/)では、機能とコンポーネントを削除するためのプロジェクトのアプローチを説明しています。
|
||||
{{% /capture %}}
|
||||
|
|
|
|||
|
|
@ -0,0 +1,18 @@
|
|||
---
|
||||
title: クラスター
|
||||
id: cluster
|
||||
date: 2019-06-15
|
||||
full_link:
|
||||
short_description: >
|
||||
|
||||
Kubernetesが管理するコンテナ化されたアプリケーションを実行する、ノードと呼ばれるマシンの集合です。クラスターには、少なくとも1つのワーカーノードと少なくとも1つのマスターノードがあります。
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- operation
|
||||
---
|
||||
Kubernetesが管理するコンテナ化されたアプリケーションを実行する、ノードと呼ばれるマシンの集合です。クラスターには、少なくとも1つのワーカーノードと少なくとも1つのマスターノードがあります。
|
||||
|
||||
<!--more-->
|
||||
ワーカーノードは、アプリケーションのコンポーネントであるPodをホストします。マスターノードは、クラスター内のワーカーノードとPodを管理します。複数のマスターノードを使用して、クラスターにフェイルオーバーと高可用性を提供します。
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
---
|
||||
title: Ingress
|
||||
id: ingress
|
||||
date: 2018-04-12
|
||||
full_link: /docs/ja/concepts/services-networking/ingress/
|
||||
short_description: >
|
||||
クラスター内のServiceに対する外部からのアクセス(主にHTTP)を管理するAPIオブジェクトです。
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- networking
|
||||
- architecture
|
||||
- extension
|
||||
---
|
||||
クラスター内のServiceに対する外部からのアクセス(主にHTTP)を管理するAPIオブジェクトです。
|
||||
|
||||
<!--more-->
|
||||
|
||||
Ingressは負荷分散、SSL終端、名前ベースの仮想ホスティングの機能を提供します。
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
title: "kubectl CLI"
|
||||
weight: 60
|
||||
---
|
||||
|
||||
|
|
@ -0,0 +1,384 @@
|
|||
---
|
||||
title: kubectlチートシート
|
||||
content_template: templates/concept
|
||||
card:
|
||||
name: reference
|
||||
weight: 30
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
[Kubectl概要](/docs/reference/kubectl/overview/)と[JsonPathガイド](/docs/reference/kubectl/jsonpath)も合わせてご覧ください。
|
||||
|
||||
このページは`kubectl`コマンドの概要です。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
# kubectl - チートシート
|
||||
|
||||
## Kubectlコマンドの補完
|
||||
|
||||
### BASH
|
||||
|
||||
```bash
|
||||
source <(kubectl completion bash) # 現在のbashシェルにコマンド補完を設定するには、最初にbash-completionパッケージをインストールする必要があります。
|
||||
echo "source <(kubectl completion bash)" >> ~/.bashrc # bashシェルでのコマンド補完を永続化するために.bashrcに追記します。
|
||||
```
|
||||
|
||||
また、エイリアスを使用している場合にも`kubectl`コマンドを補完できます。
|
||||
|
||||
```bash
|
||||
alias k=kubectl
|
||||
complete -F __start_kubectl k
|
||||
```
|
||||
|
||||
### ZSH
|
||||
|
||||
```bash
|
||||
source <(kubectl completion zsh) # 現在のzshシェルでコマンド補完を設定します
|
||||
echo "if [ $commands[kubectl] ]; then source <(kubectl completion zsh); fi" >> ~/.zshrc # zshシェルでのコマンド補完を永続化するために.zshrcに追記します。
|
||||
```
|
||||
|
||||
## Kubectlコンテキストの設定
|
||||
|
||||
`kubectl`がどのKubernetesクラスターと通信するかを設定します。
|
||||
設定ファイル詳細については[kubeconfigを使用した複数クラスターとの認証](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)をご覧ください。
|
||||
|
||||
```bash
|
||||
kubectl config view # マージされたkubeconfigの設定を表示します。
|
||||
|
||||
# 複数のkubeconfigファイルを同時に読み込む場合はこのように記述します。
|
||||
KUBECONFIG=~/.kube/config:~/.kube/kubconfig2
|
||||
|
||||
kubectl config view
|
||||
|
||||
# e2eユーザのパスワードを取得します。
|
||||
kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}'
|
||||
|
||||
kubectl config view -o jsonpath='{.users[].name}' # 最初のユーザー名を表示します
|
||||
kubectl config view -o jsonpath='{.users[*].name}' # ユーザー名のリストを表示します
|
||||
kubectl config get-contexts # コンテキストのリストを表示します
|
||||
kubectl config current-context # 現在のコンテキストを表示します
|
||||
kubectl config use-context my-cluster-name # デフォルトのコンテキストをmy-cluster-nameに設定します
|
||||
|
||||
# basic認証をサポートする新たなクラスターをkubeconfigに追加します
|
||||
kubectl config set-credentials kubeuser/foo.kubernetes.com --username=kubeuser --password=kubepassword
|
||||
|
||||
# 現在のコンテキストでkubectlのサブコマンドのネームスペースを永続的に変更します
|
||||
kubectl config set-context --current --namespace=ggckad-s2
|
||||
|
||||
# 特定のユーザー名と名前空間を使用してコンテキストを設定します
|
||||
kubectl config set-context gce --user=cluster-admin --namespace=foo \
|
||||
&& kubectl config use-context gce
|
||||
|
||||
kubectl config unset users.foo # ユーザーfooを削除します
|
||||
```
|
||||
|
||||
## Apply
|
||||
|
||||
`apply`はKubernetesリソースを定義するファイルを通じてアプリケーションを管理します。`kubectl apply`を実行して、クラスター内のリソースを作成および更新します。これは、本番環境でKubernetesアプリケーションを管理する推奨方法です。
|
||||
詳しくは[Kubectl Book](https://kubectl.docs.kubernetes.io)をご覧ください。
|
||||
|
||||
|
||||
## Objectの作成
|
||||
|
||||
Kubernetesのマニフェストファイルは、jsonまたはyamlで定義できます。ファイル拡張子として、`.yaml`や`.yml`、`.json`が使えます。
|
||||
|
||||
```bash
|
||||
kubectl apply -f ./my-manifest.yaml # リソースを作成します
|
||||
kubectl apply -f ./my1.yaml -f ./my2.yaml # 複数のファイルからリソースを作成します
|
||||
kubectl apply -f ./dir # dirディレクトリ内のすべてのマニフェストファイルからリソースを作成します
|
||||
kubectl apply -f https://git.io/vPieo # urlで公開されているファイルからリソースを作成します
|
||||
kubectl create deployment nginx --image=nginx # 単一のnginx Deploymentを作成します
|
||||
kubectl explain pods,svc # PodおよびServiceマニフェストのドキュメントを取得します
|
||||
|
||||
# 標準入力から複数のYAMLオブジェクトを作成します
|
||||
|
||||
cat <<EOF | kubectl apply -f -
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: busybox-sleep
|
||||
spec:
|
||||
containers:
|
||||
- name: busybox
|
||||
image: busybox
|
||||
args:
|
||||
- sleep
|
||||
- "1000000"
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: busybox-sleep-less
|
||||
spec:
|
||||
containers:
|
||||
- name: busybox
|
||||
image: busybox
|
||||
args:
|
||||
- sleep
|
||||
- "1000"
|
||||
EOF
|
||||
|
||||
# いくつかの鍵を含むSecretを作成します
|
||||
|
||||
cat <<EOF | kubectl apply -f -
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: mysecret
|
||||
type: Opaque
|
||||
data:
|
||||
password: $(echo -n "s33msi4" | base64 -w0)
|
||||
username: $(echo -n "jane" | base64 -w0)
|
||||
EOF
|
||||
|
||||
```
|
||||
|
||||
## リソースの検索と閲覧
|
||||
|
||||
```bash
|
||||
# Getコマンドで基本的な情報を確認します
|
||||
kubectl get services # 現在のネームスペース上にあるすべてのサービスのリストを表示します
|
||||
kubectl get pods --all-namespaces # すべてのネームスペース上にあるすべてのPodのリストを表示します
|
||||
kubectl get pods -o wide # 現在のネームスペース上にあるすべてのPodについてより詳細なリストを表示します
|
||||
kubectl get deployment my-dep # 特定のDeploymentを表示します
|
||||
kubectl get pods # 現在のネームスペース上にあるすべてのPodのリストを表示します
|
||||
kubectl get pod my-pod -o yaml # PodのYAMLを表示します
|
||||
kubectl get pod my-pod -o yaml --export # クラスター固有の情報を除いたPodのマニフェストをYAMLで表示します
|
||||
|
||||
# Describeコマンドで詳細な情報を確認します
|
||||
kubectl describe nodes my-node
|
||||
kubectl describe pods my-pod
|
||||
|
||||
# 名前順にソートしたリストを表示します
|
||||
kubectl get services --sort-by=.metadata.name
|
||||
|
||||
# Restartカウント順にPodのリストを表示します
|
||||
kubectl get pods --sort-by='.status.containerStatuses[0].restartCount'
|
||||
|
||||
# capacity順にソートしたtestネームスペースに存在するPodのリストを表示します
|
||||
kubectl get pods -n test --sort-by=.spec.capacity.storage
|
||||
|
||||
# app=cassandraラベルのついたすべてのPodのversionラベルを表示します
|
||||
kubectl get pods --selector=app=cassandra -o \
|
||||
jsonpath='{.items[*].metadata.labels.version}'
|
||||
|
||||
# すべてのワーカーノードを取得します（セレクターを使用して、
|
||||
# 「node-role.kubernetes.io/master」という名前のラベルを持つ結果を除外します）
|
||||
kubectl get node --selector='!node-role.kubernetes.io/master'
|
||||
|
||||
# 現在のネームスペースでrunning状態のPodをリストを表示します
|
||||
kubectl get pods --field-selector=status.phase=Running
|
||||
|
||||
# すべてのノードのExternal IPをリストを表示します
|
||||
kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}'
|
||||
|
||||
# 特定のRCに属するPodの名前のリストを表示します
|
||||
# `jq`コマンドは複雑なjsonpathを変換する場合に便利であり、https://stedolan.github.io/jq/で見つけることが可能です
|
||||
|
||||
sel=${$(kubectl get rc my-rc --output=json | jq -j '.spec.selector | to_entries | .[] | "\(.key)=\(.value),"')%?}
|
||||
echo $(kubectl get pods --selector=$sel --output=jsonpath={.items..metadata.name})
|
||||
|
||||
# すべてのPod(またはラベル付けをサポートする他のKubernetesオブジェクト)のラベルのリストを表示します
|
||||
|
||||
kubectl get pods --show-labels
|
||||
|
||||
# どのノードがready状態か確認します
|
||||
|
||||
JSONPATH='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status};{end}{end}' \
|
||||
&& kubectl get nodes -o jsonpath="$JSONPATH" | grep "Ready=True"
|
||||
|
||||
# Podで現在使用中のSecretをすべて表示します
|
||||
|
||||
kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq
|
||||
|
||||
# タイムスタンプでソートされたEventのリストを表示します
|
||||
|
||||
kubectl get events --sort-by=.metadata.creationTimestamp
|
||||
```
|
||||
|
||||
## リソースのアップデート
|
||||
|
||||
version 1.11で`rolling-update`は廃止されました、代わりに`rollout`コマンドをお使いください(詳しくはこちらをご覧ください [CHANGELOG-1.11.md](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.11.md))。
|
||||
|
||||
```bash
|
||||
kubectl set image deployment/frontend www=image:v2 # frontend Deploymentのwwwコンテナイメージをv2にローリングアップデートします
|
||||
kubectl rollout history deployment/frontend # frontend Deploymentの改訂履歴を確認します
|
||||
kubectl rollout undo deployment/frontend # 1つ前のDeploymentにロールバックします
|
||||
kubectl rollout undo deployment/frontend --to-revision=2 # 特定のバージョンにロールバックします
|
||||
kubectl rollout status -w deployment/frontend # frontend Deploymentのローリングアップデートを状態をwatchします
|
||||
|
||||
|
||||
# これらのコマンドは1.11から廃止されました
|
||||
kubectl rolling-update frontend-v1 -f frontend-v2.json # (廃止) frontend-v1 Podをローリングアップデートします
|
||||
kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2 # (廃止) リソース名とイメージを変更します
|
||||
kubectl rolling-update frontend --image=image:v2 # (廃止) frontendのイメージを変更します
|
||||
kubectl rolling-update frontend-v1 frontend-v2 --rollback # (廃止) 現在実行中のローリングアップデートを中止します
|
||||
cat pod.json | kubectl replace -f - # 標準入力から渡されたJSONに基づいてPodを置き換えます
|
||||
|
||||
# リソースを強制的に削除してから再生成し、置き換えます。サービスの停止が発生します
|
||||
kubectl replace --force -f ./pod.json
|
||||
|
||||
# ReplicaSetリソースで作られたnginxについてServiceを作成します。これは、ポート80で提供され、コンテナへはポート8000で接続します
|
||||
kubectl expose rc nginx --port=80 --target-port=8000
|
||||
|
||||
# 単一コンテナのPodイメージのバージョン(タグ)をv4に更新します
|
||||
kubectl get pod mypod -o yaml | sed 's/\(image: myimage\):.*$/\1:v4/' | kubectl replace -f -
|
||||
|
||||
kubectl label pods my-pod new-label=awesome # ラベルを追加します
|
||||
kubectl annotate pods my-pod icon-url=http://goo.gl/XXBTWq # アノテーションを追加します
|
||||
kubectl autoscale deployment foo --min=2 --max=10 # "foo" Deploymentのオートスケーリングを行います
|
||||
```
|
||||
|
||||
## リソースへのパッチ適用
|
||||
|
||||
```bash
|
||||
# ノードを部分的に更新します
|
||||
kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}'
|
||||
|
||||
# コンテナのイメージを更新します。spec.containers[*].nameはマージキーであるため必須です
|
||||
kubectl patch pod valid-pod -p '{"spec":{"containers":[{"name":"kubernetes-serve-hostname","image":"new image"}]}}'
|
||||
|
||||
# ポテンシャル配列を含むJSONパッチを使用して、コンテナのイメージを更新します
|
||||
kubectl patch pod valid-pod --type='json' -p='[{"op": "replace", "path": "/spec/containers/0/image", "value":"new image"}]'
|
||||
|
||||
# ポテンシャル配列のJSONパッチを使用してDeploymentのlivenessProbeを無効にします
|
||||
kubectl patch deployment valid-deployment --type json -p='[{"op": "remove", "path": "/spec/template/spec/containers/0/livenessProbe"}]'
|
||||
|
||||
# ポテンシャル配列に新たな要素を追加します
|
||||
kubectl patch sa default --type='json' -p='[{"op": "add", "path": "/secrets/1", "value": {"name": "whatever" } }]'
|
||||
```
|
||||
|
||||
## リソースの編集
|
||||
|
||||
任意のエディターでAPIリソースを編集します。
|
||||
|
||||
```bash
|
||||
kubectl edit svc/docker-registry # docker-registryという名前のサービスを編集します
|
||||
KUBE_EDITOR="nano" kubectl edit svc/docker-registry # エディターを指定します
|
||||
```
|
||||
|
||||
## リソースのスケーリング
|
||||
|
||||
```bash
|
||||
kubectl scale --replicas=3 rs/foo # 「foo」という名前のレプリカセットを3にスケーリングします
|
||||
kubectl scale --replicas=3 -f foo.yaml # 「foo.yaml」で指定されたリソースを3にスケーリングします
|
||||
kubectl scale --current-replicas=2 --replicas=3 deployment/mysql # mysqlと名付けられたdeploymentの現在のサイズが2であれば、mysqlを3にスケーリングします
|
||||
kubectl scale --replicas=5 rc/foo rc/bar rc/baz # 複数のReplication controllerをスケーリングします
|
||||
```
|
||||
|
||||
## リソースの削除
|
||||
|
||||
```bash
|
||||
kubectl delete -f ./pod.json # pod.jsonで指定されたタイプと名前を使用してPodを削除します
|
||||
kubectl delete pod,service baz foo # 「baz」と「foo」の名前を持つPodとServiceを削除します
|
||||
kubectl delete pods,services -l name=myLabel # name=myLabelラベルを持つのPodとServiceを削除します
|
||||
kubectl -n my-ns delete pod,svc --all # 名前空間my-ns内のすべてのPodとServiceを削除します
|
||||
# awkコマンドのpattern1またはpattern2に一致するすべてのPodを削除します。
|
||||
kubectl get pods -n mynamespace --no-headers=true | awk '/pattern1|pattern2/{print $1}' | xargs kubectl delete -n mynamespace pod
|
||||
```
|
||||
|
||||
## 実行中のポッドとの対話処理
|
||||
|
||||
```bash
|
||||
kubectl logs my-pod # Podのログをダンプします(標準出力)
|
||||
kubectl logs -l name=myLabel # name=myLabelラベルの持つPodのログをダンプします(標準出力)
|
||||
kubectl logs my-pod --previous # 以前に存在したコンテナのPodログをダンプします(標準出力)
|
||||
kubectl logs my-pod -c my-container # 複数コンテナがあるPodで、特定のコンテナのログをダンプします(標準出力)
|
||||
kubectl logs -l name=myLabel -c my-container # name=mylabelラベルを持つPodのログをダンプします(標準出力)
|
||||
kubectl logs my-pod -c my-container --previous # 複数コンテナがあるPodで、以前に作成した特定のコンテナのログをダンプします(標準出力)
|
||||
kubectl logs -f my-pod # Podのログをストリームで確認します(標準出力)
|
||||
kubectl logs -f my-pod -c my-container # 複数のコンテナがあるPodで、特定のコンテナのログをストリームで確認します(標準出力)
|
||||
kubectl logs -f -l name=myLabel --all-containers # name-myLabelラベルを持つすべてのコンテナのログをストリームで確認します(標準出力)
|
||||
kubectl run -i --tty busybox --image=busybox -- sh # Podをインタラクティブシェルとして実行します
|
||||
kubectl run nginx --image=nginx --restart=Never -n
|
||||
mynamespace # 特定のネームスペースでnginx Podを実行します
|
||||
kubectl run nginx --image=nginx --restart=Never # nginx Podを実行し、マニフェストファイルををpod.yamlという名前で書き込みます
|
||||
--dry-run -o yaml > pod.yaml
|
||||
kubectl attach my-pod -i # 実行中のコンテナに接続します
|
||||
kubectl port-forward my-pod 5000:6000 # ローカルマシンのポート5000を、my-podのポート6000に転送します
|
||||
kubectl exec my-pod -- ls / # 既存のPodでコマンドを実行(単一コンテナの場合)
|
||||
kubectl exec my-pod -c my-container -- ls / # 既存のPodでコマンドを実行(複数コンテナがある場合)
|
||||
kubectl top pod POD_NAME --containers # 特定のPodとそのコンテナのメトリクスを表示します
|
||||
```
|
||||
|
||||
## ノードおよびクラスターとの対話処理
|
||||
|
||||
```bash
|
||||
kubectl cordon my-node # my-nodeにスケーリングされないように設定します
|
||||
kubectl drain my-node # メンテナンスの準備としてmy-nodeで動作中のPodを空にします
|
||||
kubectl uncordon my-node # my-nodeにスケーリングされるように設定します
|
||||
kubectl top node my-node # 特定のノードのメトリクスを表示します
|
||||
kubectl cluster-info # Kubernetesクラスターのマスターとサービスのアドレスを表示します
|
||||
kubectl cluster-info dump # 現在のクラスター状態を標準出力にダンプします
|
||||
kubectl cluster-info dump --output-directory=/path/to/cluster-state # 現在のクラスター状態を/path/to/cluster-stateにダンプします
|
||||
|
||||
# special-userキーとNoScheduleエフェクトを持つTaintが既に存在する場合、その値は指定されたとおりに置き換えられます
|
||||
kubectl taint nodes foo dedicated=special-user:NoSchedule
|
||||
```
|
||||
|
||||
### リソースタイプ
|
||||
|
||||
サポートされているすべてのリソースタイプを、それらが[API group](/docs/concepts/overview/kubernetes-api/#api-groups)か[Namespaced](/docs/concepts/overview/working-with-objects/namespaces)、[Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects)に関わらずその短縮名をリストします。
|
||||
|
||||
```bash
|
||||
kubectl api-resources
|
||||
```
|
||||
|
||||
APIリソースを探索するためのその他の操作:
|
||||
|
||||
```bash
|
||||
kubectl api-resources --namespaced=true # 名前空間付きのすべてのリソースを表示します
|
||||
kubectl api-resources --namespaced=false # 名前空間のないすべてのリソースを表示します
|
||||
kubectl api-resources -o name # すべてのリソースを単純な出力(リソース名のみ)で表示します
|
||||
kubectl api-resources -o wide # すべてのリソースを拡張された形(別名 "wide")で表示します
|
||||
kubectl api-resources --verbs=list,get # "list"および"get"操作をサポートするすべてのリソースを表示します
|
||||
kubectl api-resources --api-group=extensions # "extensions" APIグループのすべてのリソースを表示します
|
||||
```
|
||||
|
||||
### 出力のフォーマット
|
||||
|
||||
特定の形式で端末ウィンドウに詳細を出力するには、サポートされている`kubectl`コマンドに`-o`または`--output`フラグを追加します。
|
||||
|
||||
出力フォーマット | 説明
|
||||
---------------- | -----------
|
||||
`-o=custom-columns=<spec>` | カスタムカラムを使用してコンマ区切りのテーブルを表示します
|
||||
`-o=custom-columns-file=<filename>` | `<filename>`ファイル内のカスタムカラムテンプレートを使用してテーブルを表示します
|
||||
`-o=json` | JSON形式のAPIオブジェクトを出力します
|
||||
`-o=jsonpath=<template>` | [jsonpath](/docs/reference/kubectl/jsonpath)式で定義されたフィールドを出力します
|
||||
`-o=jsonpath-file=<filename>` | `<filename>`ファイル内の[jsonpath](/docs/reference/kubectl/jsonpath)式で定義されたフィールドを出力します
|
||||
`-o=name` | リソース名のみを出力し、それ以外は何も出力しません。
|
||||
`-o=wide` | 追加の情報を含むプレーンテキスト形式で出力します。Podの場合、Node名が含まれます。
|
||||
`-o=yaml` | YAML形式のAPIオブジェクトを出力します
|
||||
|
||||
### Kubectlのログレベルとデバッグ
|
||||
kubectlのログレベルは、レベルを表す整数が後に続く`-v`または`--v`フラグで制御されます。一般的なKubernetesのログ記録規則と関連するログレベルについて、[こちら](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md)で説明します。
|
||||
|
||||
ログレベル | 説明
|
||||
--------------| -----------
|
||||
`--v=0` | これは、クラスターオペレーターにログレベルが0であることを"常に"見えるようにするために役立ちます
|
||||
`--v=1` | 冗長性が必要ない場合は、妥当なデフォルトのログレベルです
|
||||
`--v=2` | サービスに関する重要な定常状態情報と、システムの重要な変更に関連する可能性がある重要なログメッセージを表示します。 これは、ほとんどのシステムで推奨されるデフォルトのログレベルです。
|
||||
`--v=3` | 変更に関するより詳細なログレベルを表示します
|
||||
`--v=4` | デバックにむいたログレベルで表示します
|
||||
`--v=6` | 要求されたリソースを表示します
|
||||
`--v=7` | HTTPリクエストのヘッダを表示します
|
||||
`--v=8` | HTTPリクエストのコンテンツを表示します
|
||||
`--v=9` | HTTPリクエストのコンテンツをtruncationなしで表示します
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* kubectlについてより深く学びたい方は[kubectl概要](/docs/reference/kubectl/overview/)をご覧ください。
|
||||
|
||||
* オプションについては[kubectl](/docs/reference/kubectl/kubectl/) optionsをご覧ください。
|
||||
|
||||
* また[kubectlの利用パターン](/docs/reference/kubectl/conventions/)では再利用可能なスクリプトでkubectlを利用する方法を学べます。
|
||||
|
||||
* コミュニティ版[kubectlチートシート](https://github.com/dennyzhang/cheatsheet-kubernetes-A4)もご覧ください。
|
||||
|
||||
{{% /capture %}}
|
||||
|
|
@ -37,8 +37,8 @@ Kubernetesについて学んでいる場合、Dockerベースのソリューシ
|
|||
|コミュニティ |エコシステム |
|
||||
| ------------ | -------- |
|
||||
| [Minikube](/ja/docs/setup/learning-environment/minikube/) | [CDK on LXD](https://www.ubuntu.com/kubernetes/docs/install-local) |
|
||||
| [Kubeadm-dind](https://github.com/kubernetes-sigs/kubeadm-dind-cluster) | [Docker Desktop](https://www.docker.com/products/docker-desktop)|
|
||||
| [Kubernetes IN Docker](https://github.com/kubernetes-sigs/kind) | [Minishift](https://docs.okd.io/latest/minishift/)|
|
||||
| [kind (Kubernetes IN Docker)](https://github.com/kubernetes-sigs/kind) | [Docker Desktop](https://www.docker.com/products/docker-desktop)|
|
||||
| | [Minishift](https://docs.okd.io/latest/minishift/)|
|
||||
| | [MicroK8s](https://microk8s.io/)|
|
||||
| | [IBM Cloud Private-CE (Community Edition)](https://github.com/IBM/deploy-ibm-cloud-private) |
|
||||
| | [IBM Cloud Private-CE (Community Edition) on Linux Containers](https://github.com/HSBawa/icp-ce-on-linux-containers)|
|
||||
|
|
@ -66,23 +66,27 @@ Kubernetesクラスタにおける抽象レイヤには {{< glossary_tooltip tex
|
|||
| [Amazon](https://aws.amazon.com) | [Amazon EKS](https://aws.amazon.com/eks/) |[Amazon EC2](https://aws.amazon.com/ec2/) | | | |
|
||||
| [AppsCode](https://appscode.com/products/pharmer/) | ✔ | | | | |
|
||||
| [APPUiO](https://appuio.ch/) | ✔ | ✔ | ✔ | | | |
|
||||
| [Banzai Cloud Pipeline Kubernetes Engine (PKE)](https://banzaicloud.com/products/pke/) | | ✔ | | ✔ | ✔ | ✔ |
|
||||
| [CenturyLink Cloud](https://www.ctl.io/) | | ✔ | | | |
|
||||
| [Cisco Container Platform](https://cisco.com/go/containers) | | | ✔ | | |
|
||||
| [Cloud Foundry Container Runtime (CFCR)](https://docs-cfcr.cfapps.io/) | | | | ✔ |✔ |
|
||||
| [CloudStack](https://cloudstack.apache.org/) | | | | | ✔|
|
||||
| [Canonical](https://www.ubuntu.com/kubernetes/docs/quickstart) | | ✔ | | ✔ |✔ | ✔
|
||||
| [Containership](https://containership.io/containership-platform) | ✔ |✔ | | | |
|
||||
| [Canonical](https://ubuntu.com/kubernetes) | ✔ | ✔ | ✔ | ✔ |✔ | ✔
|
||||
| [Containership](https://containership.io) | ✔ |✔ | | | |
|
||||
| [D2iQ](https://d2iq.com/) | | [Kommander](https://d2iq.com/solutions/ksphere) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) |
|
||||
| [Digital Rebar](https://provision.readthedocs.io/en/tip/README.html) | | | | | | ✔
|
||||
| [DigitalOcean](https://www.digitalocean.com/products/kubernetes/) | ✔ | | | | |
|
||||
| [Docker Enterprise](https://www.docker.com/products/docker-enterprise) | |✔ | ✔ | | | ✔
|
||||
| [Fedora (Multi Node)](https://kubernetes.io/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) | | | | | ✔ | ✔
|
||||
| [Fedora (Single Node)](https://kubernetes.io/docs/getting-started-guides/fedora/fedora_manual_config/) | | | | | | ✔
|
||||
| [Gardener](https://gardener.cloud/) | |✔ | | ✔ | |
|
||||
| [Giant Swarm](https://giantswarm.io/) | ✔ | ✔ | ✔ | |
|
||||
| [Gardener](https://gardener.cloud/) | ✔ | ✔ | ✔ | ✔ | ✔ | [Custom Extensions](https://github.com/gardener/gardener/blob/master/docs/extensions/overview.md) |
|
||||
| [Giant Swarm](https://www.giantswarm.io/) | ✔ | ✔ | ✔ | |
|
||||
| [Google](https://cloud.google.com/) | [Google Kubernetes Engine (GKE)](https://cloud.google.com/kubernetes-engine/) | [Google Compute Engine (GCE)](https://cloud.google.com/compute/)|[GKE On-Prem](https://cloud.google.com/gke-on-prem/) | | | | | | | |
|
||||
| [IBM](https://www.ibm.com/in-en/cloud) | [IBM Cloud Kubernetes Service](https://cloud.ibm.com/kubernetes/catalog/cluster)| |[IBM Cloud Private](https://www.ibm.com/in-en/cloud/private) | |
|
||||
| [Ionos](https://www.ionos.com/enterprise-cloud) | [Ionos Managed Kubernetes](https://www.ionos.com/enterprise-cloud/managed-kubernetes) | [Ionos Enterprise Cloud](https://www.ionos.com/enterprise-cloud) | |
|
||||
| [Kontena Pharos](https://www.kontena.io/pharos/) | |✔| ✔ | | |
|
||||
| [Kubermatic](https://www.loodse.com/) | ✔ | ✔ | ✔ | | |
|
||||
| [KubeOne](https://kubeone.io/) | | ✔ | ✔ | ✔ | ✔ | ✔ |
|
||||
| [Kubermatic](https://kubermatic.io/) | ✔ | ✔ | ✔ | ✔ | ✔ | |
|
||||
| [KubeSail](https://kubesail.com/) | ✔ | | | | |
|
||||
| [Kubespray](https://kubespray.io/#/) | | | |✔ | ✔ | ✔ |
|
||||
| [Kublr](https://kublr.com/) |✔ | ✔ |✔ |✔ |✔ |✔ |
|
||||
|
|
@ -90,17 +94,20 @@ Kubernetesクラスタにおける抽象レイヤには {{< glossary_tooltip tex
|
|||
| [Mirantis Cloud Platform](https://www.mirantis.com/software/kubernetes/) | | | ✔ | | |
|
||||
| [Nirmata](https://www.nirmata.com/) | | ✔ | ✔ | | |
|
||||
| [Nutanix](https://www.nutanix.com/en) | [Nutanix Karbon](https://www.nutanix.com/products/karbon) | [Nutanix Karbon](https://www.nutanix.com/products/karbon) | | | [Nutanix AHV](https://www.nutanix.com/products/acropolis/virtualization) |
|
||||
| [OpenNebula](https://www.opennebula.org) |[OpenNebula Kubernetes](https://marketplace.opennebula.systems/docs/service/kubernetes.html) | | | | |
|
||||
| [OpenShift](https://www.openshift.com) |[OpenShift Dedicated](https://www.openshift.com/products/dedicated/) and [OpenShift Online](https://www.openshift.com/products/online/) | | [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) | | [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) |[OpenShift Container Platform](https://www.openshift.com/products/container-platform/)
|
||||
| [Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE)](https://docs.cloud.oracle.com/iaas/Content/ContEng/Concepts/contengoverview.htm) | ✔ | ✔ | | | |
|
||||
| [oVirt](https://www.ovirt.org/) | | | | | ✔ |
|
||||
| [Pivotal](https://pivotal.io/) | | [Enterprise Pivotal Container Service (PKS)](https://pivotal.io/platform/pivotal-container-service) | [Enterprise Pivotal Container Service (PKS)](https://pivotal.io/platform/pivotal-container-service) | | |
|
||||
| [Platform9](https://platform9.com/) | ✔ | ✔ | ✔ | | ✔ |✔
|
||||
| [Platform9](https://platform9.com/) | [Platform9 Managed Kubernetes](https://platform9.com/managed-kubernetes/) | | [Platform9 Managed Kubernetes](https://platform9.com/managed-kubernetes/) | ✔ | ✔ | ✔
|
||||
| [Rancher](https://rancher.com/) | | [Rancher 2.x](https://rancher.com/docs/rancher/v2.x/en/) | | [Rancher Kubernetes Engine (RKE)](https://rancher.com/docs/rke/latest/en/) | | [k3s](https://k3s.io/)
|
||||
| [StackPoint](https://stackpoint.io/) | ✔ | ✔ | | | |
|
||||
| [Supergiant](https://supergiant.io/) | |✔ | | | |
|
||||
| [SUSE](https://www.suse.com/) | | ✔ | | | |
|
||||
| [SysEleven](https://www.syseleven.io/) | ✔ | | | | |
|
||||
| [Tencent Cloud](https://intl.cloud.tencent.com/) | [Tencent Kubernetes Engine](https://intl.cloud.tencent.com/product/tke) | ✔ | ✔ | | | ✔ |
|
||||
| [VEXXHOST](https://vexxhost.com/) | ✔ | ✔ | | | |
|
||||
| [VMware](https://cloud.vmware.com/) | [VMware Cloud PKS](https://cloud.vmware.com/vmware-cloud-pks) |[VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks) | [VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks) | [VMware Essential PKS](https://cloud.vmware.com/vmware-essential-pks) | |[VMware Essential PKS](https://cloud.vmware.com/vmware-essential-pks)
|
||||
| [Z.A.R.V.I.S.](https://zarvis.ai/) | ✔ | | | | | |
|
||||
|
||||
{{% /capture %}}
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
---
|
||||
title: Production environment
|
||||
title: プロダクション環境
|
||||
weight: 30
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
---
|
||||
title: Installing Kubernetes with deployment tools
|
||||
title: Kubernetesをデプロイツールでインストールする
|
||||
weight: 30
|
||||
---
|
||||
|
|
|
|||
|
|
@ -39,20 +39,80 @@ Download kops from the [releases page](https://github.com/kubernetes/kops/releas
|
|||
|
||||
On macOS:
|
||||
|
||||
Download the latest release with the command:
|
||||
|
||||
```shell
|
||||
curl -LO https://github.com/kubernetes/kops/releases/download/$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)/kops-darwin-amd64
|
||||
```
|
||||
|
||||
To download a specific version, replace the
|
||||
|
||||
```shell
|
||||
$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)
|
||||
```
|
||||
|
||||
portion of the command with the specific version.
|
||||
|
||||
For example, to download kops version v1.15.0 type:
|
||||
|
||||
```shell
|
||||
curl -LO https://github.com/kubernetes/kops/releases/download/1.15.0/kops-darwin-amd64
|
||||
```
|
||||
|
||||
Make the kops binary executable.
|
||||
|
||||
```shell
|
||||
curl -OL https://github.com/kubernetes/kops/releases/download/1.10.0/kops-darwin-amd64
|
||||
chmod +x kops-darwin-amd64
|
||||
mv kops-darwin-amd64 /usr/local/bin/kops
|
||||
# you can also install using Homebrew
|
||||
```
|
||||
|
||||
Move the kops binary in to your PATH.
|
||||
|
||||
```shell
|
||||
sudo mv kops-darwin-amd64 /usr/local/bin/kops
|
||||
```
|
||||
|
||||
You can also install kops using [Homebrew](https://brew.sh/).
|
||||
|
||||
```shell
|
||||
brew update && brew install kops
|
||||
```
|
||||
|
||||
On Linux:
|
||||
|
||||
Download the latest release with the command:
|
||||
|
||||
```shell
|
||||
curl -LO https://github.com/kubernetes/kops/releases/download/$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)/kops-linux-amd64
|
||||
```
|
||||
|
||||
To download a specific version, replace the
|
||||
```shell
|
||||
$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)
|
||||
```
|
||||
portion of the command with the specific version.
|
||||
|
||||
For example, to download kops version v1.15.0 type:
|
||||
|
||||
```shell
|
||||
curl -LO https://github.com/kubernetes/kops/releases/download/1.15.0/kops-linux-amd64
|
||||
```
|
||||
|
||||
Make the kops binary executable
|
||||
|
||||
```shell
|
||||
wget https://github.com/kubernetes/kops/releases/download/1.10.0/kops-linux-amd64
|
||||
chmod +x kops-linux-amd64
|
||||
mv kops-linux-amd64 /usr/local/bin/kops
|
||||
```
|
||||
|
||||
Move the kops binary in to your PATH.
|
||||
|
||||
```shell
|
||||
sudo mv kops-linux-amd64 /usr/local/bin/kops
|
||||
```
|
||||
|
||||
You can also install kops using [Homebrew](https://docs.brew.sh/Homebrew-on-Linux).
|
||||
|
||||
```shell
|
||||
brew update && brew install kops
|
||||
```
|
||||
|
||||
### (2/5) クラスタ用のroute53ドメインの作成
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
---
|
||||
title: "Bootstrapping clusters with kubeadm"
|
||||
title: "kubeadmを使ってクラスターを構築する"
|
||||
weight: 10
|
||||
---
|
||||
|
|
|
|||
|
|
@ -10,27 +10,27 @@ card:
|
|||
|
||||
{{% capture overview %}}
|
||||
|
||||
<img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px">This page shows how to install the `kubeadm` toolbox.
|
||||
For information how to create a cluster with kubeadm once you have performed this installation process, see the [Using kubeadm to Create a Cluster](/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) page.
|
||||
<img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px">
|
||||
このページでは`kubeadm`コマンドをインストールする方法を示します。このインストール処理実行後にkubeadmを使用してクラスターを作成する方法については、[kubeadmを使用したシングルマスタークラスターの作成](/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)を参照してください。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
* One or more machines running one of:
|
||||
* 次のいずれかが動作しているマシンが必要です
|
||||
- Ubuntu 16.04+
|
||||
- Debian 9
|
||||
- Debian 9+
|
||||
- CentOS 7
|
||||
- RHEL 7
|
||||
- Fedora 25/26 (best-effort)
|
||||
- Red Hat Enterprise Linux (RHEL) 7
|
||||
- Fedora 25+
|
||||
- HypriotOS v1.0.1+
|
||||
- Container Linux (tested with 1800.6.0)
|
||||
* 2 GB or more of RAM per machine (any less will leave little room for your apps)
|
||||
* 2 CPUs or more
|
||||
* Full network connectivity between all machines in the cluster (public or private network is fine)
|
||||
* Unique hostname, MAC address, and product_uuid for every node. See [here](#MACアドレスとproduct_uuidが全てのノードでユニークであることの検証) for more details.
|
||||
* Certain ports are open on your machines. See [here](#必須ポートの確認) for more details.
|
||||
* Swap disabled. You **MUST** disable swap in order for the kubelet to work properly.
|
||||
* 1台あたり2GB以上のメモリ(2GBの場合、アプリ用のスペースはほとんどありません)
|
||||
* 2コア以上のCPU
|
||||
* クラスター内のすべてのマシン間で通信可能なネットワーク(パブリックネットワークでもプライベートネットワークでも構いません)
|
||||
* ユニークなhostname、MACアドレス、とproduct_uuidが各ノードに必要です。詳細は[ここ](#MACアドレスとproduct_uuidが全てのノードでユニークであることの検証)を参照してください。
|
||||
* マシン内の特定のポートが開いていること。詳細は[ここ](#必須ポートの確認)を参照してください。
|
||||
* Swapがオフであること。kubeletが正常に動作するためにはswapは**必ず**オフでなければなりません。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
|
@ -38,125 +38,125 @@ For information how to create a cluster with kubeadm once you have performed thi
|
|||
|
||||
## MACアドレスとproduct_uuidが全てのノードでユニークであることの検証
|
||||
|
||||
* You can get the MAC address of the network interfaces using the command `ip link` or `ifconfig -a`
|
||||
* The product_uuid can be checked by using the command `sudo cat /sys/class/dmi/id/product_uuid`
|
||||
* ネットワークインターフェースのMACアドレスは`ip link`もしくは`ifconfig -a`コマンドで取得できます。
|
||||
* product_uuidは`sudo cat /sys/class/dmi/id/product_uuid`コマンドで確認できます。
|
||||
|
||||
It is very likely that hardware devices will have unique addresses, although some virtual machines may have
|
||||
identical values. Kubernetes uses these values to uniquely identify the nodes in the cluster.
|
||||
If these values are not unique to each node, the installation process
|
||||
may [fail](https://github.com/kubernetes/kubeadm/issues/31).
|
||||
ハードウェアデバイスではユニークなアドレスが割り当てられる可能性が非常に高いですが、VMでは同じになることがあります。Kubernetesはこれらの値を使用して、クラスター内のノードを一意に識別します。これらの値が各ノードに固有ではない場合、インストール処理が[失敗](https://github.com/kubernetes/kubeadm/issues/31)することもあります。
|
||||
|
||||
## ネットワークアダプタの確認
|
||||
|
||||
If you have more than one network adapter, and your Kubernetes components are not reachable on the default
|
||||
route, we recommend you add IP route(s) so Kubernetes cluster addresses go via the appropriate adapter.
|
||||
複数のネットワークアダプターがあり、Kubernetesコンポーネントにデフォルトで到達できない場合、IPルートを追加して、Kubernetesクラスターのアドレスが適切なアダプターを経由するように設定することをお勧めします。
|
||||
|
||||
## iptablesがnftablesバックエンドを使用しないようにする
|
||||
|
||||
Linuxでは、カーネルのiptablesサブシステムの最新の代替品としてnftablesが利用できます。`iptables`ツールは互換性レイヤーとして機能し、iptablesのように動作しますが、実際にはnftablesを設定します。このnftablesバックエンドは現在のkubeadmパッケージと互換性がありません。(ファイアウォールルールが重複し、`kube-proxy`を破壊するためです。)
|
||||
|
||||
もしあなたのシステムの`iptables`ツールがnftablesバックエンドを使用している場合、これらの問題を避けるために`iptables`ツールをレガシーモードに切り替える必要があります。これは、少なくともDebian 10(Buster)、Ubuntu 19.04、Fedora 29、およびこれらのディストリビューションの新しいリリースでのデフォルトです。RHEL 8はレガシーモードへの切り替えをサポートしていないため、現在のkubeadmパッケージと互換性がありません。
|
||||
|
||||
{{< tabs name="iptables_legacy" >}}
|
||||
{{% tab name="Debian or Ubuntu" %}}
|
||||
```bash
|
||||
sudo update-alternatives --set iptables /usr/sbin/iptables-legacy
|
||||
sudo update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy
|
||||
sudo update-alternatives --set arptables /usr/sbin/arptables-legacy
|
||||
sudo update-alternatives --set ebtables /usr/sbin/ebtables-legacy
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="Fedora" %}}
|
||||
```bash
|
||||
update-alternatives --set iptables /usr/sbin/iptables-legacy
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
## 必須ポートの確認
|
||||
|
||||
### マスターノード
|
||||
|
||||
| Protocol | Direction | Port Range | Purpose | Used By |
|
||||
|----------|-----------|------------|-------------------------|---------------------------|
|
||||
| TCP | Inbound | 6443* | Kubernetes API server | All |
|
||||
| TCP | Inbound | 2379-2380 | etcd server client API | kube-apiserver, etcd |
|
||||
| TCP | Inbound | 10250 | Kubelet API | Self, Control plane |
|
||||
| TCP | Inbound | 10251 | kube-scheduler | Self |
|
||||
| TCP | Inbound | 10252 | kube-controller-manager | Self |
|
||||
| プロトコル | 通信の向き | ポート範囲 | 目的 | 使用者 |
|
||||
|-----------|------------|------------|-------------------------|---------------------------|
|
||||
| TCP | Inbound | 6443* | Kubernetes API server | All |
|
||||
| TCP | Inbound | 2379-2380 | etcd server client API | kube-apiserver, etcd |
|
||||
| TCP | Inbound | 10250 | Kubelet API | Self, Control plane |
|
||||
| TCP | Inbound | 10251 | kube-scheduler | Self |
|
||||
| TCP | Inbound | 10252 | kube-controller-manager | Self |
|
||||
|
||||
### ワーカーノード
|
||||
|
||||
| Protocol | Direction | Port Range | Purpose | Used By |
|
||||
|----------|-----------|-------------|-----------------------|-------------------------|
|
||||
| TCP | Inbound | 10250 | Kubelet API | Self, Control plane |
|
||||
| TCP | Inbound | 30000-32767 | NodePort Services** | All |
|
||||
| プロトコル | 通信の向き | ポート範囲 | 目的 | 使用者 |
|
||||
|-----------|------------|-------------|-------------------------|-------------------------|
|
||||
| TCP | Inbound | 10250 | Kubelet API | Self, Control plane |
|
||||
| TCP | Inbound | 30000-32767 | NodePort Services** | All |
|
||||
|
||||
** Default port range for [NodePort Services](/docs/concepts/services-networking/service/).
|
||||
** [NodePort Services](/docs/concepts/services-networking/service/)のデフォルトのポートの範囲
|
||||
|
||||
Any port numbers marked with * are overridable, so you will need to ensure any
|
||||
custom ports you provide are also open.
|
||||
\*の項目は書き換え可能です。そのため、あなたが指定したカスタムポートも開いていることを確認する必要があります。
|
||||
|
||||
Although etcd ports are included in control-plane nodes, you can also host your own
|
||||
etcd cluster externally or on custom ports.
|
||||
etcdポートはコントロールプレーンノードに含まれていますが、独自のetcdクラスターを外部またはカスタムポートでホストすることもできます。
|
||||
|
||||
The pod network plugin you use (see below) may also require certain ports to be
|
||||
open. Since this differs with each pod network plugin, please see the
|
||||
documentation for the plugins about what port(s) those need.
|
||||
使用するPodネットワークプラグイン（以下を参照）のポートも開く必要があります。これは各Podネットワークプラグインによって異なるため、必要なポートについてはプラグインのドキュメントを参照してください。
|
||||
|
||||
## ランタイムのインストール
|
||||
|
||||
Since v1.6.0, Kubernetes has enabled the use of CRI, Container Runtime Interface, by default.
|
||||
v1.6.0以降、KubernetesはデフォルトでCRI(Container Runtime Interface)の使用を有効にしています。
|
||||
|
||||
Since v1.14.0, kubeadm will try to automatically detect the container runtime on Linux nodes
|
||||
by scanning through a list of well known domain sockets. The detectable runtimes and the
|
||||
socket paths, that are used, can be found in the table below.
|
||||
また、v1.14.0以降、kubeadmは既知のドメインソケットのリストをスキャンして、Linuxノード上のコンテナランタイムを自動的に検出しようとします。検出可能なランタイムとソケットパスは、以下の表に記載されています。
|
||||
|
||||
| Runtime | Domain Socket |
|
||||
| ランタイム | ドメインソケット |
|
||||
|------------|----------------------------------|
|
||||
| Docker | /var/run/docker.sock |
|
||||
| containerd | /run/containerd/containerd.sock |
|
||||
| CRI-O | /var/run/crio/crio.sock |
|
||||
|
||||
If both Docker and containerd are detected together, Docker takes precedence. This is
|
||||
needed, because Docker 18.09 ships with containerd and both are detectable.
|
||||
If any other two or more runtimes are detected, kubeadm will exit with an appropriate
|
||||
error message.
|
||||
Dockerとcontainerdの両方が同時に検出された場合、Dockerが優先されます。Docker 18.09にはcontainerdが同梱されており、両方が検出可能であるため、この仕様が必要です。他の2つ以上のランタイムが検出された場合、kubeadmは適切なエラーメッセージで終了します。
|
||||
|
||||
On non-Linux nodes the container runtime used by default is Docker.
|
||||
Linux以外のノードでは、デフォルトで使用されるコンテナランタイムはDockerです。
|
||||
|
||||
If the container runtime of choice is Docker, it is used through the built-in
|
||||
`dockershim` CRI implementation inside of the `kubelet`.
|
||||
もしコンテナランタイムとしてDockerを選択した場合、`kebelet`内に組み込まれた`dockershim` CRIが使用されます。
|
||||
|
||||
Other CRI-based runtimes include:
|
||||
その他のCRIに基づくランタイムでは以下を使用します
|
||||
|
||||
- [containerd](https://github.com/containerd/cri) (CRI plugin built into containerd)
|
||||
- [cri-o](https://cri-o.io/)
|
||||
- [frakti](https://github.com/kubernetes/frakti)
|
||||
|
||||
Refer to the [CRI installation instructions](/ja/docs/setup/production-environment/container-runtimes/) for more information.
|
||||
詳細は[CRIのインストール](/ja/docs/setup/production-environment/container-runtimes/)を参照してください。
|
||||
|
||||
## kubeadm、kubelet、kubectlのインストール
|
||||
|
||||
You will install these packages on all of your machines:
|
||||
以下のパッケージをマシン上にインストールしてください
|
||||
|
||||
* `kubeadm`: the command to bootstrap the cluster.
|
||||
* `kubeadm`: クラスターを起動するコマンドです。
|
||||
|
||||
* `kubelet`: the component that runs on all of the machines in your cluster
|
||||
and does things like starting pods and containers.
|
||||
* `kubelet`: クラスター内のすべてのマシンで実行されるコンポーネントです。
|
||||
Podやコンテナの起動などを行います。
|
||||
|
||||
* `kubectl`: the command line util to talk to your cluster.
|
||||
* `kubectl`: クラスターにアクセスするためのコマンドラインツールです。
|
||||
|
||||
kubeadm **will not** install or manage `kubelet` or `kubectl` for you, so you will
|
||||
need to ensure they match the version of the Kubernetes control plane you want
|
||||
kubeadm to install for you. If you do not, there is a risk of a version skew occurring that
|
||||
can lead to unexpected, buggy behaviour. However, _one_ minor version skew between the
|
||||
kubelet and the control plane is supported, but the kubelet version may never exceed the API
|
||||
server version. For example, kubelets running 1.7.0 should be fully compatible with a 1.8.0 API server,
|
||||
but not vice versa.
|
||||
kubeadmは`kubelet`や`kubectl`をインストールまたは管理**しない**ため、kubeadmにインストールするKubernetesコントロールプレーンのバージョンと一致させる必要があります。そうしないと、予期しないバグのある動作につながる可能性のあるバージョン差異(version skew)が発生するリスクがあります。ただし、kubeletとコントロールプレーン間のマイナーバージョン差異(minor version skew)は_1つ_サポートされていますが、kubeletバージョンがAPIサーバーのバージョンを超えることはできません。たとえば、1.7.0を実行するkubeletは1.8.0 APIサーバーと完全に互換性がありますが、その逆はできません。
|
||||
|
||||
For information about installing `kubectl`, see [Install and set up kubectl](/docs/tasks/tools/install-kubectl/).
|
||||
`kubectl`のインストールに関する詳細情報は、[kubectlのインストールおよびセットアップ](/docs/tasks/tools/install-kubectl/)を参照してください。
|
||||
|
||||
{{< warning >}}
|
||||
These instructions exclude all Kubernetes packages from any system upgrades.
|
||||
This is because kubeadm and Kubernetes require
|
||||
[special attention to upgrade](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-11/).
|
||||
これらの手順はシステムアップグレードによるすべてのKubernetesパッケージの更新を除きます。これはkubeadmとKubernetesが[アップグレードにおける特別な注意](docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)を必要とするからです。
|
||||
{{</ warning >}}
|
||||
|
||||
For more information on version skews, see:
|
||||
バージョン差異(version skew)に関しては下記を参照してください。
|
||||
|
||||
* Kubernetes [version and version-skew policy](/ja/docs/setup/release/version-skew-policy/)
|
||||
* Kubeadm-specific [version skew policy](/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#version-skew-policy)
|
||||
* Kubernetes [Kubernetesバージョンとバージョンスキューサポートポリシー](/ja/docs/setup/release/version-skew-policy/)
|
||||
* Kubeadm-specific [バージョン互換ポリシー](/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#version-skew-policy)
|
||||
|
||||
{{< tabs name="k8s_install" >}}
|
||||
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
|
||||
```bash
|
||||
apt-get update && apt-get install -y apt-transport-https curl
|
||||
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -
|
||||
cat <<EOF >/etc/apt/sources.list.d/kubernetes.list
|
||||
sudo apt-get update && sudo apt-get install -y apt-transport-https curl
|
||||
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
|
||||
cat <<EOF | sudo tee /etc/apt/sources.list.d/kubernetes.list
|
||||
deb https://apt.kubernetes.io/ kubernetes-xenial main
|
||||
EOF
|
||||
apt-get update
|
||||
apt-get install -y kubelet kubeadm kubectl
|
||||
apt-mark hold kubelet kubeadm kubectl
|
||||
sudo apt-get update
|
||||
sudo apt-get install -y kubelet kubeadm kubectl
|
||||
sudo apt-mark hold kubelet kubeadm kubectl
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="CentOS, RHEL or Fedora" %}}
|
||||
|
|
@ -201,17 +201,17 @@ systemctl enable --now kubelet
|
|||
Install CNI plugins (required for most pod network):
|
||||
|
||||
```bash
|
||||
CNI_VERSION="v0.7.5"
|
||||
CNI_VERSION="v0.8.2"
|
||||
mkdir -p /opt/cni/bin
|
||||
curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-amd64-${CNI_VERSION}.tgz" | tar -C /opt/cni/bin -xz
|
||||
curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-linux-amd64-${CNI_VERSION}.tgz" | tar -C /opt/cni/bin -xz
|
||||
```
|
||||
|
||||
Install crictl (required for kubeadm / Kubelet Container Runtime Interface (CRI))
|
||||
|
||||
```bash
|
||||
CRICTL_VERSION="v1.12.0"
|
||||
CRICTL_VERSION="v1.16.0"
|
||||
mkdir -p /opt/bin
|
||||
curl -L "https://github.com/kubernetes-incubator/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-amd64.tar.gz" | tar -C /opt/bin -xz
|
||||
curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-amd64.tar.gz" | tar -C /opt/bin -xz
|
||||
```
|
||||
|
||||
Install `kubeadm`, `kubelet`, `kubectl` and add a `kubelet` systemd service:
|
||||
|
|
@ -237,45 +237,37 @@ systemctl enable --now kubelet
|
|||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
kubeadmが何をすべきか指示するまで、kubeletはクラッシュループで数秒ごとに再起動します。
|
||||
|
||||
The kubelet is now restarting every few seconds, as it waits in a crashloop for
|
||||
kubeadm to tell it what to do.
|
||||
## マスターノードのkubeletによって使用されるcgroupドライバーの設定
|
||||
|
||||
## マスターノードのkubeletによって使用されるcgroupドライバの設定
|
||||
Dockerを使用した場合、kubeadmは自動的にkubelet向けのcgroupドライバーを検出し、それを実行時に`/var/lib/kubelet/kubeadm-flags.env`ファイルに設定します。
|
||||
|
||||
When using Docker, kubeadm will automatically detect the cgroup driver for the kubelet
|
||||
and set it in the `/var/lib/kubelet/kubeadm-flags.env` file during runtime.
|
||||
|
||||
If you are using a different CRI, you have to modify the file
|
||||
`/etc/default/kubelet` with your `cgroup-driver` value, like so:
|
||||
もしあなたが異なるCRIを使用している場合、`/etc/default/kubelet`(CentOS、RHEL、Fedoraでは`/etc/sysconfig/kubelet`)ファイル内の`cgroup-driver`の値を以下のように変更する必要があります。
|
||||
|
||||
```bash
|
||||
KUBELET_EXTRA_ARGS=--cgroup-driver=<value>
|
||||
```
|
||||
|
||||
This file will be used by `kubeadm init` and `kubeadm join` to source extra
|
||||
user defined arguments for the kubelet.
|
||||
このファイルは、kubeletの追加のユーザー定義引数を取得するために、`kubeadm init`および`kubeadm join`によって使用されます。
|
||||
|
||||
Please mind, that you **only** have to do that if the cgroup driver of your CRI
|
||||
is not `cgroupfs`, because that is the default value in the kubelet already.
|
||||
CRIのcgroupドライバーが`cgroupfs`でない場合に**のみ**それを行う必要があることに注意してください。なぜなら、これは既にkubeletのデフォルト値であるためです。
|
||||
|
||||
Restarting the kubelet is required:
|
||||
kubeletをリスタートする方法:
|
||||
|
||||
```bash
|
||||
systemctl daemon-reload
|
||||
systemctl restart kubelet
|
||||
```
|
||||
|
||||
The automatic detection of cgroup driver for other container runtimes
|
||||
like CRI-O and containerd is work in progress.
|
||||
|
||||
CRI-Oやcontainerdといった他のコンテナランタイムのcgroup driverは実行中に自動的に検出されます。
|
||||
|
||||
## トラブルシュート
|
||||
|
||||
If you are running into difficulties with kubeadm, please consult our [troubleshooting docs](/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/).
|
||||
kubeadmで問題が発生した場合は、[トラブルシューティング](/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/)を参照してください。
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* [Using kubeadm to Create a Cluster](/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)
|
||||
* [kubeadmを使用したシングルマスタークラスターの作成](/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)
|
||||
|
||||
{{% /capture %}}
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
---
|
||||
title: Turnkey Cloud Solutions
|
||||
title: ターンキークラウドソリューション
|
||||
weight: 40
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
---
|
||||
title: "Release notes and version skew"
|
||||
title: "リリースノート及びバージョンスキュー"
|
||||
weight: 10
|
||||
---
|
||||
|
|
|
|||
|
|
@ -0,0 +1,85 @@
|
|||
---
|
||||
title: タスク
|
||||
main_menu: true
|
||||
weight: 50
|
||||
content_template: templates/concept
|
||||
---
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
Kubernetesドキュメントのこのセクションには、個々のタスクの実行方法を示すページが含まれています。
|
||||
タスクページは、通常、短い手順を実行することにより、1つのことを行う方法を示します。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Web UI (ダッシュボード)
|
||||
|
||||
ダッシュボードWeb UIを展開してアクセスし、Kubernetesクラスター内のコンテナ化されたアプリケーションの管理と監視に役立てます。
|
||||
|
||||
## kubectlコマンドラインツールの使用
|
||||
|
||||
Kubernetesクラスターを直接管理するために使用される`kubectl`コマンドラインツールをインストールしてセットアップします。
|
||||
|
||||
## Podとコンテナの設定
|
||||
|
||||
Podとコンテナの一般的な設定タスクを実行します。
|
||||
|
||||
## アプリケーションの実行
|
||||
|
||||
ローリングアップデート、Podへの情報の注入、水平Podオートスケーリングなど、一般的なアプリケーション管理タスクを実行します。
|
||||
|
||||
## ジョブの実行
|
||||
|
||||
並列処理を使用してジョブを実行します。
|
||||
|
||||
## クラスター内のアプリケーションへのアクセス
|
||||
|
||||
クラスター内のアプリケーションにアクセスするために、負荷分散、ポート転送を設定するか、ファイアウォールまたはDNSの設定をセットアップします。
|
||||
|
||||
## 監視、ログ、デバッグ
|
||||
|
||||
クラスタのトラブルシューティングまたはコンテナ化されたアプリケーションのデバッグのために、監視とログを設定します。
|
||||
|
||||
## Kubernetes APIへのアクセス
|
||||
|
||||
Kubernetes APIに直接アクセスするためのさまざまな方法を学びます。
|
||||
|
||||
## TLSの使用
|
||||
|
||||
クラスタールート認証局(CA)を信頼して使用するようにアプリケーションを設定します。
|
||||
|
||||
## クラスターの管理
|
||||
|
||||
クラスターを管理するための一般的なタスクを学びます。
|
||||
|
||||
## フェデレーションの管理
|
||||
|
||||
クラスタフェデレーションのコンポーネントを設定します。
|
||||
|
||||
## ステートフルなアプリケーションの管理
|
||||
|
||||
StatefulSetのスケーリング、削除、デバッグなど、ステートフルなアプリケーションを管理するための一般的なタスクを実行します。
|
||||
|
||||
## クラスターデーモン
|
||||
|
||||
ローリングアップデートの実行など、DaemonSetを管理するための一般的なタスクを実行します。
|
||||
|
||||
## GPUの管理
|
||||
|
||||
クラスター内のノードがリソースとして使用するNVIDIA GPUを設定およびスケジュールします。
|
||||
|
||||
## Huge Pageの管理
|
||||
|
||||
クラスター内のスケジュール可能なリソースとしてHuge Pageを構成およびスケジュールします。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
タスクページを作成する場合は、[ドキュメントのPull Requestの作成](/docs/home/contribute/create-pull-request/)を参照してください。
|
||||
|
||||
{{% /capture %}}
|
||||
|
|
@ -0,0 +1,4 @@
|
|||
---
|
||||
title: "クラスター内アプリケーションへのアクセス"
|
||||
weight: 60
|
||||
---
|
||||
|
|
@ -0,0 +1,4 @@
|
|||
---
|
||||
title: "クラスターの管理"
|
||||
weight: 20
|
||||
---
|
||||
|
|
@ -0,0 +1,237 @@
|
|||
---
|
||||
title: コンテナおよびPodへのCPUリソースの割り当て
|
||||
content_template: templates/task
|
||||
weight: 20
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
このページでは、CPUの *request* と *limit* をコンテナに割り当てる方法について示します。コンテナは設定された制限を超えてCPUを使用することはできません。システムにCPUの空き時間がある場合、コンテナには要求されたCPUを割り当てられます。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
クラスターの各ノードには、少なくとも1つ以上のCPUが必要になります。
|
||||
|
||||
このページのいくつかの手順では、クラスターにて[metrics-server](https://github.com/kubernetes-incubator/metrics-server)サービスを実行する必要があります。すでにmetrics-serverが動作している場合、これらの手順をスキップできます。
|
||||
|
||||
{{< glossary_tooltip term_id="minikube" >}}を動作させている場合、以下のコマンドによりmetrics-serverを有効にできます:
|
||||
|
||||
```shell
|
||||
minikube addons enable metrics-server
|
||||
```
|
||||
|
||||
metrics-serverが実行されているか、もしくはリソースメトリクスAPI (`metrics.k8s.io`) の別のプロバイダーが実行されていることを確認するには、以下のコマンドを実行してください:
|
||||
|
||||
```shell
|
||||
kubectl get apiservices
|
||||
```
|
||||
|
||||
リソースメトリクスAPIが利用可能であれば、出力には `metrics.k8s.io` への参照が含まれます。
|
||||
|
||||
```
|
||||
NAME
|
||||
v1beta1.metrics.k8s.io
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## namespaceの作成
|
||||
|
||||
この練習で作成するリソースがクラスター内で分離されるよう、{{< glossary_tooltip term_id="namespace" >}}を作成します。
|
||||
|
||||
```shell
|
||||
kubectl create namespace cpu-example
|
||||
```
|
||||
|
||||
## CPUの要求と制限を指定する
|
||||
|
||||
コンテナにCPUの要求を指定するには、コンテナのリソースマニフェストに`resources:requests`フィールドを追記します。CPUの制限を指定するには、`resources:limits`を追記します。
|
||||
|
||||
この練習では、一つのコンテナをもつPodを作成します。コンテナに0.5 CPUの要求と1 CPUの制限を与えます。Podの設定ファイルは次のようになります:
|
||||
|
||||
{{< codenew file="pods/resource/cpu-request-limit.yaml" >}}
|
||||
|
||||
設定ファイルの`args`セクションでは、コンテナ起動時の引数を与えます。`-cpus "2"`という引数では、コンテナに2 CPUを割り当てます。
|
||||
|
||||
Podを作成してください:
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/pods/resource/cpu-request-limit.yaml --namespace=cpu-example
|
||||
```
|
||||
|
||||
Podのコンテナが起動していることを検証してください:
|
||||
|
||||
```shell
|
||||
kubectl get pod cpu-demo --namespace=cpu-example
|
||||
```
|
||||
|
||||
Podの詳細な情報を確認してください:
|
||||
|
||||
```shell
|
||||
kubectl get pod cpu-demo --output=yaml --namespace=cpu-example
|
||||
```
|
||||
|
||||
この出力では、Pod内の一つのコンテナに500ミリCPUの要求と1 CPUの制限があることを示しています。
|
||||
|
||||
```yaml
|
||||
resources:
|
||||
limits:
|
||||
cpu: "1"
|
||||
requests:
|
||||
cpu: 500m
|
||||
```
|
||||
|
||||
`kubectl top`を実行し、Podのメトリクスを取得してください:
|
||||
|
||||
```shell
|
||||
kubectl top pod cpu-demo --namespace=cpu-example
|
||||
```
|
||||
|
||||
この出力では、Podが974ミリCPUを使用していることを示しています。Podの設定で指定した1 CPUの制限よりわずかに小さい値です。
|
||||
|
||||
```
|
||||
NAME CPU(cores) MEMORY(bytes)
|
||||
cpu-demo 974m <something>
|
||||
```
|
||||
|
||||
`-cpu "2"`を設定することで、コンテナが2 CPU利用しようとすることを思い出してください。しかしながら、コンテナは約1 CPUしか使用することができません。コンテナが制限よりも多くのCPUリソースを利用しようとしているため、コンテナのCPUの利用が抑制されています。
|
||||
|
||||
{{< note >}}
|
||||
CPUの使用量が1.0未満である理由の可能性して、ノードに利用可能なCPUリソースが十分にないことが挙げられます。この練習における必要条件として、各ノードに少なくとも1 CPUが必要であることを思い出してください。1 CPUのノード上でコンテナを実行させる場合、指定したコンテナのCPU制限にかかわらず、コンテナは1 CPU以上使用することはできません。
|
||||
{{< /note >}}
|
||||
|
||||
## CPUの単位
|
||||
|
||||
CPUリソースは *CPU* の単位で示されます。Kubernetesにおいて1つのCPUは次に等しくなります:
|
||||
|
||||
* 1 AWS vCPU
|
||||
* 1 GCPコア
|
||||
* 1 Azure vCore
|
||||
* ハイパースレッディングが有効なベアメタルIntelプロセッサーの1スレッド
|
||||
|
||||
小数値も利用可能です。0.5 CPUを要求するコンテナには、1 CPUを要求するコンテナの半分のCPUが与えられます。mというミリを表す接尾辞も使用できます。たとえば、100m CPU、100 milliCPU、0.1 CPUはすべて同じです。1m以上の精度は指定できません。
|
||||
|
||||
CPUはつねに絶対量として要求され、決して相対量としては要求されません。0.1はシングルコア、デュアルコア、48コアCPUのマシンで同じ量となります。
|
||||
|
||||
Podを削除してください:
|
||||
|
||||
```shell
|
||||
kubectl delete pod cpu-demo --namespace=cpu-example
|
||||
```
|
||||
|
||||
## ノードよりも大きいCPU要求を指定する
|
||||
|
||||
CPU要求と制限はコンテナと関連づけられていますが、PodにCPU要求と制限が与えられていると考えるとわかりやすいでしょう。PodのCPU要求は、Pod内のすべてのコンテナのCPU要求の合計となります。同様に、PodのCPU制限は、Pod内のすべてのコンテナのCPU制限の合計となります。
|
||||
|
||||
Podのスケジューリングはリソースの要求量に基づいています。Podはノード上で動作するうえで、そのCPU要求に対してノードに十分利用可能なCPUリソースがある場合のみスケジュールされます。
|
||||
|
||||
この練習では、クラスター内のノードのキャパシティを超える大きさのCPU要求を与えたPodを作成します。以下に100 CPUの要求を与えた一つのコンテナを持つ、Podの設定ファイルを示します。これは、クラスター内のノードのキャパシティを超える可能性があります。
|
||||
|
||||
{{< codenew file="pods/resource/cpu-request-limit-2.yaml" >}}
|
||||
|
||||
Podを作成してください:
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/pods/resource/cpu-request-limit-2.yaml --namespace=cpu-example
|
||||
```
|
||||
|
||||
Podの状態を確認してください:
|
||||
|
||||
```shell
|
||||
kubectl get pod cpu-demo-2 --namespace=cpu-example
|
||||
```
|
||||
|
||||
この出力では、Podのステータスが待機中であることを示しています。つまり、Podがどのノードに対しても実行するようスケジュールされておらず、いつまでも待機状態のままであることを表しています:
|
||||
|
||||
```shell
|
||||
kubectl get pod cpu-demo-2 --namespace=cpu-example
|
||||
```
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
cpu-demo-2 0/1 Pending 0 7m
|
||||
```
|
||||
|
||||
イベントを含むPodの詳細な情報を確認してください:
|
||||
|
||||
|
||||
```shell
|
||||
kubectl describe pod cpu-demo-2 --namespace=cpu-example
|
||||
```
|
||||
|
||||
|
||||
この出力では、ノードのCPU不足のためコンテナがスケジュールされないことを示しています:
|
||||
|
||||
|
||||
```
|
||||
Events:
|
||||
Reason Message
|
||||
------ -------
|
||||
FailedScheduling No nodes are available that match all of the following predicates:: Insufficient cpu (3).
|
||||
```
|
||||
|
||||
Podを削除してください:
|
||||
|
||||
```shell
|
||||
kubectl delete pod cpu-demo-2 --namespace=cpu-example
|
||||
```
|
||||
|
||||
## CPU制限を指定しない場合
|
||||
|
||||
コンテナのCPU制限を指定しない場合、次のいずれかの状態となります:
|
||||
|
||||
* コンテナのCPUリソースの使用量に上限がない状態となります。コンテナは実行中のノードで利用可能なすべてのCPUを使用できます。
|
||||
|
||||
* CPU制限を与えられたnamespaceでコンテナを実行されると、コンテナにはデフォルトの制限値が自動的に指定されます。クラスターの管理者は[LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core)によってCPU制限のデフォルト値を指定できます。
|
||||
|
||||
## CPU要求と制限のモチベーション
|
||||
|
||||
クラスターで動作するコンテナにCPU要求と制限を設定することで、クラスターのノードで利用可能なCPUリソースを効率的に使用することができます。PodのCPU要求を低く保つことで、Podがスケジュールされやすくなります。CPU要求よりも大きい制限を与えることで、次の2つを実現できます:
|
||||
|
||||
* Podは利用可能なCPUリソースを、突発的な活動（バースト）に使用することができます。
|
||||
* バースト中のPodのCPUリソース量は、適切な量に制限されます。
|
||||
|
||||
|
||||
## クリーンアップ
|
||||
|
||||
namespaceを削除してください:
|
||||
|
||||
```shell
|
||||
kubectl delete namespace cpu-example
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
|
||||
### アプリケーション開発者向け
|
||||
|
||||
* [コンテナとPodにメモリーリソースを割り当てる](/docs/tasks/configure-pod-container/assign-memory-resource/)
|
||||
|
||||
* [PodのQuality of Serviceを設定する](/docs/tasks/configure-pod-container/quality-service-pod/)
|
||||
|
||||
### クラスター管理者向け
|
||||
|
||||
* [Namespaceにメモリー要求および制限のデフォルト値を設定する](/docs/tasks/administer-cluster/memory-default-namespace/)
|
||||
|
||||
* [NamespaceにCPU要求および制限のデフォルト値を設定する](/docs/tasks/administer-cluster/cpu-default-namespace/)
|
||||
|
||||
* [Namespaceに最小および最大メモリー量の制約を設定する](/docs/tasks/administer-cluster/memory-constraint-namespace/)
|
||||
|
||||
* [Namespaceに最小および最大のCPU使用量の制約を設定する](/docs/tasks/administer-cluster/cpu-constraint-namespace/)
|
||||
|
||||
* [NamespaceにメモリーおよびCPUのクォータを設定する](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)
|
||||
|
||||
* [NamespaceにPodのクォータを設定する](/docs/tasks/administer-cluster/quota-pod-namespace/)
|
||||
|
||||
* [APIオブジェクトのクォータを設定する](/docs/tasks/administer-cluster/quota-api-object/)
|
||||
|
||||
{{% /capture %}}
|
||||
|
|
@ -0,0 +1,256 @@
|
|||
---
|
||||
title: PodにQuality of Serviceを設定する
|
||||
content_template: templates/task
|
||||
weight: 30
|
||||
---
|
||||
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
このページでは、特定のQuality of Service (QoS)クラスをPodに割り当てるための設定方法を示します。Kubernetesは、Podのスケジューリングおよび退役を決定するためにQoSクラスを用います。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## QoSクラス
|
||||
|
||||
KubernetesはPodの作成時に次のいずれかのQoSクラスをPodに割り当てます:
|
||||
|
||||
* Guaranteed
|
||||
* Burstable
|
||||
* BestEffort
|
||||
|
||||
## namespaceの作成
|
||||
|
||||
この演習で作成するリソースがクラスター内で分離されるよう、namespaceを作成します。
|
||||
|
||||
|
||||
```shell
|
||||
kubectl create namespace qos-example
|
||||
```
|
||||
|
||||
## GuaranteedのQoSクラスを割り当てたPodを作成する
|
||||
|
||||
PodにGuaranteedのQoSクラスを与えるには、以下が必要になります:
|
||||
|
||||
* Pod内のすべてのコンテナにメモリーの制限と要求が与えられており、同じ値であること。
|
||||
* Pod内のすべてのコンテナにCPUの制限と要求が与えられており、同じ値であること。
|
||||
|
||||
以下に1つのコンテナをもつPodの設定ファイルを示します。コンテナには200MiBのメモリー制限とリクエストを与え、700ミリCPUの制限と要求を与えます。
|
||||
|
||||
{{< codenew file="pods/qos/qos-pod.yaml" >}}
|
||||
|
||||
Podを作成してください:
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/pods/qos/qos-pod.yaml --namespace=qos-example
|
||||
```
|
||||
|
||||
Podの詳細な情報を確認してください:
|
||||
|
||||
```shell
|
||||
kubectl get pod qos-demo --namespace=qos-example --output=yaml
|
||||
```
|
||||
|
||||
この出力では、KubernetesがPodにGuaranteed QoSクラスを与えたことを示しています。Podのコンテナにメモリー制限と一致するメモリー要求があり、CPU制限と一致するCPU要求があることも確認できます。
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
containers:
|
||||
...
|
||||
resources:
|
||||
limits:
|
||||
cpu: 700m
|
||||
memory: 200Mi
|
||||
requests:
|
||||
cpu: 700m
|
||||
memory: 200Mi
|
||||
...
|
||||
qosClass: Guaranteed
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
コンテナにメモリー制限を指定し、メモリー要求を指定していない場合は、Kubernetesは自動的にメモリー制限と一致するメモリー要求を割り当てます。同様に、コンテナにCPU制限を指定し、CPU要求を指定していない場合は、Kubernetesは自動的にCPU制限と一致するCPU要求を割り当てます。
|
||||
{{< /note >}}
|
||||
|
||||
Podを削除してください:
|
||||
|
||||
```shell
|
||||
kubectl delete pod qos-demo --namespace=qos-example
|
||||
```
|
||||
|
||||
## BurstableのQoSクラスを割り当てたPodを作成する
|
||||
|
||||
次のような場合に、Burstable QoSクラスがPodに与えられます:
|
||||
|
||||
* PodがGuaranteed QoSクラスの基準に満たない場合。
|
||||
* Pod内の1つ以上のコンテナがメモリーまたはCPUの要求を与えられている場合。
|
||||
|
||||
以下に1つのコンテナをもつPodの設定ファイルを示します。コンテナには200MiBのメモリー制限と100MiBのメモリー要求を与えます。
|
||||
|
||||
{{< codenew file="pods/qos/qos-pod-2.yaml" >}}
|
||||
|
||||
Podを作成してください:
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/pods/qos/qos-pod-2.yaml --namespace=qos-example
|
||||
```
|
||||
|
||||
Podの詳細な情報を確認してください:
|
||||
|
||||
```shell
|
||||
kubectl get pod qos-demo-2 --namespace=qos-example --output=yaml
|
||||
```
|
||||
|
||||
この出力では、KubernetesがPodにBurstable QoSクラスを与えたことを示しています。
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
containers:
|
||||
- image: nginx
|
||||
imagePullPolicy: Always
|
||||
name: qos-demo-2-ctr
|
||||
resources:
|
||||
limits:
|
||||
memory: 200Mi
|
||||
requests:
|
||||
memory: 100Mi
|
||||
...
|
||||
qosClass: Burstable
|
||||
```
|
||||
|
||||
Podを削除してください:
|
||||
|
||||
```shell
|
||||
kubectl delete pod qos-demo-2 --namespace=qos-example
|
||||
```
|
||||
|
||||
## BestEffortのQoSクラスを割り当てたPodを作成する
|
||||
|
||||
PodにBestEffort QoSクラスを与えるには、Pod内のコンテナにはメモリーやCPUの制限や要求を指定してはなりません。
|
||||
|
||||
以下に1つのコンテナをもつPodの設定ファイルを示します。コンテナにはメモリーやCPUの制限や要求がありません:
|
||||
|
||||
{{< codenew file="pods/qos/qos-pod-3.yaml" >}}
|
||||
|
||||
Podを作成してください:
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/pods/qos/qos-pod-3.yaml --namespace=qos-example
|
||||
```
|
||||
|
||||
Podの詳細な情報を確認してください:
|
||||
|
||||
```shell
|
||||
kubectl get pod qos-demo-3 --namespace=qos-example --output=yaml
|
||||
```
|
||||
|
||||
この出力では、KubernetesがPodにBestEffort QoSクラスを与えたことを示しています。
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
containers:
|
||||
...
|
||||
resources: {}
|
||||
...
|
||||
qosClass: BestEffort
|
||||
```
|
||||
|
||||
Podを削除してください:
|
||||
|
||||
```shell
|
||||
kubectl delete pod qos-demo-3 --namespace=qos-example
|
||||
```
|
||||
|
||||
## 2つのコンテナを含むPodを作成する
|
||||
|
||||
以下に2つのコンテナをもつPodの設定ファイルを示します。一方のコンテナは200MiBのメモリー要求を指定し、もう一方のコンテナには要求や制限を指定しません。
|
||||
|
||||
{{< codenew file="pods/qos/qos-pod-4.yaml" >}}
|
||||
|
||||
このPodがBurstable QoSクラスの基準を満たしていることに注目してください。つまり、Guaranteed QoSクラスの基準に満たしておらず、一方のコンテナにはメモリー要求を与えられています。
|
||||
|
||||
Podを作成してください:
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/pods/qos/qos-pod-4.yaml --namespace=qos-example
|
||||
```
|
||||
|
||||
Podの詳細な情報を確認してください:
|
||||
|
||||
```shell
|
||||
kubectl get pod qos-demo-4 --namespace=qos-example --output=yaml
|
||||
```
|
||||
|
||||
この出力では、KubernetesがPodにBurstable QoSクラスを与えたことを示しています:
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
containers:
|
||||
...
|
||||
name: qos-demo-4-ctr-1
|
||||
resources:
|
||||
requests:
|
||||
memory: 200Mi
|
||||
...
|
||||
name: qos-demo-4-ctr-2
|
||||
resources: {}
|
||||
...
|
||||
qosClass: Burstable
|
||||
```
|
||||
|
||||
Podを削除してください:
|
||||
|
||||
```shell
|
||||
kubectl delete pod qos-demo-4 --namespace=qos-example
|
||||
```
|
||||
|
||||
## クリーンアップ
|
||||
|
||||
namespaceを削除してください:
|
||||
|
||||
```shell
|
||||
kubectl delete namespace qos-example
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
|
||||
### アプリケーション開発者向け
|
||||
|
||||
* [コンテナとPodにメモリーリソースを割り当てる](/docs/tasks/configure-pod-container/assign-memory-resource/)
|
||||
|
||||
* [コンテナとPodにCPUリソースを割り当てる](/docs/tasks/configure-pod-container/assign-cpu-resource/)
|
||||
|
||||
### クラスター管理者向け
|
||||
|
||||
* [Namespaceにメモリー要求および制限のデフォルト値を設定する](/docs/tasks/administer-cluster/memory-default-namespace/)
|
||||
|
||||
* [NamespaceにCPU要求および制限のデフォルト値を設定する](/docs/tasks/administer-cluster/cpu-default-namespace/)
|
||||
|
||||
* [Namespaceに最小および最大メモリー量の制約を設定する](/docs/tasks/administer-cluster/memory-constraint-namespace/)
|
||||
|
||||
* [Namespaceに最小および最大のCPU使用量の制約を設定する](/docs/tasks/administer-cluster/cpu-constraint-namespace/)
|
||||
|
||||
* [NamespaceにメモリーおよびCPUのクォータを設定する](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)
|
||||
|
||||
* [NamespaceにPodのクォータを設定する](/docs/tasks/administer-cluster/quota-pod-namespace/)
|
||||
|
||||
* [APIオブジェクトのクォータを設定する](/docs/tasks/administer-cluster/quota-api-object/)
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,4 @@
|
|||
---
|
||||
title: "監視、ログ、デバッグ"
|
||||
weight: 80
|
||||
---
|
||||
|
|
@ -0,0 +1,597 @@
|
|||
---
|
||||
content_template: templates/concept
|
||||
title: Serviceのデバッグ
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
新規にKubernetesをインストールした環境でかなり頻繁に発生する問題は、`Service`が適切に機能しないというものです。
|
||||
`Deployment`を実行して`Service`を作成したにもかかわらず、アクセスしようとしても応答がありません。
|
||||
何が問題になっているのかを理解するのに、このドキュメントがきっと役立つでしょう。
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## 規則
|
||||
|
||||
このドキュメントでは全体を通して、実行可能なさまざまなコマンドが示されます。
|
||||
中には`Pod`内で実行する必要があるコマンドもあれば、Kubernetesの`ノード`上で実行する必要があるコマンドや、`kubectl`とクラスターの認証情報がある場所であればどこでも実行できるコマンドもあります。
|
||||
期待される内容を明確にするために、このドキュメントでは次の規則を使用します。
|
||||
|
||||
コマンド"COMMAND"が`Pod`内で実行され、"OUTPUT"を出力すると期待される場合:
|
||||
|
||||
```shell
|
||||
u@pod$ COMMAND
|
||||
OUTPUT
|
||||
```
|
||||
|
||||
コマンド"COMMAND"が`Node`上で実行され、"OUTPUT"を出力すると期待される場合:
|
||||
|
||||
```shell
|
||||
u@node$ COMMAND
|
||||
OUTPUT
|
||||
```
|
||||
|
||||
コマンドが"kubectl ARGS"の場合:
|
||||
|
||||
```shell
|
||||
kubectl ARGS
|
||||
OUTPUT
|
||||
```
|
||||
|
||||
## Pod内でコマンドを実行する
|
||||
|
||||
ここでの多くのステップでは、クラスターで実行されている`Pod`が見ているものを確認する必要があります。
|
||||
これを行う最も簡単な方法は、インタラクティブなalpineの`Pod`を実行することです。
|
||||
|
||||
```none
|
||||
kubectl run -it --rm --restart=Never alpine --image=alpine sh
|
||||
/ #
|
||||
```
|
||||
{{< note >}}
|
||||
コマンドプロンプトが表示されない場合は、Enterキーを押してみてください。
|
||||
{{< /note >}}
|
||||
|
||||
使用したい実行中の`Pod`が既にある場合は、以下のようにしてその`Pod`内でコマンドを実行できます。
|
||||
|
||||
```shell
|
||||
kubectl exec <POD-NAME> -c <CONTAINER-NAME> -- <COMMAND>
|
||||
```
|
||||
|
||||
## セットアップ
|
||||
|
||||
このドキュメントのウォークスルーのために、いくつかの`Pod`を実行しましょう。
|
||||
おそらくあなた自身の`Service`をデバッグしているため、あなた自身の詳細に置き換えることもできますし、これに沿って2番目のデータポイントを取得することもできます。
|
||||
|
||||
```shell
|
||||
kubectl run hostnames --image=k8s.gcr.io/serve_hostname \
|
||||
--labels=app=hostnames \
|
||||
--port=9376 \
|
||||
--replicas=3
|
||||
deployment.apps/hostnames created
|
||||
```
|
||||
|
||||
`kubectl`コマンドは作成、変更されたリソースのタイプと名前を出力するため、この後のコマンドで使用することもできます。
|
||||
{{< note >}}
|
||||
これは、次のYAMLで`Deployment`を開始した場合と同じです。
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: hostnames
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: hostnames
|
||||
replicas: 3
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: hostnames
|
||||
spec:
|
||||
containers:
|
||||
- name: hostnames
|
||||
image: k8s.gcr.io/serve_hostname
|
||||
ports:
|
||||
- containerPort: 9376
|
||||
protocol: TCP
|
||||
```
|
||||
{{< /note >}}
|
||||
|
||||
`Pod`が実行中であることを確認してください。
|
||||
|
||||
```shell
|
||||
kubectl get pods -l app=hostnames
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
hostnames-632524106-bbpiw 1/1 Running 0 2m
|
||||
hostnames-632524106-ly40y 1/1 Running 0 2m
|
||||
hostnames-632524106-tlaok 1/1 Running 0 2m
|
||||
```
|
||||
|
||||
## Serviceは存在するか？
|
||||
|
||||
賢明な読者は、`Service`をまだ実際に作成していないことにお気付きかと思いますが、これは意図的です。これは時々忘れられるステップであり、最初に確認すべきことです。
|
||||
|
||||
では、存在しない`Service`にアクセスしようとするとどうなるでしょうか？
|
||||
この`Service`を名前で利用する別の`Pod`があると仮定すると、次のような結果が得られます。
|
||||
|
||||
```shell
|
||||
u@pod$ wget -O- hostnames
|
||||
Resolving hostnames (hostnames)... failed: Name or service not known.
|
||||
wget: unable to resolve host address 'hostnames'
|
||||
```
|
||||
|
||||
そのため、最初に確認するのは、その`Service`が実際に存在するかどうかです。
|
||||
|
||||
```shell
|
||||
kubectl get svc hostnames
|
||||
No resources found.
|
||||
Error from server (NotFound): services "hostnames" not found
|
||||
```
|
||||
|
||||
犯人がいましたので、`Service`を作成しましょう。
|
||||
前と同様に、これはウォークスルー用です。ご自身の`Service`の詳細を使用することもできます。
|
||||
|
||||
```shell
|
||||
kubectl expose deployment hostnames --port=80 --target-port=9376
|
||||
service/hostnames exposed
|
||||
```
|
||||
|
||||
そして、念のため内容を確認します。
|
||||
|
||||
```shell
|
||||
kubectl get svc hostnames
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
hostnames ClusterIP 10.0.1.175 <none> 80/TCP 5s
|
||||
```
|
||||
|
||||
前と同様に、これは次のようなYAMLで`Service`を開始した場合と同じです。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: hostnames
|
||||
spec:
|
||||
selector:
|
||||
app: hostnames
|
||||
ports:
|
||||
- name: default
|
||||
protocol: TCP
|
||||
port: 80
|
||||
targetPort: 9376
|
||||
```
|
||||
|
||||
これで、`Service`が存在することが確認できました。
|
||||
|
||||
## サービスはDNSによって機能しているか？
|
||||
|
||||
同じ`Namespace`の`Pod`から次のコマンドを実行してください。
|
||||
|
||||
```shell
|
||||
u@pod$ nslookup hostnames
|
||||
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
|
||||
|
||||
Name: hostnames
|
||||
Address 1: 10.0.1.175 hostnames.default.svc.cluster.local
|
||||
```
|
||||
|
||||
これが失敗した場合、おそらく`Pod`と`Service`が異なる`Namespace`にあるため、ネームスペースで修飾された名前を試してください。
|
||||
|
||||
```shell
|
||||
u@pod$ nslookup hostnames.default
|
||||
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
|
||||
|
||||
Name: hostnames.default
|
||||
Address 1: 10.0.1.175 hostnames.default.svc.cluster.local
|
||||
```
|
||||
|
||||
これが機能する場合、クロスネームスペース名を使用するようにアプリケーションを調整するか、同じ`Namespace`でアプリと`Service`を実行する必要があります。
|
||||
これでも失敗する場合は、完全修飾名を試してください。
|
||||
|
||||
```shell
|
||||
u@pod$ nslookup hostnames.default.svc.cluster.local
|
||||
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
|
||||
|
||||
Name: hostnames.default.svc.cluster.local
|
||||
Address 1: 10.0.1.175 hostnames.default.svc.cluster.local
|
||||
```
|
||||
|
||||
ここでのサフィックス"default.svc.cluster.local"に注意してください。
|
||||
"default"は、操作している`Namespace`です。
|
||||
"svc"は、これが`Service`であることを示します。
|
||||
"cluster.local"はクラスタードメインであり、あなたのクラスターでは異なる場合があります。
|
||||
|
||||
クラスター内の`ノード`からも試すこともできます。
|
||||
|
||||
{{< note >}}
|
||||
10.0.0.10は私のDNS `Service`であり、あなたのクラスターでは異なるかもしれません。
|
||||
{{< /note >}}
|
||||
|
||||
```shell
|
||||
u@node$ nslookup hostnames.default.svc.cluster.local 10.0.0.10
|
||||
Server: 10.0.0.10
|
||||
Address: 10.0.0.10#53
|
||||
|
||||
Name: hostnames.default.svc.cluster.local
|
||||
Address: 10.0.1.175
|
||||
```
|
||||
|
||||
完全修飾名では検索できるのに、相対名ではできない場合、`/etc/resolv.conf`ファイルが正しいことを確認する必要があります。
|
||||
|
||||
```shell
|
||||
u@pod$ cat /etc/resolv.conf
|
||||
nameserver 10.0.0.10
|
||||
search default.svc.cluster.local svc.cluster.local cluster.local example.com
|
||||
options ndots:5
|
||||
```
|
||||
|
||||
`nameserver`行はクラスターのDNS `Service`を示さなければなりません。
|
||||
これは、`--cluster-dns`フラグで`kubelet`に渡されます。
|
||||
|
||||
`search`行には、`Service`名を見つけるための適切なサフィックスを含める必要があります。
|
||||
この場合、ローカルの`Namespace`で`Service`を見つけるためのサフィックス(`default.svc.cluster.local`)、すべての`Namespaces`で`Service`を見つけるためのサフィックス(`svc.cluster.local`)、およびクラスターのサフィックス(`cluster.local`)です。
|
||||
インストール方法によっては、その後に追加のレコードがある場合があります(合計6つまで)。
|
||||
クラスターのサフィックスは、`--cluster-domain`フラグを使用して`kubelet`に渡されます。
|
||||
このドキュメントではそれが"cluster.local"であると仮定していますが、あなたのクラスターでは異なる場合があります。
|
||||
その場合は、上記のすべてのコマンドでクラスターのサフィックスを変更する必要があります。
|
||||
|
||||
`options`行では、DNSクライアントライブラリーが検索パスをまったく考慮しないように`ndots`を十分に高く設定する必要があります。
|
||||
Kubernetesはデフォルトでこれを5に設定します。これは、生成されるすべてのDNS名をカバーするのに十分な大きさです。
|
||||
|
||||
### ServiveはDNSに存在するか？
|
||||
|
||||
上記がまだ失敗する場合、DNSルックアップが`Service`に対して機能していません。
|
||||
一歩離れて、他の何が機能していないかを確認しましょう。
|
||||
Kubernetesマスターの`Service`は常に機能するはずです。
|
||||
|
||||
```shell
|
||||
u@pod$ nslookup kubernetes.default
|
||||
Server: 10.0.0.10
|
||||
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
|
||||
|
||||
Name: kubernetes.default
|
||||
Address 1: 10.0.0.1 kubernetes.default.svc.cluster.local
|
||||
```
|
||||
|
||||
これが失敗した場合、このドキュメントのkube-proxyセクションに移動するか、あるいは、このドキュメントの先頭に戻って最初からやり直し、あなた自身の`Service`をデバッグする代わりにDNSをデバッグする必要があるかもしれません。
|
||||
|
||||
## ServiceはIPでは機能するか？
|
||||
|
||||
DNSが機能することを確認できると仮定すると、次にテストするのは`Service`が機能しているかどうかです。
|
||||
上述の`kubectl get`で確認できる`Service`のIPに、クラスター内のノードからアクセスします。
|
||||
|
||||
```shell
|
||||
u@node$ curl 10.0.1.175:80
|
||||
hostnames-0uton
|
||||
|
||||
u@node$ curl 10.0.1.175:80
|
||||
hostnames-yp2kp
|
||||
|
||||
u@node$ curl 10.0.1.175:80
|
||||
hostnames-bvc05
|
||||
```
|
||||
|
||||
`Service`が機能している場合は、正しい応答が得られるはずです。
|
||||
そうでない場合、おかしい可能性のあるものがいくつかあるため、続けましょう。
|
||||
|
||||
## Serviceは正しいか？
|
||||
|
||||
馬鹿げているように聞こえるかもしれませんが、`Service`が正しく定義され`Pod`のポートとマッチすることを二度、三度と確認すべきです。
|
||||
`Service`を読み返して確認しましょう。
|
||||
|
||||
```shell
|
||||
kubectl get service hostnames -o json
|
||||
```
|
||||
```json
|
||||
{
|
||||
"kind": "Service",
|
||||
"apiVersion": "v1",
|
||||
"metadata": {
|
||||
"name": "hostnames",
|
||||
"namespace": "default",
|
||||
"uid": "428c8b6c-24bc-11e5-936d-42010af0a9bc",
|
||||
"resourceVersion": "347189",
|
||||
"creationTimestamp": "2015-07-07T15:24:29Z",
|
||||
"labels": {
|
||||
"app": "hostnames"
|
||||
}
|
||||
},
|
||||
"spec": {
|
||||
"ports": [
|
||||
{
|
||||
"name": "default",
|
||||
"protocol": "TCP",
|
||||
"port": 80,
|
||||
"targetPort": 9376,
|
||||
"nodePort": 0
|
||||
}
|
||||
],
|
||||
"selector": {
|
||||
"app": "hostnames"
|
||||
},
|
||||
"clusterIP": "10.0.1.175",
|
||||
"type": "ClusterIP",
|
||||
"sessionAffinity": "None"
|
||||
},
|
||||
"status": {
|
||||
"loadBalancer": {}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
* アクセスしようとしているポートは`spec.ports[]`に定義されていますか？
|
||||
* `targetPort`は`Pod`に対して適切ですか(多くの`Pod`は`Service`とは異なるポートを使用することを選択します)？
|
||||
* `targetPort`を数値で定義しようとしている場合、それは数値(9376)、文字列"9376"のどちらですか？
|
||||
* `targetPort`を名前で定義しようとしている場合、`Pod`は同じ名前でポートを公開していますか？
|
||||
* ポートの`protocol`は`Pod`のものと同じですか？
|
||||
|
||||
## ServiceにEndpointがあるか？
|
||||
|
||||
ここまで来たということは、`Service`は存在し、DNSによって名前解決できることが確認できているでしょう。
|
||||
ここでは、実行した`Pod`が`Service`によって実際に選択されていることを確認しましょう。
|
||||
|
||||
以前に、`Pod`が実行されていることを確認しました。再確認しましょう。
|
||||
|
||||
```shell
|
||||
kubectl get pods -l app=hostnames
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
hostnames-0uton 1/1 Running 0 1h
|
||||
hostnames-bvc05 1/1 Running 0 1h
|
||||
hostnames-yp2kp 1/1 Running 0 1h
|
||||
```
|
||||
|
||||
"AGE"列は、これらの`Pod`が約1時間前のものであることを示しており、それらが正常に実行され、クラッシュしていないことを意味します。
|
||||
|
||||
`-l app=hostnames`引数はラベルセレクターで、ちょうど私たちの`Service`に定義されているものと同じです。
|
||||
Kubernetesシステム内には、すべての`Service`のセレクターを評価し、結果を`Endpoint`オブジェクトに保存するコントロールループがあります。
|
||||
|
||||
```shell
|
||||
kubectl get endpoints hostnames
|
||||
NAME ENDPOINTS
|
||||
hostnames 10.244.0.5:9376,10.244.0.6:9376,10.244.0.7:9376
|
||||
```
|
||||
|
||||
これにより、Endpointコントローラーが`Service`の正しい`Pod`を見つけていることを確認できます。
|
||||
`hostnames`行が空白の場合、`Service`の`spec.selector`フィールドが実際に`Pod`の`metadata.labels`値を選択していることを確認する必要があります。
|
||||
よくある間違いは、タイプミスまたは他のエラー、たとえば`Service`が`run=hostnames`を選択しているのに`Deployment`が`app=hostnames`を指定していることです。
|
||||
|
||||
## Podは機能しているか？
|
||||
|
||||
この時点で、`Service`が存在し、`Pod`を選択していることがわかります。
|
||||
`Pod`が実際に機能していることを確認しましょう。`Service`メカニズムをバイパスして、`Pod`に直接アクセスすることができます。
|
||||
|
||||
{{< note >}}
|
||||
これらのコマンドは、`Service`ポート(80)ではなく、`Pod`ポート(9376)を使用します。
|
||||
{{< /note >}}
|
||||
|
||||
```shell
|
||||
u@pod$ wget -qO- 10.244.0.5:9376
|
||||
hostnames-0uton
|
||||
|
||||
pod $ wget -qO- 10.244.0.6:9376
|
||||
hostnames-bvc05
|
||||
|
||||
u@pod$ wget -qO- 10.244.0.7:9376
|
||||
hostnames-yp2kp
|
||||
```
|
||||
|
||||
`Endpoint`リスト内の各`Pod`は、それぞれの自身のホスト名を返すはずです。
|
||||
そうならない(または、あなた自身の`Pod`の正しい振る舞いにならない)場合は、そこで何が起こっているのかを調査する必要があります。
|
||||
`kubectl logs`が役立つかもしれません。あるいは、`kubectl exec`で直接`Pod`にアクセスし、そこでサービスをチェックしましょう。
|
||||
|
||||
もう1つ確認すべきことは、`Pod`がクラッシュしたり、再起動されていないことです。
|
||||
頻繁に再起動されていると、断続的な接続の問題が発生する可能性があります。
|
||||
|
||||
```shell
|
||||
kubectl get pods -l app=hostnames
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
hostnames-632524106-bbpiw 1/1 Running 0 2m
|
||||
hostnames-632524106-ly40y 1/1 Running 0 2m
|
||||
hostnames-632524106-tlaok 1/1 Running 0 2m
|
||||
```
|
||||
|
||||
再起動回数が多い場合は、[Podをデバッグする](/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller/#podのデバッグ)方法の詳細をご覧ください。
|
||||
|
||||
## kube-proxyは機能しているか？
|
||||
|
||||
ここに到達したのなら、`Service`は実行され、`Endpoint`があり、`Pod`が実際にサービスを提供しています。
|
||||
この時点で、`Service`のプロキシーメカニズム全体が疑わしいです。
|
||||
ひとつひとつ確認しましょう。
|
||||
|
||||
### kube-proxyは実行されているか？
|
||||
|
||||
`kube-proxy`が`ノード`上で実行されていることを確認しましょう。
|
||||
以下のような結果が得られるはずです。
|
||||
|
||||
```shell
|
||||
u@node$ ps auxw | grep kube-proxy
|
||||
root 4194 0.4 0.1 101864 17696 ? Sl Jul04 25:43 /usr/local/bin/kube-proxy --master=https://kubernetes-master --kubeconfig=/var/lib/kube-proxy/kubeconfig --v=2
|
||||
```
|
||||
|
||||
次に、マスターとの接続など、明らかな失敗をしていないことを確認します。
|
||||
これを行うには、ログを確認する必要があります。
|
||||
ログへのアクセス方法は、`ノード`のOSに依存します。
|
||||
一部のOSでは/var/log/kube-proxy.logのようなファイルですが、他のOSでは`journalctl`を使用してログにアクセスします。
|
||||
次のように表示されます。
|
||||
|
||||
```none
|
||||
I1027 22:14:53.995134 5063 server.go:200] Running in resource-only container "/kube-proxy"
|
||||
I1027 22:14:53.998163 5063 server.go:247] Using iptables Proxier.
|
||||
I1027 22:14:53.999055 5063 server.go:255] Tearing down userspace rules. Errors here are acceptable.
|
||||
I1027 22:14:54.038140 5063 proxier.go:352] Setting endpoints for "kube-system/kube-dns:dns-tcp" to [10.244.1.3:53]
|
||||
I1027 22:14:54.038164 5063 proxier.go:352] Setting endpoints for "kube-system/kube-dns:dns" to [10.244.1.3:53]
|
||||
I1027 22:14:54.038209 5063 proxier.go:352] Setting endpoints for "default/kubernetes:https" to [10.240.0.2:443]
|
||||
I1027 22:14:54.038238 5063 proxier.go:429] Not syncing iptables until Services and Endpoints have been received from master
|
||||
I1027 22:14:54.040048 5063 proxier.go:294] Adding new service "default/kubernetes:https" at 10.0.0.1:443/TCP
|
||||
I1027 22:14:54.040154 5063 proxier.go:294] Adding new service "kube-system/kube-dns:dns" at 10.0.0.10:53/UDP
|
||||
I1027 22:14:54.040223 5063 proxier.go:294] Adding new service "kube-system/kube-dns:dns-tcp" at 10.0.0.10:53/TCP
|
||||
```
|
||||
|
||||
マスターに接続できないことに関するエラーメッセージが表示された場合、`ノード`の設定とインストール手順をダブルチェックする必要があります。
|
||||
|
||||
`kube-proxy`が正しく実行できない理由の可能性の1つは、必須の`conntrack`バイナリが見つからないことです。
|
||||
これは、例えばKubernetesをスクラッチからインストールするなど、クラスターのインストール方法に依存して、一部のLinuxシステムで発生する場合があります。
|
||||
これが該当する場合は、`conntrack`パッケージを手動でインストール(例: Ubuntuでは`sudo apt install conntrack`)する必要があり、その後に再試行する必要があります。
|
||||
|
||||
### kube-proxyはiptablesルールを書いているか？
|
||||
|
||||
`kube-proxy`の主な責務の1つは、`Service`を実装する`iptables`ルールを記述することです。
|
||||
それらのルールが書かれていることを確認しましょう。
|
||||
|
||||
kube-proxyは、"userspace"モード、"iptables"モード、または"ipvs"モードで実行できます。
|
||||
あなたが"iptables"モードまたは"ipvs"モードを使用していることを願います。
|
||||
続くケースのいずれかが表示されるはずです。
|
||||
|
||||
#### Userspace
|
||||
|
||||
```shell
|
||||
u@node$ iptables-save | grep hostnames
|
||||
-A KUBE-PORTALS-CONTAINER -d 10.0.1.175/32 -p tcp -m comment --comment "default/hostnames:default" -m tcp --dport 80 -j REDIRECT --to-ports 48577
|
||||
-A KUBE-PORTALS-HOST -d 10.0.1.175/32 -p tcp -m comment --comment "default/hostnames:default" -m tcp --dport 80 -j DNAT --to-destination 10.240.115.247:48577
|
||||
```
|
||||
|
||||
`Service`の各ポート毎(この例では1つ)に2つのルールがあるはずです。
|
||||
"KUBE-PORTALS-CONTAINER"と"KUBE-PORTALS-HOST"です。
|
||||
これらが表示されない場合は、`-v`フラグを4に設定して`kube-proxy`を再起動してから、もう一度ログを確認してください。
|
||||
|
||||
"userspace"モードを使用する必要がある人ほとんどないため、ここではこれ以上の時間を費やしません。
|
||||
|
||||
#### Iptables
|
||||
|
||||
```shell
|
||||
u@node$ iptables-save | grep hostnames
|
||||
-A KUBE-SEP-57KPRZ3JQVENLNBR -s 10.244.3.6/32 -m comment --comment "default/hostnames:" -j MARK --set-xmark 0x00004000/0x00004000
|
||||
-A KUBE-SEP-57KPRZ3JQVENLNBR -p tcp -m comment --comment "default/hostnames:" -m tcp -j DNAT --to-destination 10.244.3.6:9376
|
||||
-A KUBE-SEP-WNBA2IHDGP2BOBGZ -s 10.244.1.7/32 -m comment --comment "default/hostnames:" -j MARK --set-xmark 0x00004000/0x00004000
|
||||
-A KUBE-SEP-WNBA2IHDGP2BOBGZ -p tcp -m comment --comment "default/hostnames:" -m tcp -j DNAT --to-destination 10.244.1.7:9376
|
||||
-A KUBE-SEP-X3P2623AGDH6CDF3 -s 10.244.2.3/32 -m comment --comment "default/hostnames:" -j MARK --set-xmark 0x00004000/0x00004000
|
||||
-A KUBE-SEP-X3P2623AGDH6CDF3 -p tcp -m comment --comment "default/hostnames:" -m tcp -j DNAT --to-destination 10.244.2.3:9376
|
||||
-A KUBE-SERVICES -d 10.0.1.175/32 -p tcp -m comment --comment "default/hostnames: cluster IP" -m tcp --dport 80 -j KUBE-SVC-NWV5X2332I4OT4T3
|
||||
-A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-WNBA2IHDGP2BOBGZ
|
||||
-A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-X3P2623AGDH6CDF3
|
||||
-A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -j KUBE-SEP-57KPRZ3JQVENLNBR
|
||||
```
|
||||
|
||||
`KUBE-SERVICES`に1つのルールがあり、`KUBE-SVC-(hash)`のエンドポイント毎に1つまたは2つのルールがあり(`SessionAffinity`に依存)、エンドポイント毎に1つの`KUBE-SEP-(hash)`チェーンがあり、 そしてそれぞれの`KUBE-SEP-(hash)`チェーンにはいくつかのルールがあるはずです。
|
||||
正確なルールは、あなたの正確な構成(NodePortとLoadBalancerを含む)によって異なります。
|
||||
|
||||
#### IPVS
|
||||
|
||||
```shell
|
||||
u@node$ ipvsadm -ln
|
||||
Prot LocalAddress:Port Scheduler Flags
|
||||
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
|
||||
...
|
||||
TCP 10.0.1.175:80 rr
|
||||
-> 10.244.0.5:9376 Masq 1 0 0
|
||||
-> 10.244.0.6:9376 Masq 1 0 0
|
||||
-> 10.244.0.7:9376 Masq 1 0 0
|
||||
...
|
||||
```
|
||||
|
||||
IPVSプロキシーは、各Serviceアドレス(Cluster IP、External IP、NodePort IP、Load Balancer IPなど)毎の仮想サーバーと、Serviceのエンドポイントが存在する場合に対応する実サーバーを作成します。
|
||||
この例では、hostnames Service(`10.0.1.175:80`)は3つのエンドポイント(`10.244.0.5:9376`、`10.244.0.6:9376`、`10.244.0.7:9376`)を持ち、上と似た結果が得られるはずです。
|
||||
|
||||
### kube-proxyはプロキシしているか？
|
||||
|
||||
上記のルールが表示されていると仮定すると、もう一度IPを使用して`Service`へのアクセスを試してください。
|
||||
|
||||
```shell
|
||||
u@node$ curl 10.0.1.175:80
|
||||
hostnames-0uton
|
||||
```
|
||||
|
||||
もしこれが失敗し、あなたがuserspaceプロキシーを使用している場合、プロキシーへの直接アクセスを試してみてください。
|
||||
もしiptablesプロキシーを使用している場合、このセクションはスキップしてください。
|
||||
|
||||
上記の`iptables-save`の出力を振り返り、`kube-proxy`が`Service`に使用しているポート番号を抽出します。
|
||||
上記の例では"48577"です。このポートに接続してください。
|
||||
|
||||
```shell
|
||||
u@node$ curl localhost:48577
|
||||
hostnames-yp2kp
|
||||
```
|
||||
|
||||
もしまだ失敗する場合は、`kube-proxy`ログで次のような特定の行を探してください。
|
||||
|
||||
```shell
|
||||
Setting endpoints for default/hostnames:default to [10.244.0.5:9376 10.244.0.6:9376 10.244.0.7:9376]
|
||||
```
|
||||
|
||||
これらが表示されない場合は、`-v`フラグを4に設定して`kube-proxy`を再起動してから、再度ログを確認してください。
|
||||
|
||||
### PodはService IPを介して自分自身にアクセスできない
|
||||
|
||||
これはネットワークが"hairpin"トラフィック用に適切に設定されていない場合、通常は`kube-proxy`が`iptables`モードで実行され、Podがブリッジネットワークに接続されている場合に発生します。
|
||||
`Kubelet`は`hairpin-mode`[フラグ](/docs/admin/kubelet/)を公開します。
|
||||
これにより、Serviceのエンドポイントが自身のServiceのVIPにアクセスしようとした場合に、自身への負荷分散を可能にします。
|
||||
`hairpin-mode`フラグは`hairpin-veth`または`promiscuous-bridge`に設定する必要があります。
|
||||
|
||||
この問題をトラブルシューティングする一般的な手順は次のとおりです。
|
||||
|
||||
* `hairpin-mode`が`hairpin-veth`または`promiscuous-bridge`に設定されていることを確認します。
|
||||
次のような表示がされるはずです。この例では、`hairpin-mode`は`promiscuous-bridge`に設定されています。
|
||||
|
||||
```shell
|
||||
u@node$ ps auxw|grep kubelet
|
||||
root 3392 1.1 0.8 186804 65208 ? Sl 00:51 11:11 /usr/local/bin/kubelet --enable-debugging-handlers=true --config=/etc/kubernetes/manifests --allow-privileged=True --v=4 --cluster-dns=10.0.0.10 --cluster-domain=cluster.local --configure-cbr0=true --cgroup-root=/ --system-cgroups=/system --hairpin-mode=promiscuous-bridge --runtime-cgroups=/docker-daemon --kubelet-cgroups=/kubelet --babysit-daemons=true --max-pods=110 --serialize-image-pulls=false --outofdisk-transition-frequency=0
|
||||
|
||||
```
|
||||
|
||||
* 実際に使われている`hairpin-mode`を確認します。
|
||||
これを行うには、kubeletログを確認する必要があります。
|
||||
ログへのアクセス方法は、NodeのOSによって異なります。
|
||||
一部のOSでは/var/log/kubelet.logなどのファイルですが、他のOSでは`journalctl`を使用してログにアクセスします。
|
||||
互換性のために、実際に使われている`hairpin-mode`が`--hairpin-mode`フラグと一致しない場合があることに注意してください。
|
||||
kubelet.logにキーワード`hairpin`を含むログ行があるかどうかを確認してください。
|
||||
実際に使われている`hairpin-mode`を示す以下のようなログ行があるはずです。
|
||||
|
||||
```shell
|
||||
I0629 00:51:43.648698 3252 kubelet.go:380] Hairpin mode set to "promiscuous-bridge"
|
||||
```
|
||||
|
||||
* 実際に使われている`hairpin-mode`が`hairpin-veth`の場合、`Kubelet`にノードの`/sys`で操作する権限があることを確認します。
|
||||
すべてが正常に機能している場合、次のようなものが表示されます。
|
||||
|
||||
```shell
|
||||
for intf in /sys/devices/virtual/net/cbr0/brif/*; do cat $intf/hairpin_mode; done
|
||||
1
|
||||
1
|
||||
1
|
||||
1
|
||||
```
|
||||
|
||||
実際に使われている`hairpin-mode`が`promiscuous-bridge`の場合、`Kubelet`にノード上のLinuxブリッジを操作する権限があることを確認してください。
|
||||
`cbr0`ブリッジが使用され適切に構成されている場合、以下が表示されます。
|
||||
|
||||
```shell
|
||||
u@node$ ifconfig cbr0 |grep PROMISC
|
||||
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1460 Metric:1
|
||||
|
||||
```
|
||||
|
||||
* 上記のいずれも解決しない場合、助けを求めてください。
|
||||
|
||||
## 助けを求める
|
||||
|
||||
ここまでたどり着いたということは、とてもおかしなことが起こっています。
|
||||
`Service`は実行中で、`Endpoint`があり、`Pod`は実際にサービスを提供しています。
|
||||
DNSは動作していて、`iptables`ルールがインストールされていて、`kube-proxy`も誤動作していないようです。
|
||||
それでも、あなたの`Service`は機能していません。
|
||||
おそらく私たちにお知らせ頂いた方がよいでしょう。調査をお手伝いします！
|
||||
|
||||
[Slack](/docs/troubleshooting/#slack)または
|
||||
[Forum](https://discuss.kubernetes.io)または
|
||||
[GitHub](https://github.com/kubernetes/kubernetes)でお問い合わせください。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
詳細については、[トラブルシューティングドキュメント](/docs/troubleshooting/)をご覧ください。
|
||||
|
||||
{{% /capture %}}
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
title: "アプリケーションの実行"
|
||||
weight: 40
|
||||
---
|
||||
|
||||
|
|
@ -1,5 +1,4 @@
|
|||
---
|
||||
title: "Install Tools"
|
||||
title: "ツールのインストール"
|
||||
weight: 10
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -78,21 +78,24 @@ yum install -y kubectl
|
|||
{{< /tabs >}}
|
||||
|
||||
|
||||
### Snapを使用してインストールする
|
||||
### 他のパッケージマネージャーを使用してインストールする
|
||||
|
||||
Ubuntuまたは[snap](https://snapcraft.io/docs/core/install)パッケージマネージャーをサポートしているLinuxディストリビューションを使用している場合、kubectlは[snap](https://snapcraft.io/)アプリケーションとして利用することもできます。
|
||||
Ubuntuまたは[snap](https://snapcraft.io/docs/core/install)パッケージマネージャーをサポートする別のLinuxディストリビューションを使用している場合、kubectlは[snap](https://snapcraft.io/)アプリケーションとして使用できます。
|
||||
|
||||
1. snapユーザーに切り替えて、インストールコマンドを実行してください:
|
||||
Linuxで[Homebrew](https://docs.brew.sh/Homebrew-on-Linux)パッケージマネージャーを使用している場合は、kubectlを[インストール](https://docs.brew.sh/Homebrew-on-Linux#install)することが可能です。
|
||||
|
||||
```
|
||||
sudo snap install kubectl --classic
|
||||
```
|
||||
{{< tabs name="other_kubectl_install" >}}
|
||||
{{< tab name="Snap" codelang="bash" >}}
|
||||
sudo snap install kubectl --classic
|
||||
|
||||
2. インストールしたバージョンが最新であることを確認してください:
|
||||
kubectl version
|
||||
{{< /tab >}}
|
||||
{{< tab name="Homebrew" codelang="bash" >}}
|
||||
brew install kubectl
|
||||
|
||||
```
|
||||
kubectl version
|
||||
```
|
||||
kubectl version
|
||||
{{< /tab >}}
|
||||
{{< /tabs >}}
|
||||
|
||||
## macOSへkubectlをインストールする
|
||||
|
||||
|
|
@ -101,7 +104,7 @@ Ubuntuまたは[snap](https://snapcraft.io/docs/core/install)パッケージマ
|
|||
1. 最新リリースをダウンロードしてください:
|
||||
|
||||
```
|
||||
curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl
|
||||
curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl"
|
||||
```
|
||||
|
||||
特定のバージョンをダウンロードする場合、コマンドの`$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)`の部分を特定のバージョンに書き換えてください。
|
||||
|
|
@ -135,6 +138,11 @@ macOSで[Homebrew](https://brew.sh/)パッケージマネージャーを使用
|
|||
|
||||
1. インストールコマンドを実行してください:
|
||||
|
||||
```
|
||||
brew install kubectl
|
||||
```
|
||||
または
|
||||
|
||||
```
|
||||
brew install kubernetes-cli
|
||||
```
|
||||
|
|
@ -183,7 +191,7 @@ macOSで[MacPorts](https://macports.org/)パッケージマネージャーを使
|
|||
kubectl version
|
||||
```
|
||||
{{< note >}}
|
||||
[Docker for Windows](https://docs.docker.com/docker-for-windows/#kubernetes)は、それ自身のバージョンの`kubectl`をPATHに追加します。Dockerをすでにインストールしている場合、Dockerインストーラーによって追加されたPATHの前に追加するか、Dockerの`kubectl`を削除してください。
|
||||
[Docker Desktop for Windows](https://docs.docker.com/docker-for-windows/#kubernetes)は、それ自身のバージョンの`kubectl`をPATHに追加します。Docker Desktopをすでにインストールしている場合、Docker Desktopインストーラーによって追加されたPATHの前に追加するか、Docker Desktopの`kubectl`を削除してください。
|
||||
{{< /note >}}
|
||||
|
||||
### PSGalleryからPowerShellを使用してインストールする
|
||||
|
|
@ -274,7 +282,7 @@ Google Cloud SDKの一部として、kubectlをインストールすることも
|
|||
|
||||
## kubectlの設定を検証する
|
||||
|
||||
kubectlがKubernetesクラスターを探索し接続するために、[kubeconfigファイル](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)が必要になります。これは、`kube-up.sh`によりクラスターを作成した際や、Minikubeクラスターを正常にデプロイした際に自動生成されます。デフォルトでは、kubectlの設定は`~/.kube/config`に格納されています。
|
||||
kubectlがKubernetesクラスターを探索し接続するために、[kubeconfigファイル](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)が必要になります。これは、[kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh)によりクラスターを作成した際や、Minikubeクラスターを正常にデプロイした際に自動生成されます。デフォルトでは、kubectlの設定は`~/.kube/config`に格納されています。
|
||||
|
||||
クラスターの状態を取得し、kubectlが適切に設定されていることを確認してください:
|
||||
|
||||
|
|
@ -344,6 +352,12 @@ source /usr/share/bash-completion/bash_completion
|
|||
```shell
|
||||
kubectl completion bash >/etc/bash_completion.d/kubectl
|
||||
```
|
||||
- kubectlにエイリアスを張っている場合は、以下のようにシェルの補完を拡張して使うことができます:
|
||||
|
||||
```shell
|
||||
echo 'alias k=kubectl' >>~/.bashrc
|
||||
echo 'complete -F __start_kubectl k' >>~/.bashrc
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
bash-completionは`/etc/bash_completion.d`内のすべての補完スクリプトをsourceします。
|
||||
|
|
@ -403,7 +417,14 @@ export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d"
|
|||
- 補完スクリプトを`/usr/local/etc/bash_completion.d`ディレクトリに追加する:
|
||||
|
||||
```shell
|
||||
kubectl completion bash >/etc/bash_completion.d/kubectl
|
||||
kubectl completion bash >/usr/local/etc/bash_completion.d/kubectl
|
||||
```
|
||||
|
||||
- kubectlにエイリアスを張っている場合は、以下のようにシェルの補完を拡張して使うことができます:
|
||||
|
||||
```shell
|
||||
echo 'alias k=kubectl' >>~/.bashrc
|
||||
echo 'complete -F __start_kubectl k' >>~/.bashrc
|
||||
```
|
||||
|
||||
- kubectlをHomwbrewでインストールした場合（[前述](#homebrewを使用してmacosへインストールする)のとおり）、kubectlの補完スクリプトはすでに`/usr/local/etc/bash_completion.d/kubectl`に格納されているでしょう。この場合、なにも操作する必要はありません。
|
||||
|
|
@ -425,6 +446,13 @@ Zshにおけるkubectlの補完スクリプトは`kubectl completion zsh`コマ
|
|||
source <(kubectl completion zsh)
|
||||
```
|
||||
|
||||
kubectlにエイリアスを張っている場合は、以下のようにシェルの補完を拡張して使うことができます:
|
||||
|
||||
```shell
|
||||
echo 'alias k=kubectl' >>~/.zshrc
|
||||
echo 'complete -F __start_kubectl k' >>~/.zshrc
|
||||
```
|
||||
|
||||
シェルをリロードしたあとに、kubectlの自動補完が機能するはずです。
|
||||
|
||||
`complete:13: command not found: compdef`のようなエラーが出力された場合は、以下を`~/.zshrc`の先頭に追記してください:
|
||||
|
|
|
|||
|
|
@ -15,96 +15,172 @@ card:
|
|||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
コンピューターのBIOS上でVT-xもしくはAMD-vの仮想化が使用可能でなければなりません。Linux上で確認するために以下のコマンドを実行し、出力されることを確認してください。
|
||||
```shell
|
||||
egrep --color 'vmx|svm' /proc/cpuinfo
|
||||
{{< tabs name="minikube_before_you_begin" >}}
|
||||
{{% tab name="Linux" %}}
|
||||
Linuxで仮想化がサポートされているかどうかを確認するには、次のコマンドを実行して、出力が空でないことを確認します:
|
||||
```
|
||||
grep -E --color 'vmx|svm' /proc/cpuinfo
|
||||
```
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="macOS" %}}
|
||||
仮想化がmacOSでサポートされているかどうかを確認するには、ターミナルで次のコマンドを実行します。
|
||||
```
|
||||
sysctl -a | grep -E --color 'machdep.cpu.features|VMX'
|
||||
```
|
||||
出力に`VMX`が表示されている場合（色付けされているはずです）、VT-x機能がマシンで有効になっています。
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="Windows" %}}
|
||||
Windows 8以降で仮想化がサポートされているかどうかを確認するには、Windowsターミナルまたはコマンドプロンプトで次のコマンドを実行します。
|
||||
```
|
||||
systeminfo
|
||||
```
|
||||
次の出力が表示される場合、仮想化はWindowsでサポートされています。
|
||||
```
|
||||
Hyper-V Requirements: VM Monitor Mode Extensions: Yes
|
||||
Virtualization Enabled In Firmware: Yes
|
||||
Second Level Address Translation: Yes
|
||||
Data Execution Prevention Available: Yes
|
||||
```
|
||||
|
||||
次の出力が表示される場合、システムにはすでにHypervisorがインストールされており、次の手順をスキップできます。
|
||||
```
|
||||
Hyper-V Requirements: A hypervisor has been detected. Features required for Hyper-V will not be displayed.
|
||||
```
|
||||
|
||||
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## ハイパーバイザーのインストール
|
||||
# minikubeのインストール
|
||||
|
||||
ハイパーバイザーがインストールされていなかったら、OSにいずれかをインストールしてください。
|
||||
{{< tabs name="tab_with_md" >}}
|
||||
{{% tab name="Linux" %}}
|
||||
|
||||
Operating system | サポートしているハイパーバイザー
|
||||
:----------------|:---------------------
|
||||
macOS | [VirtualBox](https://www.virtualbox.org/wiki/Downloads), [VMware Fusion](https://www.vmware.com/products/fusion), [HyperKit](https://github.com/moby/hyperkit)
|
||||
Linux | [VirtualBox](https://www.virtualbox.org/wiki/Downloads), [KVM](http://www.linux-kvm.org/)
|
||||
Windows | [VirtualBox](https://www.virtualbox.org/wiki/Downloads), [Hyper-V](https://msdn.microsoft.com/en-us/virtualization/hyperv_on_windows/quick_start/walkthrough_install)
|
||||
### kubectlのインストール
|
||||
|
||||
kubectlがインストールされていることを確認してください。
|
||||
[kubectlのインストールとセットアップ](/docs/tasks/tools/install-kubectl/#install-kubectl-on-linux)の指示に従ってkubectlをインストールできます。
|
||||
|
||||
### ハイパーバイザーのインストール
|
||||
|
||||
ハイパーバイザーがまだインストールされていない場合は、これらのいずれかをインストールしてください:
|
||||
|
||||
• [KVM](https://www.linux-kvm.org/)、ただしQEMUも使っているもの
|
||||
|
||||
• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
|
||||
|
||||
{{< note >}}
|
||||
MinikubeはVMの中ではなくホスト上のKubernetesのコンポーネントの一部として実行する`--vm-driver=none`をサポートしています。このドライバーはハイパーバイザーではなく、DockerやLinuxの環境を必要とします。
|
||||
minikubeは、VMではなくホストでKubernetesコンポーネントを実行する`--vm-driver=none`オプションもサポートしています。
|
||||
このドライバーを使用するには、[Docker](https://www.docker.com/products/docker-desktop)とLinux環境が必要ですが、ハイパーバイザーは不要です。
|
||||
noneドライバーを使用する場合は、[Docker](https://www.docker.com/products/docker-desktop)からdockerのaptインストールを使用することをおすすめします。
|
||||
dockerのsnapインストールは、minikubeでは機能しません。
|
||||
{{< /note >}}
|
||||
|
||||
## kubectlのインストール
|
||||
### パッケージを利用したMinikubeのインストール
|
||||
|
||||
* kubectlのインストールは[kubectlのインストールと設定](/ja/docs/tasks/tools/install-kubectl/)を確認してください。
|
||||
Minikubeの*Experimental*パッケージが利用可能です。
|
||||
GitHubのMinikubeの[リリース](https://github.com/kubernetes/minikube/releases)ページからLinux(AMD64)パッケージを見つけることができます。
|
||||
|
||||
## Minikubeのインストール
|
||||
Linuxのディストリビューションのパッケージツールを使用して、適切なパッケージをインストールしてください。
|
||||
|
||||
### macOS
|
||||
### 直接ダウンロードによるMinikubeのインストール
|
||||
|
||||
[Homebrew](https://brew.sh)を使うことでmacOSにMinikubeを簡単にインストールできます。
|
||||
|
||||
```shell
|
||||
brew cask install minikube
|
||||
```
|
||||
|
||||
バイナリファイルを使用してmacOSにインストールすることも可能です。
|
||||
|
||||
```shell
|
||||
curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-darwin-amd64 \
|
||||
&& chmod +x minikube
|
||||
```
|
||||
|
||||
以下のコマンドを入力して、Minikubeを実行可能にしてください。
|
||||
|
||||
```shell
|
||||
sudo mv minikube /usr/local/bin
|
||||
```
|
||||
|
||||
### Linux
|
||||
|
||||
{{< note >}}
|
||||
ここではバイナリを使ってLinux上にMinikubeをインストールする方法を示します。
|
||||
{{< /note >}}
|
||||
|
||||
バイナリファイルを使用してLinuxにインストールできます。
|
||||
パッケージ経由でインストールしない場合は、スタンドアロンバイナリをダウンロードして使用できます。
|
||||
|
||||
```shell
|
||||
curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 \
|
||||
&& chmod +x minikube
|
||||
```
|
||||
|
||||
以下のコマンドを入力して、Minikubeを実行可能にしてください。
|
||||
Minikube実行可能バイナリをパスに追加する簡単な方法を次に示します:
|
||||
|
||||
```shell
|
||||
sudo cp minikube /usr/local/bin && rm minikube
|
||||
sudo mkdir -p /usr/local/bin/
|
||||
sudo install minikube /usr/local/bin/
|
||||
```
|
||||
|
||||
### Windows
|
||||
{{% /tab %}}
|
||||
{{% tab name="macOS" %}}
|
||||
### kubectlのインストール
|
||||
|
||||
kubectlがインストールされていることを確認してください。
|
||||
[kubectlのインストールとセットアップ](/docs/tasks/tools/install-kubectl/#install-kubectl-on-macos)の指示に従ってkubectlをインストールできます。
|
||||
|
||||
### ハイパーバイザーのインストール
|
||||
|
||||
ハイパーバイザーがまだインストールされていない場合は、これらのいずれかをインストールしてください:
|
||||
|
||||
• [HyperKit](https://github.com/moby/hyperkit)
|
||||
|
||||
• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
|
||||
|
||||
• [VMware Fusion](https://www.vmware.com/products/fusion)
|
||||
|
||||
### Minikubeのインストール
|
||||
[Homebrew](https://brew.sh)を使うことでmacOSにMinikubeを簡単にインストールできます:
|
||||
|
||||
```shell
|
||||
brew install minikube
|
||||
```
|
||||
|
||||
スタンドアロンのバイナリをダウンロードして、macOSにインストールすることもできます:
|
||||
|
||||
```shell
|
||||
curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-darwin-amd64 \
|
||||
&& chmod +x minikube
|
||||
```
|
||||
|
||||
Minikube実行可能バイナリをパスに追加する簡単な方法を次に示します:
|
||||
|
||||
```shell
|
||||
sudo mv minikube /usr/local/bin
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="Windows" %}}
|
||||
### kubectlのインストール
|
||||
|
||||
kubectlがインストールされていることを確認してください。
|
||||
[kubectlのインストールとセットアップ](/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows)の指示に従ってkubectlをインストールできます。
|
||||
|
||||
### ハイパーバイザーのインストール
|
||||
|
||||
ハイパーバイザーがまだインストールされていない場合は、これらのいずれかをインストールしてください:
|
||||
|
||||
• [Hyper-V](https://msdn.microsoft.com/en-us/virtualization/hyperv_on_windows/quick_start/walkthrough_install)
|
||||
|
||||
• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
|
||||
|
||||
{{< note >}}
|
||||
MinikubeをWindowsで実行するために、[Hyper-V](https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/quick-start/enable-hyper-v)もしくは[VirtualBox](https://www.virtualbox.org/)をインストールする必要があります。Hyper-VはWindows 10 Enterprise、Windows 10 Professional、Windows 10 Educationで実行できます。より詳しいインストールについてのドキュメントはMinikube公式の[GitHub](https://github.com/kubernetes/minikube/#installation)のリポジトリを参照してください。
|
||||
Hyper-Vは、Windows 10 Enterprise、Windows 10 Professional、Windows 10 Educationの3つのバージョンのWindows 10で実行できます。
|
||||
{{< /note >}}
|
||||
|
||||
### Chocolateyを使用したMinikubeのインストール
|
||||
|
||||
[Chocolatey](https://chocolatey.org/)を使うことでWindowsにMinikubeを簡単にインストールできます(管理者権限で実行する必要があります)。
|
||||
|
||||
```shell
|
||||
choco install minikube kubernetes-cli
|
||||
choco install minikube
|
||||
```
|
||||
|
||||
Minikubeのインストールが終わったら、現在のCLIのセッションを終了して再起動します。Minikubeは自動的にパスに追加されます。
|
||||
|
||||
#### 手動でWindowsにインストールする方法
|
||||
### インストーラーを使用したMinikubeのインストール
|
||||
|
||||
Windowsに手動でMinikubeをダウンロードする場合、[`minikube-windows-amd64`](https://github.com/kubernetes/minikube/releases/latest)をダウンロードし、名前を`minikube.exe`に変更してこれをパスに加えます。
|
||||
[Windowsインストーラー](https://docs.microsoft.com/en-us/windows/desktop/msi/windows-installer-portal)を使用してWindowsにMinikubeを手動でインストールするには、[`minikube-installer.exe`](https://github.com/kubernetes/minikube/releases/latest/download/minikube-installer.exe)をダウンロードしてインストーラーを実行します。
|
||||
|
||||
#### Windowsのインストーラー
|
||||
### 直接ダウンロードによるMinikubeのインストール
|
||||
|
||||
[Windows Installer](https://docs.microsoft.com/en-us/windows/desktop/msi/windows-installer-portal)を使ってWindowsに手動でインストールする場合、[`minikube-installer.exe`](https://github.com/kubernetes/minikube/releases/latest)をインストールし、インストーラーを実行します。
|
||||
WindowsにMinikubeを手動でインストールするには、[`minikube-windows-amd64`](https://github.com/kubernetes/minikube/releases/latest)をダウンロードし、名前を`minikube.exe`に変更して、パスに追加します。
|
||||
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
|
@ -114,19 +190,19 @@ Windowsに手動でMinikubeをダウンロードする場合、[`minikube-window
|
|||
|
||||
{{% /capture %}}
|
||||
|
||||
## クリーンアップし、新たに始める場合
|
||||
## ローカル状態のクリーンアップ {#cleanup-local-state}
|
||||
|
||||
もし以前に Minikubeをインストールしていたら、以下のコマンドを実行します。
|
||||
```shell
|
||||
minikube start
|
||||
```
|
||||
|
||||
このエラーが返ってきます。
|
||||
`minikube start`はエラーを返します。
|
||||
```shell
|
||||
machine does not exist
|
||||
```
|
||||
|
||||
以下のファイルを消去する必要があります。
|
||||
minikubeのローカル状態をクリアする必要があります:
|
||||
```shell
|
||||
rm -rf ~/.minikube
|
||||
```
|
||||
minikube delete
|
||||
```
|
||||
|
|
|
|||
Loading…
Reference in New Issue