WEBVTT

00:00:00.400 --> 00:00:04.300
今日は誰もが耳にしたことはあっても説明できないKubernetesについてお話しします。

00:00:04.460 --> 00:00:08.200
この技術がわかりにくいのは実際に直面するまで多くの人が気づかない問題を解決するものだからです。

00:00:08.380 --> 00:00:11.720
誰もが重要だとは知っていますが何をするものかと尋ねるとみんな一様に言葉に詰まります。

00:00:11.880 --> 00:00:14.280
これはDockerの代替品でもクラウドOSでもありません。

00:00:14.460 --> 00:00:17.380
よく相互解されるのですが混乱するのも無理はありません。

00:00:17.560 --> 00:00:20.900
Kubernetesは直面するまで存在すら知らない問題を解決するツールだからです。

00:00:21.040 --> 00:00:24.680
管理すべきコンテナが数個を超えた時に初めて不可欠なツールとなります。

00:00:24.680 --> 00:00:34.080
このエピソードを終える頃にはKubernetesの正体やコンテナとの関係性、そしてゼロから構築したくないチームにとってなぜAzure Kubernetesサービスが実用的であるかが理解できるはずです。

00:00:34.220 --> 00:00:36.420
コーヒーを片手にさあ見ていきましょう。

00:00:36.580 --> 00:00:37.780
コンテナ以前の問題。

00:00:38.000 --> 00:00:39.820
まずはその問題に立ち返ってみましょう。

00:00:40.020 --> 00:00:42.020
10年前のソフトウェア企業を想像してみてください。

00:00:42.200 --> 00:00:46.540
いくつかのアプリを動かすためにサーバーを購入しOSをインストールしてすべて手作業でデプロイしていました。

00:00:46.540 --> 00:00:50.080
アプリごとに専用のマシンが必要でリソースを共有することはできませんでした。

00:00:50.080 --> 00:00:54.900
あるアプリが大量のメモリを必要とし、別のアプリがほとんど使わなくてもそれぞれに専用のサーバーが必要でした。

00:00:55.080 --> 00:00:56.240
その無駄は甚大でした。

00:00:56.460 --> 00:01:02.520
サーバーの稼働率は20%程度でしたが、アプリ間で依存関係の競合が起きるため統合することもできませんでした。

00:01:02.680 --> 00:01:09.020
部屋中がサーバーで埋め尽くされ、どれもほとんど稼働していないのに電力と冷却コストを消費し、常にメンテナンスが必要な状態でした。

00:01:09.180 --> 00:01:12.520
あるアプリはPython3、7を必要とし、別のアプリは3.8を必要とします。

00:01:12.520 --> 00:01:15.160
古いライブラリが必要なものもあれば、最新版が必要なものもありました。

00:01:15.260 --> 00:01:20.460
同じマシンで動かせば不具合が起きるため、結局サーバーを買い増し、ほとんど遊んでいるハードウェアに金を払い続けることになったのです。

00:01:20.600 --> 00:01:30.280
仮想マシン、VM、和物理サーバーを分割できるため多少の助けにはなりましたが、各VMはOS全体を抱えるため非常に重く、リスクとメモリを消費し、起動に数分もかかりました。

00:01:30.480 --> 00:01:33.840
しかも、それぞれを個別に設定する必要があり、膨大な手間がかかりました。

00:01:33.840 --> 00:01:38.520
依然として、すべてのOSを管理しパッチを当て、更新し、セキュリティを確保しなければなりませんでした。

00:01:38.660 --> 00:01:41.780
チームは、もっと軽量でポータブルなものを必要としていました。

00:01:41.980 --> 00:01:48.080
VMのようなオーバーヘッドなしに、アプリと実行に必要なすべてをパッケージ化でき、マシン間で簡単に移動できる方法です。

00:01:48.260 --> 00:01:50.100
そこで登場したのがコンテナです。

00:01:50.280 --> 00:01:51.380
コンテナの正体。

00:01:51.540 --> 00:01:55.960
コンテナとは、アプリケーションと実行に必要なすべてを詰め込んだ小さなパッケージのことです。

00:01:55.960 --> 00:02:00.720
つまり、コード、ランタイム、ライブラリ、設定ファイルがすべて一つのユニットとしてまとめられています。

00:02:00.900 --> 00:02:03.580
ソフトウェアのための輸送用コンテナだと考えてください。

00:02:03.760 --> 00:02:08.360
輸送用コンテナはトラック、列車、船のどれに乗せてもコンテナ自体は変わりません。

00:02:08.540 --> 00:02:10.740
ソフトウェアコンテナも同じ仕組みで動作します。

00:02:10.940 --> 00:02:15.720
一度ビルドすれば、ノートPC、テストサーバー、本番環境のどこでも同じように動作します。

00:02:15.900 --> 00:02:19.220
コンテナと仮想マシンの主な違いは、効率性の高さです。

00:02:19.220 --> 00:02:24.920
仮想マシンは独自のフルOSを実行するため、それぞれが専用のカーネルやシステムファイル一式を必要とします。

00:02:25.080 --> 00:02:26.980
コンテナはホストOSを共有します。

00:02:27.220 --> 00:02:30.240
それは、独自の分離された環境を持つ単なるプロセスにすぎません。

00:02:30.400 --> 00:02:33.240
つまり、コンテナは数分ではなく、数秒で起動します。

00:02:33.420 --> 00:02:36.880
メモリ使用量も少なく、一台のマシンにより多くのコンテナを詰め込めます。

00:02:37.060 --> 00:02:41.880
Dockerは、開発者がコマンド一つで簡単に構築実行できるようにしたことで、コンテナを普及させました。

00:02:42.080 --> 00:02:45.560
その瞬間自分の環境では動く、という問題が解消され始めました。

00:02:45.720 --> 00:02:49.480
ノートPC上のコンテナでアプリが動けば、サーバー上でも同じように動作します。

00:02:49.660 --> 00:02:51.420
環境がどこでも一貫しているのです。

00:02:51.580 --> 00:02:54.540
しかし、コンテナはある問題を解決する一方で、新たな問題を生み出しました。

00:02:54.740 --> 00:02:57.200
数個のコンテナであれば、手動管理でも問題ありません。

00:02:57.420 --> 00:03:00.040
自分で起動や停止を行い、状況を把握できるからです。

00:03:00.180 --> 00:03:02.200
では、数百個になったらどうなるでしょうか?

00:03:02.200 --> 00:03:07.940
どのサーバーでどのコンテナを動かすか決め、失敗したものを再起動し、互いに接続し、アクセス急増時にはスケールアップする必要があります。

00:03:08.160 --> 00:03:11.100
それは新たな課題であり、まさにそこでKubernetesの出番となります。

00:03:11.280 --> 00:03:12.760
オーケストレーションの問題です。

00:03:12.920 --> 00:03:17.000
さて、コンテナを導入し、アプリをパッケージ化し、どこでも一貫して動くようになり、順調に見えます。

00:03:17.180 --> 00:03:18.820
しかし、それも束の間のことです。

00:03:18.980 --> 00:03:21.340
10個や20個のコンテナなら、手動で管理できます。

00:03:21.340 --> 00:03:26.360
どのサーバーで何を動かしているか把握し、クラッシュすれば再起動し、あちこちを更新することも可能です。

00:03:26.480 --> 00:03:27.620
管理可能な範囲です。

00:03:27.800 --> 00:03:29.600
しかし、やがてアプリケーションは成長します。

00:03:29.780 --> 00:03:31.360
マイクロサービスへと移行するのです。

00:03:31.540 --> 00:03:34.540
すると、一つの巨大なアプリではなく、20個の小さなアプリに分かれます。

00:03:34.700 --> 00:03:39.040
信頼性のために各アプリを複数コピーして動かすと、今や200個ものコンテナを扱うことになります。

00:03:39.220 --> 00:03:40.860
もはや手動管理では限界です。

00:03:40.860 --> 00:03:46.860
各サーバーにどのコンテナを配置するかを決め、失敗時には再起動し、通信できるように接続しなければなりません。

00:03:47.060 --> 00:03:52.920
セールや製品発表などでトラフィックが急増すればスケールアップし、落ち着けばスケールダウンする必要もあります。

00:03:53.200 --> 00:04:00.380
また、ダウンタイムなしで更新をロールアウトするには、古いコンテナを新しいものへ一つずつ慎重に入れ替え、何も壊さないようにしなければなりません。

00:04:00.540 --> 00:04:04.740
これらがオーケストレーションの問題であり、まさにKubernetesが解決するために作られたものなのです。

00:04:04.740 --> 00:04:10.080
Kubernetesはコンテナ化されたアプリケーションのデプロイ、スケーリング、管理を自動化するオープンソースのプラットフォームです。

00:04:10.200 --> 00:04:12.800
データセンター向けのオペレーティングシステムだと考えてください。

00:04:12.980 --> 00:04:20.200
WindowsやLinuxが単一のコンピュータ上でCPUやメモリ、リスクなどのリソースを管理するように、Kubernetesはサーバー群全体のリソースを管理します。

00:04:20.400 --> 00:04:23.920
すべてのマシンを、一つの巨大なコンピューティングパワーの集合体として扱うのです。

00:04:23.920 --> 00:04:29.220
実行したい内容を伝えれば、どこで動かし、どのように維持し、どのように他と接続するかをKubernetesが判断します。

00:04:29.360 --> 00:04:32.140
核となる概念は、Pod、Node、そしてクラスタです。

00:04:32.300 --> 00:04:34.580
それでは、Kubernetesがどのように動作するのかを見ていきましょう。

00:04:34.700 --> 00:04:37.040
Kubernetesにおける最小単位は、Pod、Podと呼ばれます。

00:04:37.160 --> 00:04:39.200
Podは一つ以上のコンテナをまとめる役割を持ちます。

00:04:39.360 --> 00:04:43.320
同じPod内のコンテナはストレージとネットワークを共有しているため、ローカルホスト経由で互いに通信できます。

00:04:43.500 --> 00:04:45.780
Podはデプロイの最小単位だと考えると良いでしょう。

00:04:45.960 --> 00:04:48.340
Kubernetesでは、コンテナを直接デプロイすることはありません。

00:04:48.500 --> 00:04:49.680
デプロイするのはPodです。

00:04:49.840 --> 00:04:52.220
Podは単独では動かず、Nodeの上で動作します。

00:04:52.420 --> 00:04:55.860
Nodeとは、Kubernetesクラスタの一部である物理または仮想サーバーのことです。

00:04:56.000 --> 00:05:00.620
各NodeはPodを動かすために必要なソフトウェアを実行しており、他にもいくつかの要素が含まれていますが、それは後ほど説明します。

00:05:00.620 --> 00:05:04.140
クラスタとは、統合された一つのシステムとして管理されるすべてのNodeの集合体です。

00:05:04.260 --> 00:05:09.040
簡単に言えば、Podはアプリケーションであり、Nodeはその実行場所、そしてクラスタが環境全体を指します。

00:05:09.200 --> 00:05:10.540
Podは一時的な存在です。

00:05:10.740 --> 00:05:12.460
いつでも作成、破棄、移動が可能です。

00:05:12.580 --> 00:05:13.700
これは設計上の仕様です。

00:05:13.840 --> 00:05:16.380
Nodeに障害が発生しても、KubernetesはPodを別のNodeへ移動させます。

00:05:16.560 --> 00:05:18.640
スケールアップが必要な時は、新しいPodを作成します。

00:05:18.640 --> 00:05:20.820
Podがクラッシュした場合は、自動的に置き換えられます。

00:05:20.940 --> 00:05:22.920
システム全体がPodを一時的なものとして扱うのです。

00:05:23.060 --> 00:05:26.100
しかし、Podが頻繁に入れ替わると、通信先を特定する方法が必要になります。

00:05:26.280 --> 00:05:28.780
そこで、Podと直接通信するのではなくサービスを介して通信します。

00:05:28.960 --> 00:05:32.820
サービスは安定したネットワークアドレスを提供し、Podが入れ替わっても正しいPodへトラフィックを転送します。

00:05:32.980 --> 00:05:34.220
ホテルを想像してみてください。

00:05:34.400 --> 00:05:36.300
ホテルの電話番号がこのサービスに当たります。

00:05:36.300 --> 00:05:39.180
部屋の宿泊客は常に入れ替わりますが、ホテルの電話番号は変わりません。

00:05:39.280 --> 00:05:41.860
フロントに電話をかければ、適切な部屋に回線を繋いでくれますよね。

00:05:41.980 --> 00:05:44.300
Kubernetesのサービスも、まさにこれと同じ働きをします。

00:05:44.500 --> 00:05:48.660
アプリケーションを実行している現在のPodへ常に誘導する、固定のアドレスを提供してくれるのです。

00:05:48.800 --> 00:05:51.100
コントロールプレーン、それはクラスターの頭脳です。

00:05:51.260 --> 00:05:53.600
ここまで、Pod、ノード、クラスターについて見てきました。

00:05:53.760 --> 00:05:55.940
では、何をどこで動かすのか、誰が決めているのでしょうか。

00:05:56.060 --> 00:05:57.520
それはコントロールプレーンの役割です。

00:05:57.660 --> 00:06:00.680
すべてのKubernetesクラスターには必ず備わっており、システム全体を司る頭脳となっています。

00:06:00.860 --> 00:06:02.360
すべての決定はここで行われます。

00:06:02.360 --> 00:06:04.340
コントロールプレーンにはいくつかのコンポーネントがあります。

00:06:04.520 --> 00:06:07.560
最初の一つはAPIサーバーで、これはクラスターの正面玄関として機能します。

00:06:07.700 --> 00:06:13.440
コマンドライン、ダッシュボード、自動化スクリプトなど、Kubernetesに送るあらゆるコマンドはAPIサーバーを経由します。

00:06:13.620 --> 00:06:18.800
APIサーバーはリクエストを認証し、要求された操作の権限があるかを確認してから、適切な場所へ渡します。

00:06:18.940 --> 00:06:22.520
Kubernetesでは、APIサーバーを通さずに何かが行われることはありません。

00:06:22.680 --> 00:06:26.140
次はスケジューラーで、各Podをどのノードで実行するかを決定します。

00:06:26.140 --> 00:06:35.220
このアプリケーションを実行したいと指示すると、スケジューラーは利用可能な全ノードを調査し、CPU、メモリ、リスク容量などのリソース状況を確認して、最適なノードを選びます。

00:06:35.400 --> 00:06:38.940
それはまるで、宿泊客のニーズに合わせて部屋を割り当てるホテルのマネージャーのようです。

00:06:39.100 --> 00:06:43.820
荷物が多い客には広い部屋を、軽量なアプリケーションには空き容量のある小さなノードを割り当てます。

00:06:43.980 --> 00:06:45.660
次にコントローラーマネージャーがあります。

00:06:45.900 --> 00:06:49.760
このコンポーネントはクラスターを監視し、実際の状態が宣言した通りであることを保証します。

00:06:49.920 --> 00:06:52.540
例えば、ウェブアプリを3つコピーして実行したいと宣言したとします。

00:06:52.700 --> 00:06:55.720
コントローラーマネージャーは、実際に3つのコピーが実行されているかを確認します。

00:06:55.900 --> 00:06:58.580
もし1つがクラッシュすれば、それを検知して代替品を起動します。

00:06:58.780 --> 00:07:01.560
誰かが誤ってPodを削除しても、新しいPodを作成します。

00:07:01.560 --> 00:07:04.160
クラスターの整合性を保つためのコンポーネントです。

00:07:04.300 --> 00:07:07.180
そして最後に、クラスターのデータベースであるETCDがあります。

00:07:07.400 --> 00:07:11.200
何が実行されているか、どこで実行されているか、どのように構成されているかなど、すべてを記録します。

00:07:11.340 --> 00:07:13.700
クラスター全体にとっての信頼の拠り所となります。

00:07:13.920 --> 00:07:19.060
APIサーバーが正面玄関なら、ETCDはすべての記録が保管されているバックオフィスのキャビネットのようなものです。

00:07:19.200 --> 00:07:23.720
この設計の素晴らしい点は、やりたいことを宣言するだけで、Kubernetesがそれを実現する方法を考えてくれることです。

00:07:23.720 --> 00:07:27.180
やり方を支持するのではなく、最終的な結果をどうすべきかを伝えるのです。

00:07:27.320 --> 00:07:31.120
これが宣言的モデルであり、Kubernetesのあらゆる動作の革新となる考え方です。

00:07:31.260 --> 00:07:34.120
ワークロード、デプロイメント、サービス、そしてスケーリング。

00:07:34.260 --> 00:07:37.320
では、実際にKubernetesでアプリケーションを実行する方法についてお話ししましょう。

00:07:37.480 --> 00:07:39.160
Podを直接作成することはありません。

00:07:39.340 --> 00:07:42.240
その代わりに、デプロイメントと呼ばれるより高レベルなオブジェクトを使用します。

00:07:42.300 --> 00:07:49.700
デプロイメントとは、Podのコピーをいくつ実行するか、どのコンテナイメージを使うか、新しいバージョンが出た際にどう更新するかをKubernetesに伝えるマネージャーだと考えてください。

00:07:49.840 --> 00:07:52.660
これがステートレスアプリケーションを実行する標準的な方法です。

00:07:52.840 --> 00:07:57.380
デプロイメントを更新して新しいバージョンのアプリをプッシュすると、Kubernetesはローリングアップデートを実行します。

00:07:57.540 --> 00:08:01.180
Podを一つずつ置き換え、常に少なくとも一つのコピーが実行されている状態を保ちます。

00:08:01.340 --> 00:08:04.240
つまり、ダウンタイムやユーザーへの突然の中断が発生しません。

00:08:04.340 --> 00:08:08.540
新しいバージョンで問題が発生しても、単一のコマンドで以前のバージョンにロールバックできます。

00:08:08.720 --> 00:08:10.280
これは強力な安全策です。

00:08:10.420 --> 00:08:12.440
しかし、Podにはアクセスできる必要があります。

00:08:12.660 --> 00:08:14.080
そこで役立つのがサービスです。

00:08:14.260 --> 00:08:17.920
サービスは安定したネットワークアドレスを提供し、適切なPodへトラフィックをルーティングします。

00:08:18.100 --> 00:08:22.360
また、それらのPodをアプリケーションの他の部分や外部へ公開することも可能です。

00:08:22.560 --> 00:08:29.000
サービスは、クラスター内でのみアクセス可能な内部向けか、インターネットからアクセス可能なパブリックIPを持つ外部向けかに分かれます。

00:08:29.180 --> 00:08:31.320
さて、スケーリングについてお話ししましょう。

00:08:31.320 --> 00:08:34.960
Kubernetesは需要に応じてアプリケーションを自動的に拡大・縮小できます。

00:08:35.140 --> 00:08:42.100
目標、例えばCPU使用率70%を設定すると、使用率がそれを超えればPodを追加し、下がればPodを削除します。

00:08:42.260 --> 00:08:46.220
トラフィックの急増時にはアプリケーションをスケールアップし、落ち着けばスケールダウンします。

00:08:46.460 --> 00:08:47.900
手動操作は必要ありません。

00:08:48.080 --> 00:08:50.300
しかし、この強力な機能には複雑さが伴います。

00:08:50.300 --> 00:08:55.700
自身のKubernetesクラスターを運用する場合、コントロールプレーン、アップグレード、セキュリティパッチ、バックアップのすべてに責任を持つ必要があります。

00:08:55.880 --> 00:09:00.160
ノード障害、ネットワーク構成、クラスターのスケーリングに対応するには深い専門知識が必要です。

00:09:00.320 --> 00:09:03.660
多くのチームはアプリケーションの開発よりもクラスターの管理に時間を費やしています。

00:09:03.860 --> 00:09:06.040
そこで登場するのが、マネージドKubernetesです。

00:09:06.220 --> 00:09:08.460
セルフマネージドとマネージドKubernetesの違いについて。

00:09:08.680 --> 00:09:11.440
それでは、自身でKubernetesを運用する現実について話しましょう。

00:09:11.540 --> 00:09:17.400
独自のクラスターを構築すると、コントロールプレーン、アップグレード、セキュリティパッチ、ETCDのバックアップなど、すべてに責任を負うことになります。

00:09:17.540 --> 00:09:20.280
APIサーバーがダウンした場合、それはあなたの責任です。

00:09:20.460 --> 00:09:24.320
使用しているバージョンにセキュリティの脆弱性が見つかれば、自分でパッチを適用する必要があります。

00:09:24.500 --> 00:09:27.480
ETCDが破損した場合は、バックアップから復元しなければなりません。

00:09:27.640 --> 00:09:29.680
これらすべてに深い専門知識が求められます。

00:09:29.840 --> 00:09:34.580
ノードの障害、クラスターレベルでのネットワークの仕組み、そしてシステムを壊さずにスケールさせる方法を理解しておく必要があります。

00:09:34.760 --> 00:09:36.940
多くのチームが驚くのは、次の点です。

00:09:36.940 --> 00:09:41.920
多くの組織が、その上で動くアプリケーションの構築よりも、Kubernetesクラスターの管理に多くの時間を費やしています。

00:09:42.060 --> 00:09:46.120
絶えずアップグレードと格闘し、ネットワークの問題をトラブルシューティングし、ノード障害に対処しています。

00:09:46.260 --> 00:09:48.320
クラスターの管理がフルタイムの仕事になってしまうのです。

00:09:48.460 --> 00:09:51.020
本来、Kubernetesを採用した目的はそこではないはずです。

00:09:51.160 --> 00:09:53.280
ここでマネージドKubernetesサービスの出番です。

00:09:53.420 --> 00:09:57.620
Azure Kubernetes Service、AXEのようなサービスは、コントロールプレーンを代行してくれます。

00:09:57.620 --> 00:10:01.820
AzureがAPIサーバー、ETCD、スケジューラー、コントローラーマネージャーを管理します。

00:10:01.940 --> 00:10:04.560
パッチ適用や稼働維持について心配する必要はもうありません。

00:10:04.720 --> 00:10:08.260
お支払いいただくのは、ワークロードを実際に実行する仮想マシンであるワーカーノードの分だけです。

00:10:08.400 --> 00:10:10.020
コントロールプレーン自体は無料です。

00:10:10.180 --> 00:10:12.140
これにより、状況は劇的に変わります。

00:10:12.300 --> 00:10:17.420
クラスターの保守に時間を費やす代わりに、チームは構築中のアプリケーションという真に重要なことに集中できます。

00:10:17.420 --> 00:10:21.600
ほとんどのチーム特にこれから始めるチームにとって、マネージドクバネテスが正しい選択です。

00:10:21.740 --> 00:10:24.880
運用オーバーヘッドなしで、クバネテスのすべての力を活用できます。

00:10:25.100 --> 00:10:27.480
AXE、Azureで実現するシンプルなクバネテス。

00:10:27.640 --> 00:10:29.580
では、AXEとは正確には何でしょうか?

00:10:29.700 --> 00:10:34.280
これはAzureのマネージドクバネテスサービスであり、ゼロから構築することなくフル機能のクラスターを提供します。

00:10:34.480 --> 00:10:39.020
前述の通りコントロールプレーンは無料ですので、ワークロードを実行する仮想マシンの分のみをお支払いいただきます。

00:10:39.020 --> 00:10:43.400
つまり、小さく初めて低コストで運用し、ニーズの拡大に合わせてスケールアップできるということです。

00:10:43.560 --> 00:10:45.660
Azureが面倒な作業のすべてを担います。

00:10:45.860 --> 00:10:49.740
コントロールプレーンのアップグレードパッチ適用、ヘルス監視はすべて対応済みです。

00:10:49.920 --> 00:10:53.960
システムを稼働し続けるためだけに、専任のクバネテス専門家チームを抱える必要はありません。

00:10:54.140 --> 00:10:59.200
また、AXEはAzureエコシステムの一部であるため、おそらくすでにお使いのツールと統合されます。

00:10:59.200 --> 00:11:05.200
認証のためのAzure Active Directory、ログとメトリックのためのAzure Monitor、ガバナンスのためのAzure Policyなどがあります。

00:11:05.380 --> 00:11:07.580
これらはすべて最初から連携して動作します。

00:11:07.760 --> 00:11:09.720
個別の部品を後付けする必要はありません。

00:11:09.900 --> 00:11:14.340
GitHub ActionsやAzure DevOpsを使ったCI、CD Pipelineの設定はわずか数分で完了します。

00:11:14.500 --> 00:11:21.260
リポジトリに変更をプッシュすれば、新しいコンテナイメージが自動的にビルドされ、Azureコンテナレジストリにプッシュされ、AXE上のデプロイメントが更新されます。

00:11:21.460 --> 00:11:24.220
手動の手順も、サーバーへのSSHログインも不要です。

00:11:24.420 --> 00:11:25.720
すべてが自動化されています。

00:11:25.940 --> 00:11:31.360
初心者向けには、AXEオートマチックモードがあり、クラスター構成に関するあらゆる決定を自分でしたくないチーム向けに設計されています。

00:11:31.560 --> 00:11:35.480
スケーリング、ネットワーキング、セキュリティ、アップグレードのためのすぐに使えるデフォルト設定を提供します。

00:11:35.660 --> 00:11:38.120
始めるためにKubernetesの専門家になる必要はありません。

00:11:38.120 --> 00:11:41.000
アプリケーションについて記述するだけで、残りはAXEが処理します。

00:11:41.160 --> 00:11:44.700
一つのコマンドでクラスターが作成され、一つのマニフェストファイルでアプリケーションが実行されます。

00:11:44.860 --> 00:11:47.700
AXEで習得したスキルは、どのKubernetes環境にも転用可能です。

00:11:47.860 --> 00:11:50.120
内部では標準のKubernetesが動いているからです。

00:11:50.300 --> 00:11:55.880
独自システムを学ぶのではなく、Azureが運用の複雑さを代行する本物の技術を学んでいるのです。

00:11:56.040 --> 00:11:57.880
これで全体像がつかめたはずです。

00:11:57.880 --> 00:12:07.100
コンテナはアプリケーションをパッケージ化してどこでも一貫して実行できるようにし、Kubernetesはそのコンテナを大規模にオーケストレーションして、デプロイ、スケーリング、復旧を自動的に処理します。

00:12:07.280 --> 00:12:13.200
AXEはコントロールプレーンを管理し、使い慣れたAzureツールと統合することで、そのオーケストレーションを扱いやすくします。

00:12:13.420 --> 00:12:14.400
要点はこれです。

00:12:14.520 --> 00:12:18.220
Kubernetesは巨大なエンジニアリングチームを抱える大手テック企業だけのものではありません。

00:12:18.360 --> 00:12:21.620
AXEのようなマネージドサービスがあれば、あらゆるチームが利用できるのです。

00:12:21.740 --> 00:12:23.520
今週の宿題はシンプルです。

00:12:23.660 --> 00:12:28.440
無料のAzureアカウントを作成し、AXEクラスターを立ち上げて、簡単なアプリケーションをデプロイしてみてください。

00:12:28.440 --> 00:12:31.780
わずか数分で、このプラットフォームがいかに進化しているかを実感できるはずです。

00:12:31.920 --> 00:12:33.180
もっと深く学びたいですか?

00:12:33.380 --> 00:12:38.660
次回のエピソードでは、最初のコンテナイメージを作成し、Azureコンテナレジストリにプッシュする方法を解説します。

00:12:38.840 --> 00:12:43.900
お気に入りのPodcastプラットフォームで登録し、Kubernetesを始めたばかりの仲間にぜひシェアしてください。