Download to read offline
![Kubernetes on Mesos Deep Dive [Japanese]](https://cdn.slidesharecdn.com/ss_thumbnails/k8sonmesos-180626063613-thumbnail.jpg?width=640&height=640&fit=bounds)
超ざっくりKubernetes概要 -全体観を知ればこわくない、かもしれない？-
- 1.
- 2.
- 3. アジェンダ • Kubernetesって何者？ • まず物理構成を押さえます。 •次に、AWSのサービスと比較しながらみていきます。 • Kubernetesの論理的なリソース構成 • Appendix 適宜質問タイムを兼ねた小休憩を挟もうと思います。
- 4.
- 5.
- 6.
- 7. AWSサービスとの比較.2 標準DNS Persistent Storage wrapping IstioIngress GW 部分的に Ingress
- 8.
- 9. アジェンダ • Kubernetesって何者？ • まず物理構成を押さえます。 •次に、AWSのサービスと比較しながらみていきます。 • Kubernetesの論理的なリソース構成 • Appendix
- 10. k8sリソースの論理的な構成.1 1.まずクラスターが1つ 主に環境分離 2. 中に囲い(NS) チーム間/内のリソース分離 my-ns my-cluster empty-ns $ kubectlconfig use-context my-cluster $ kubectl config set-context --current --namespace=my-ns
- 12.
- 13. k8sリソースの論理的な構成.2 • Pod • (Containerのセット) •Replica Set • Podのデプロイ数を規 定 • Deployment • 何ぞ？ $ kubectl get pods -n my-ns web-pod $ kubectl get rs -n my-ns *3 set web-rs web-deploy $ kubectl get deployments -n my-ns
- 14. Deploymentの存在価値 答え： 新旧のReplica Setが 内部的に作られ、ロー リングデプロイが行わ れていく $ kubectlapply –f web.yaml -n my-ns web-rs web-deploy v1.0.0 web-rs v1.0.1
- 15. 外から各Podにアクセスさせるために 1.Serviceで負荷分散 2. Ingressで安全に接 続 my-ns my-cluster $ kubectlapply –f web-svc.yaml –n my-ns web-deploy web-svc web-ing $ kubectl apply –f web-ing.yaml –n my-ns
- 16. アジェンダ • Kubernetesって何者？ • まず物理構成を押さえます。 •次に、AWSのサービスと比較しながらみていきます。 • Kubernetesの論理的なリソース構成 • Appendix
- 17. Appendix.1 詳しくなるには触るがいちばん。 ->軽量版をローカルに入れて動かしましょ。 1. minikube: 一番おすすめ、multi-platform 2.microk8s: Ubuntu使いならあるいは？canonicalが作っている 3. k3s: IoT製品向け。 (今回WSLで使用) 4. Docker Desktopのk8s機能: オススメはあまりできない…
- 18. Appendix.2 動画ハンズオンはよき Kubernetes Hands-On -Deploy Microservices to the AWS Cloud | Udemy 書籍なら 入門・ベスプラ理解としてオススメ O'Reilly Japan - Kubernetesで実践するクラウドネイティブDevOps (oreilly.co.jp) リファレンスにはこちらをどうぞ Kubernetes完全ガイド 第2版 - インプレスブックス (impress.co.jp)
- 19.
Editor's Notes
- #2 超ざっくりkubernetes概要、始めてまいります。 すごく雑なパワポでお目汚しするかと思いますが、ご寛恕ください。 <NEXT>
- #3 まずこの会の目的から： 開発メンバーが大まかにk8s、つまりデプロイされる環境を理解 それによって、インフラメンバーへの依頼・協業がしやすくなること なので、主に全体感を持っていただくのが主目的です。 わからない概念を放っておくと以後の時間は意味のないものになってしまいますので、 わからないことは恥と思わずすぐにお聞きください。 なお、この資料はDockerやコンテナの理解とAWSの一般的なサービスについての知識を要します。 また、あくまでk8s初心者に向けた情報ですので、詳細な説明を避けています。 厳密に言えば間違い、というものも僅かに含まれていますので、 実際にkubernetesに相対するときにはしっかり各種ドキュメントを読み込んでください。 <NEXT>
- #4 アジェンダはこちらの通りです。 区切りごとに質問タイムを設けます。 <NEXT>
- #5 まずこれ、読み方ってなんでしょうかね？ よくあるのがクーバネティス、クバネティス、英語話者はキューバネティスみたいな発音をするみたいです。 私はここではクベ、クベちゃんと読もうと思います。あめちゃんみたいなノリですね。 さて、kubernetesってなんでしょうか？ — 質問 — <ANIMATION> 一口に言って、「コンテナオーケストレーションツール」、まるでECSのような。教科書的には正解でしょう。 しかし、この認識を正すのがここでの私の役割かと思います。 <ANIMATION> ずばり、k8sはちょっとしたプライベートクラウドです。 単なるオーケストレーションツールとみなすには、k8s及びCNCFエコシステムは多機能すぎます。 余談ですが、CNCFはクラウドネイティブコンピューティングファウンデーションの略です。 クラウドネイティブを目指すための様々なプロジェクトが走っており、k8sも代表的なプロジェクトです。 またkube???みたいなk8sを前提とするプロジェクトもありますね。 <NEXT>
- #6 まずはk8sの物理構成からいきましょう。 k8sの一側面はクラスター技術です。VMでもベアメタルでも基本的には複数台のサーバーを並べて、巨大なコンピューティングリソースのプールを作ります。その中にコンテナなどのリソースを配置します。 クラスター内には、かなりざっくりいうと少数のマスターと複数のワーカーノードが存在します。 マスターはひたすらワーカーノードの管理、コンテナなどコンポーネントの配置(スケジューリングといいます)をしたり。 当然その中には、既知の方もいらっしゃるかもしれませんがkubectlコマンドの受け口、つまりk8s APIの処理も含まれています。 念の為補足しておくと、kubectlはクラスター内部のリソース全般を管理するコマンドラインインターフェースです。 <ANIMATION> kubectl applyはその代表と言っていいでしょう。 なお、冗長構成とかの話をすると長くなるので省きます。 <NEXT>
- #7 では、いかにk8sプラットフォームが多機能であるかを軽く説明したいと思います。 やや乱暴ですが、一緒にAWSの対応するサービスを並べるとイメージしやすいかもしれませんね。まずk8sは、UserAccount/ServiceAccount/RBACという認可の機構を持っています。 UserAccountはIAMユーザー連動なので細かい設定はできませんが、IAMロールのような機構は持っています。 細かい話ですが、k8sのServiceAccountとAWS IAMロールを紐づけて、コンテナにAWSリソースへのアクセスを透過的に認可することもできます。 IAMは限定的とはいえ互換。 <ANIMATION> コンピューティング基盤としてはどうでしょう？ 当然コンテナをどうデプロイするかについてはもっとも基本的な機能です。 常時稼働のサービスもバッチもお手のもの、ということでECS互換。 <ANIMATION> ですがこのk8s、実はIaaSとしての機能も持つことが可能です。 kubevirtというプロジェクトをk8sに導入することでVMが管理できます。軽いEC2互換。 まぁ使っている例を聞いたことがないですが… <ANIMATION> さらにさらに、FaasSだってお手のものです、KNativeの導入さえすればですが。Lambda互換。 <ANIMATION> コンピューティングだけでこの有様です。 <NEXT>
- #8 ストレージはどうでしょうか？ 各コンテナには当然起動時に揮発性のストレージがアタッチされますが、一方でPersistent volumeという標準機構があります。 これはコンテナにアタッチできる永続ボリュームです。なので、アタッチされたコンテナが消滅しても残すことのできるボリュームも扱うことができます。 実体はEBS上のボリュームであり、それをPVとして扱うので、EBSラッパーと言えるでしょう。 <ANIMATION> サービスを公開するには？ そこには名前解決とネットワークの疎通、負荷分散が必要でしょう。 クラスター内部では数多くのコンテナが立っていて、当然コンテナ間の通信が発生しますし、kubectlを経由してのコンテナアクセスもあります。 そんな時にはマスターノードがDNS(kube-dns)機構を持っています。 しかし外部からのアクセスは…? そんな時にIstio ingress gatewayが利用できます。例としてIstio ingress gatewayに*..example.comというDNSレコードを渡して設定を施せば、例えばapi.example.comのアクセスに対しAPIサーバーのコンテナ群に通信を通してくれるでしょう。 部分的ですがRoute53互換。 <ANIMATION> ちなみにこのIstioはIngress GWでなく単体のIstioとしてのほうが有名です。 サービスメッシュを実現するためのツールですね。 それからコンテナにインターネットを経由してエンドユーザーがアクセスするにはどうしましょうか？ 当然クラスターをパブリックネットワークにおけば通信はできるでしょうが、手痛い代償を払うことになるでしょうね。 クラスターはプライベートなネットワークに置き、ALBを介して通信させるといいですね。そんな時にはk8s標準のIngressを使うと良いでしょう。 <ANIMATION> これはALBをはじめとするクラウドのProxy/LBをラップしてくれます。 <NEXT>
- #9 最後監視ですね。 FluentdやFluentBitを使ってログ収集してログ分析基盤に。 <ANIMATION> メトリクス収集やアラートはPrometheus、 <ANIMATION> そしてメトリクスの可視化はGrafanaに。 <ANIMATION> これらを合わせてCloudWatch互換と言えるでしょう。 <NEXT>
- #10 サービスを動かすための必須な機能をざっと見ていただきました。 <ANIMATION> これまでのものは本当に一端です。 他にもイケてるCI/CDは組めますし、ミドルウェアをk8sで動かすことによってマネージドサービスはいくらでも作れます。 CNCFには数多くのプロジェクトが存在し、あらゆるワークフローに対応するシステムをk8sで組むことができるでしょう。 いかにk8sが多機能で、コンテナオーケストレーションという言葉では足りないことがお分かりいただけたことと思います。 といったところで、少し休憩を挟みたいと思います。 答えられる範囲で回答しますので、よければご質問もどうぞ。 <NEXT>
- #11 そんなk8sですが、皆さんはアプリケーションを開発しk8sのプラットフォームにサービスをデプロイして機能を提供するミッションをお持ちです。 その中においてデプロイしたコードがk8sでどう扱われるのかを知る必要もあるかもしれません。 そこでk8sクラスター内でコンテナが論理的にどう扱われるのかを説明します。 まずクラスターが存在していて、ログインしてみましょう。 コマンド打ってみましょうか。 <ANIMATION> Context、日本語で言えば文脈ということですが、これはほぼクラスターと同じと思ってください。 use-contextとは過去接続設定を行った、とあるクラスターに対して再度接続しています。 当然ローカルPCでは複数クラスターのcontextを保持できます。 その場合、最後のクラスター名を別のものに変えれば、任意のクラスターに接続できるわけです。 <ANIMATION> これはクラスター管理者向けの情報、つまりめちゃくちゃ余談なのですが、 Contextを分ける、つまりクラスターをどのくらい持つかにも戦略はあります。 そしてこれは環境分離が一般的です。つまり本番クラスター、ステージクラスターなど。 中にはコスト圧縮を突き詰めて全部一緒のクラスターに突っ込む組織もあるでしょうが、それは断言しましょう、悪手とするべきです。 <ANIMATION> <ANIMATION> さて、クラスターに入ったところ、グループがありますね？ これはName Spaceという論理的なリソースのセグメントです。 <ANIMATION> K8sのリソースはNSの中に配置・管理されますが、基本的に各リソースは同じNS内のリソースにしかアクセスができません。 それによって、例えば〇〇チームのNSとか、DBセグメントのNSとか、そういった分離ができるわけです。 そうして、オペミスによる障害の波及を防いでいきます。 <ANIMATION> NSを固定して事故を防ぎましょう、という感じですね。 <NEXT>
- #12 なくてもいいかもですが、NSこちらはWSL上にk8sの軽量版をインストールした上でNSのリストを出しました。 背景が白くなっているところですね。 ご覧の通り、すでにNSが複数存在しています。 RDBをインストールすると管理用データベースが作成されますが、これも同様にk8sの管理に使われるメタ的なリソースが配置されています。 <NEXT>
- #13 続いて本命のリソースたちです。 <ANIMATION> <ANIMATION> なにやらコンテナはかなりの階層構造を持っていそうですね。 別の図を用いてStep-by-Stepで見ていきましょう。 <NEXT>
- #14 k8sでコンテナをデプロイする際、その最小単位はコンテナではなくPodです。 <ANIMATION> <ANIMATION> <ANIMATION> Podは役割の異なる複数のコンテナの集合体で、localhostを共有しています。 つまり皆さんの端末でdocker-composeで立ち上げた1セットのコンテナ環境と同じということです。 同一Pod内での通信は端末内での通信と同様ですし、なんならファイルシステムだって共有できます。 だからこそ、webコンテナとFluentdコンテナを立ち上げ、webサーバーが吐き出したログをFluentdが読み取ってログ集積所に送信する、なんてことも可能なのです。 <ANIMATION> 基本的にk8s内ではこのPodをクラスター内に複数作成し、負荷分散と地理的な冗長性(multi-AZ)を確保します。この「Podを複数立ち上げる」、というのが次のグルーピングであるReplica Setの役割です。 <ANIMATION> <ANIMATION> <ANIMATION> Replica SetでPodの数を指定すれば、その数だけPodが立ち上がります。 その内1つのPodが何らかのトラブルで落ちれば、Replica Setは代わりのPodを立ち上げてくれます。 これによって耐障害性:Auto-healの恩恵が受けられるわけです。 <ANIMATION> しかしまだ終わりではありません。 <ANIMATION> <ANIMATION> <ANIMATION> このグループはDeploymentと呼ばれます。 つまり、最終的にコンテナはk8sの中でDeployment -> Replica Set -> Podという階層構造を持った状態で管理されます。 そして、開発者がサービスをk8sにデプロイするとすれば、そのための設定はPodでもReplica Setでもなく、それらを内包しているDeploymentに対して行うことになるでしょう。 もちろん、kubectlを使用してPodやReplica Set単体をデプロイすることも可能ではありますが、避けるべきことではあります。 なぜ？それはイベントに沿う方がわかりやすいでしょう。 <NEXT>
- #15 まず、my-appというコンテナリポジトリをチームで管理し、その最新1.0.0がk8sにもデプロイ済みだとします。 ここで、開発が終了し、新しい1.0.1のイメージがリポジトリにpushされ、作業者あるいはCDサービスがリリースを行うことになります。 担当者は、Deploymentの設定内部にあるPodのコンテナ情報から、そのコンテナイメージのバージョンを変更してk8sに設定反映をします。 <ANIMATION> <ANIMATION> すると、平常時はDeploymentの下に1つしかなかったReplica Setは2つに増えます。 もうお分かりですね？ <ANIMATION> <ANIMATION> <ANIMATION> 既存Replica SetのPodが減っていくにつれ、新Replica Setに新しいイメージをベースにしたPodが増えていき、やがてはReplica Setが置き換わるわけです。 <ANIMATION> <ANIMATION> k8sの標準的な機能を使うだけで簡単にローリングデプロイが実現できますね。 繰り返しになりますが、Pod、RS、Deploymentというのがコンテナの基本的な構成となります。 <NEXT>
- #16 すみません、頭パツパツかもしれませんが、もう少し頑張ってください。 Deploymentに入れる形でアプリケーションが起動できたものの、ネットワークがなければアプリケーションは無用の長物です。 次はネットワークの根幹部分だけ説明します。 まず、Deploymentによって同じ役割を持ったPodが複数立ち上がると、 そのPodに向かうトラフィックを解決し、なおかつ複数Podへの負荷分散をする必要があります。 そのためにはServiceが必要です。 <ANIMATION> そこでDeploymentと一対のセットになる形でServiceを作成します。 すると、Serviceは紐づいたDeployment下のPodに対しアクセスを振り分けてくれます。 <ANIMATION> <ANIMATION> これが基本的なネットワークの設定です。 <ANIMATION> 実はServiceにも、あるいはPod単体にも設定次第でIPアドレスを振ることができるので、極論その設定をしてしまえばアクセスはできてしまいます。 が、その経路を使用して外部のエンドユーザーが使ってよいかというとそれは違いますね？ 繰り返しになりますが、クラスターのネットワークはプライベートな空間に隠蔽して、エンドユーザーがアクセス可能な終端を作ってあげる必要があります。 それがIngressです。 <ANIMATION> <ANIMATION> AWSの場合には、Ingressの管理下でALBが利用可能です。 この場合のIngressは負荷分散というよりもSSL/TLS終端であったり、複数Serviceに対するルーティングであったりします。 <NEXT>
- #17 ここまでk8sにおけるコンテナ管理の単位とネットワーキングを見てきました。 といったところで私からの概要説明は以上です。 <ANIMATION> そのほか、k8sについてもっと知りたいならということで、その参考情報を載せておきます。 <NEXT>
- #18 正直兎にも角にも詳しくなるには触るのが一番です。 ローカル端末には以下からお好きなものをインストールするのがよいでしょう。 minikube: 一番おすすめ。 microk8s: もしUbuntu使いなら k3s: IoT製品向けの省機能版、WSLに入れたのもこれ Dockerのk8s機能: あまりオススメしない 余談ですが、私は近々自宅サーバーにk3sの導入を考えています。 <NEXT>
- #19 それから参考情報です。 正直、本とにらめっこするよりも動画形式の方が頭に入るかと思います。ハンズオン大事ですね。 もし英語OKであれば下記はオススメです。 (日本語字幕もいけるかもしれません) windowsとローカルminikubeを使っています。(というのもあってminikubeをオススメしました) 最終的にこの動画ではEKSにデプロイをしていきます。 Udemyではその他日本語の動画もあるようですが、すみません、探してみてください。 書籍であれば、ぜひ入門書としてこちらをご一読ください。 オライリーですがわかりやすく、k8sだけでなくインフラ/DevOpsとしてどういう方向性が正しいのかという示唆にも富んでいる良書です。 それからリファレンス的に下のものをどうぞ。 どちらもKindleではなくPDFとして購入可能です。 <NEXT>
- #20 といったところで本当に終わりです。 ご清聴ありがとうございました。 <FIN>