Japan Azure User Group 9周年イベントに参加しました

こんにちは、サイオステクノロジー技術部武井です。

本日は、日本では最大のAzureユーザーコミュニティであるJapan Azure User Group(JAZUG) 9周年イベントに参加をしてまいりました。

同時開催で、マイクロソフトのてらだよしお氏が、Azure上でKubernetesを実行できるマネージドサービス「Azure Kubernetes Service」(以降、AKS)のイロハについて、実際に手を動かしながら解説するというイベントもあり、私はこちらの方に参加しました。

アプリケーションのビルドやDockerのイメージ作成という、開発における初期のフェーズから実践してらっしゃいましたので、実際の現場での、リアルな開発の流れをイメージすることが出来たという点で、非常に参加した意義がありました。

そして、AKSに必要な細かいTIPS(例えばDockerのマルチステージによるビルド環境と実行環境の分離など)がたくさん紹介されており、それらがかなり実践的な内容でしたので、現場で導入したときに、最初につまずきそうな部分は既にクリアした状態でスタートできそうな気がしました(^o^)

また、Kubernetesの論理的な構成(Podとnodeの関係など)の解説もあり、Kubernetesの全体的なイメージを把握することも出来ました。ハンズオンや構築手順の解説などでは、木を見て森を見ずのように、いきなり詳細な構築手順から入ってしまって、イメージを掴むことが出来ず結局ワケガワカラナイヨ的なことが多々あるのですが、今回のセミナーでは、全くそういったことがなく、構築手順はもちろんのこと、全体的なイメージもきっちり抑えることが出来ました。

エンジニアとしての心意気を語られたエモい話もあり、元気出ましたー(^o^)「技術への愛が人生を豊かにする」は名言でございます。

セッション中の資料は以下のURLにあります。

https://github.com/yoshioterada/k8s-Azure-Container-Service-AKS–on-Azure

以下、メモ書きみたいですみませんが、聞いてよかったなと思ったことです。

Dockerのマルチステージビルドにより、ビルドイメージ用コンテナと、実行用コンテナに分けて、イメージを小さく作成することが大事
Azure上でJavaで開発するときはzuluを使えばLTSが受けられる。
AKSを作る方法はGUIとCUIがある。CUIでしか出来ないこともあるので、そちらのほうがオススメ。例えば、GUIで作ると最大30個のPodしかできないけど、CUIだと110まで作れるなど。
複数のクラスタの切り替えは、kubectxで一発
Istioはコンテナの世界にAPOを持ってきたもの
- Istioを使うとPodの中にProxyというコンテナが入ってくる
- PodへのアクセスはProxyを経由するようになる。
- Proxyにログの処理とかメトリクスを取りたい場合Proxyにやればいい。コンテナ単位に実装しなくていい。
Podを作成する際、CPUとメモリのリソースは指定する。PodはVM上で動作しており、VMの限られたリソースを使うので、リソースを指定しておかないと、VM自体がダウンし、他のPodにまで影響が及んでしまう。
- resourecesのrequestsは必ず指定する1コア=1000mなので、VMのコア数が2コアだったから各Podのrequestsの合計値が2000m以下になればいい
selectorを使ったBlue-Green Develoymentを行うと幸せになれる。
DockerHubのイメージをむやみに信じないこと
- Officialなイメージは安全して使用することができる
- 一般人が作ったイメージを作る場合は、コンテナのセキュリティをチェックしてくれるようなサービスを使うこと
k8sはバグだらけ
- stackoverflowで英語で調べよう
複雑な運用構成を作らない。無理してk8sを使わない。適材適所が大事。App Serviceでも十分な場合がある。
aksを利用するかどうかを判断するためには次のURLを参考にする → https://yoshio3.com/2019/07/20/appropriate-choice-of-k8s-environment/