第22回 Tokyo Jazug Nightに参加しました
今宵の Tokyo Jazug Night は？
私は今年の6末頃に Azure のサブスクリプションを取得し、翌月の Jazug Night から参加させて頂いているのですが、毎月の定例行事となってきました。このイベントがある時は何が何でも仕事を切り上げます。笑
ちなみに、今宵は「Azure Bot Service」と「PowerApps」（＋CloudFlare様のショートセッション）でした。
次世代コミュニケーションツール「チャットボット」の活用
〜Azure Bot ServiceでAzureのことに何でも答えてくれるLINEボットを作る〜
サイオステクノロジーの武井様が登壇されました。サイオスさんのブログはインフラネタを調べている際に何かと参考にさせて頂いてたので中の方のお話を拝聴することができて良かったです！
本日の登壇内容も上記ブログにアップされているのですが、サイオステクノロジーさんのブログは基礎的なところを始めとして応用的な技術ネタも数多くアップされており、「これが無料なのか、イイ時代になったなぁ。」と感じます。
と、本題に戻りまして Azure Bot Service ですが、今流行のチャットボットを簡易的なものであればノンコーディングで作成できるとのことで。Teams や Slack にも連携可能とのことなので情シス的な目線としてはヘルプデスク的な要素はこれに投げ込んでしまおうかなと画策中。武井様も情シスにオススメ的なことをおっしゃっていたのでこの辺連携できれば情シス的にもユーザ的にも Win-Win な関係を築けそうです。
気になる価格としては代表的なチャネル（＝Standard）であれば無料？なようで、共に利用する Web App も検証用途であれば F0（Free） で大丈夫なようです。
あとは、Application Insights や Bot の核となる
・Language Understanding Intelligent Service（LUIS）
・QnA Maker API
でどれくらいかかるか、ということで。Bot に関しては Free または試用版で作成することも可能なようです。
本日のデモでは実際に拾えなかった質問内容を Application Insights で表示するという例があり、精度を上げるサイクルを見ることができました。結局はチャットボットも空振ってしまうだけでは意味のないボットになってしまうので精度を上げていくのは重要課題なわけです。（「分かりません」ばっかりやん！というツッコミが Application Insights で拾われていたのは笑いのツボでした。笑）
実際の構築内容はサイオステクノロジーさんのブログに上がっているので気になったキーワードのみ上げます。
・LUIS の API キー Authoring Key / Endpoint Key
➡前者はあくまでも開発用。本番用としては読み取り専用の後者を利用する。
・Composite エンティティ
➡複合エンティティのこと。グルーピングを利用することで複雑な文章も解釈できるようになる？
ひとまずは、一度手を動かしてみるのが早そうなので近々 Azure Bot Service を利用して簡易的なものを私も作成してみようと思います！
武井様は 2019/11 の Windows × WSL の記事を担当されているようで改めての宣伝です。Azure 絡みなので記事を読んでみようと思います。
Azure SQL DatabaseとPowerAppsでお手軽にアプリ開発！
～リレーショナルデータを高速に可視化！～
2本目は FIXER の横山様による登壇でした。PowerApps は最近かなり気になっていたので当セッションを拝聴できてとても勉強になりました。よくよく考えてみると今回は1・2本目共に（ほぼ）ノンコーディングでサービスを作成、ということに着眼した内容でした。
当セッションの内容としては Azure SQL Database と PowerApps を利用して簡易的な AZ 試験対策アプリを作成したという内容です。構想含めて3日少々？で作成されたようで、ハマったところを除けばもっと早くアプリが出来るかも？とのことでした。
気になったことのメモ。
➡2024年までにローコードツールがアプリ開発の65%に。この兆候となると、今後はよりアイデア勝負で勝ち抜いていくのかがカギとなりそうです。
➡Build の Keynote でナデラ氏が話した内容で「注力する4つのプラットフォーム」に Power Platform も含まれている。
➡ PowerApps はパワポのノリで画面作成できる。横山様は説明しつつハンズオンでサクサクと進めていました。確かに「こりゃ楽チンだ！」という印象を受けました。
➡ SubmitForm と Patch は重要キーワード
Twitterの「#jazug」を眺めていた感じでは AZ 試験対策アプリは「欲しい！」という声が多く、個人的にも AZ-900 以外で出来たら普通に欲しいアプリでした。笑
こちら、後日FIXERさんのブログあたりに上がる模様？なので、記事がアップされ次第、改めてお伺いしたいと思います。
と、本日は旬の2本のネタが拝聴できて、とても勉強になりました。
ちなみに、2本のセッションの後には CloudFlare さんのショートセッションがあり巷で噂の「1.1.1.1」の無料 DNS サービスに関する内容でした。
この数字の羅列を見ると Google の Public DNS である「8.8.8.8」が有名ですが、Cloud Flare さんの DNS はより安全により速く使うことができるとのこと。これも時間がある時に試してみようと思います！
Kubernetes（AKS）をやさしく学ぶ旅 その7
少し間が開きましたが・・・・。
その6 では Pod の少し詳細な部分に触れ、ReplicaSet をこれからハンズオンする、というところで完了しました。
今までに構築してきた環境をベースに ReplicaSet のハンズオンを行います。
ハンズオン Start！
まずは、ReplicaSet を「5」で指定（replicas: 5）したマニフェストファイルを準備して ReplicaSet を作成します。
xxx > kubectl create -f ReplicaSet/replicaset.yaml replicaset.apps/photoview-rs created
その後、Pod 情報を確認してみると・・・・。
xxx > kubectl get pod --show-labels NAME READY STATUS RESTARTS AGE LABELS photoview-rs-2mhpk 1/1 Running 0 8m26s app=photoview,env=prod photoview-rs-ghn9h 1/1 Running 0 8m26s app=photoview,env=prod photoview-rs-hpps2 1/1 Running 0 8m26s app=photoview,env=prod photoview-rs-m4fnl 1/1 Running 0 8m26s app=photoview,env=prod photoview-rs-sz5vb 1/1 Running 0 8m26s app=photoview,env=prod
この上で詳細情報（describe）を確認してみると・・・・。
xxx > kubectl describe rs photoview-rs （略） Replicas: 5 current / 5 desired （略）
正常に5つの ReplicaSet が作成されているようです！ちなみに、マニフェストファイルの「replicas: n」を変更すればそれに応じた ReplicaSet になります。ここで一度、ReplicaSet は削除してしまいますので、Pod もまとめて削除されます。
xxx > kubectl delete -f ReplicaSet/replicaset.yaml replicaset.apps "photoview-rs" deleted xxx > kubectl get pod NAME READY STATUS RESTARTS AGE photoview-rs-2mhpk 0/1 Terminating 0 15m photoview-rs-m4fnl 0/1 Terminating 0 15m xxx > kubectl get pod No resources found. ＊一度目の確認時にはまだ残っていたようです
クラスター内の制御はどう行っているの？
ReplicaSet のハンズオンを行ってみましたが、実際クラスター内で Pod を指定した数だけ起動するのはどのように行っているのでしょうか？これを制御しているのが「コントローラー」です。クラスターにおいて Pod が設定した数値になっているかを確認しそうでない場合は自動で修復を試みます。ちなみに、ReplicaSet は指定された数の Pod を起動するリソースではなく指定された数の Pod を起動した状態を維持するリソースです。（ここも本来はハンズオンがあるのですが割愛）
Pod に障害があった場合はどのような挙動になるの？
実際に ReplicaSet で Pod に障害が発生した場合はどうなるのでしょうか？挙動を確認してみます。
xxx > kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES nginx-pod 1/1 Running 0 2m25s 10.244.2.4 aks-nodepool1-11226562-1nginx-replicaset-8vchz 1/1 Running 0 77s 10.244.1.6 aks-nodepool1-11226562-2 nginx-replicaset-jzthk 1/1 Running 0 77s 10.244.1.5 aks-nodepool1-11226562-2 nginx-replicaset-lgmjf 1/1 Running 0 77s 10.244.0.8 aks-nodepool1-11226562-0 nginx-replicaset-mzfrw 1/1 Running 0 77s 10.244.2.5 aks-nodepool1-11226562-1
ここで、意図的にPod「
xxx > kubectl delete pod nginx-replicaset-8vchz pod "nginx-replicaset-8vchz" deleted xxx > kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES nginx-pod 1/1 Running 0 4m59s 10.244.2.4 aks-nodepool1-11226562-1nginx-replicaset-9k9q9 1/1 Running 0 17s 10.244.1.7 aks-nodepool1-11226562-2 nginx-replicaset-jzthk 1/1 Running 0 3m51s 10.244.1.5 aks-nodepool1-11226562-2 nginx-replicaset-lgmjf 1/1 Running 0 3m51s 10.244.0.8 aks-nodepool1-11226562-0 nginx-replicaset-mzfrw 1/1 Running 0 3m51s 10.244.2.5 aks-nodepool1-11226562-1
すると、「nginx-replicaset-8vchz」は消え「nginx-replicaset-9k9q9」が作成されます。ちなみに、IPアドレスも変わっております。終了した Pod に関しては再起動ではなく別途作成されることに注意しましょう。また、Kubernetes ではコンテナーアプリケーションを運用する際にステートフルなアプリケーションの場合、Pod の状態を保証できないため、その際は StatefulSet を利用する必要があります。（ステートフル＝クライアントのセッションを保持するもの）
Node に障害があった場合はどうなるのか？
Pod ではなく Node の障害の場合はどうなるのでしょうか？クラスターを構成するマシンが落ちた想定で進めてみます。
xxx > kubectl get node NAME STATUS ROLES AGE VERSION aks-nodepool1-11226562-0 Ready agent 62m v1.15.4 aks-nodepool1-11226562-1 Ready agent 60m v1.15.4 aks-nodepool1-11226562-2 Ready agent 61m v1.15.4 xxx > az vm stop --name aks-nodepool1-11226562-0 -g MC_AKSCluster_AKSCluster_japaneast About to power off the specified VM... It will continue to be billed. To deallocate a VM, run: az vm deallocate. xxx > kubectl get node NAME STATUS ROLES AGE VERSION aks-nodepool1-11226562-0 NotReady agent 64m v1.15.4 aks-nodepool1-11226562-1 Ready agent 62m v1.15.4 aks-nodepool1-11226562-2 Ready agent 64m v1.15.4 xxx > kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES （略） nginx-replicaset-lgmjf 1/1 Terminating 0 19m 10.244.0.8 aks-nodepool1-11226562-0（略）
タイムラグがありますが、「STATUS」列は「Terminating」になります。試しに「-0」だけでなく「-2」も落としてみました。
xxx > az vm stop --name aks-nodepool1-11226562-2 -g MC_AKSCluster_AKSCluster_japaneast About to power off the specified VM... It will continue to be billed. To deallocate a VM, run: az vm deallocate. xxx > kubectl get node NAME STATUS ROLES AGE VERSION aks-nodepool1-11226562-0 NotReady agent 68m v1.15.4 aks-nodepool1-11226562-1 Ready agent 66m v1.15.4 aks-nodepool1-11226562-2 NotReady agent 68m v1.15.4 xxx > kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES nginx-pod 1/1 Running 0 26m 10.244.2.4 aks-nodepool1-11226562-1nginx-replicaset-5vffm 1/1 Running 0 18s 10.244.2.12 aks-nodepool1-11226562-1 nginx-replicaset-9k9q9 1/1 Terminating 0 21m 10.244.1.7 aks-nodepool1-11226562-2 nginx-replicaset-fv8np 1/1 Running 0 5m43s 10.244.2.8 aks-nodepool1-11226562-1 nginx-replicaset-jzthk 1/1 Terminating 0 25m 10.244.1.5 aks-nodepool1-11226562-2 nginx-replicaset-lgmjf 1/1 Terminating 0 25m 10.244.0.8 aks-nodepool1-11226562-0 nginx-replicaset-mzfrw 1/1 Running 0 25m 10.244.2.5 aks-nodepool1-11226562-1 nginx-replicaset-s57gt 1/1 Running 0 18s 10.244.2.14 aks-nodepool1-11226562-1 ＊途中、「-0」をカバーして「STATUS」列が「ContainerCreating」のものも表示されました。
結果として、全てが「-1」に寄る形になっております。（負荷かかりそうですね。。）
ちなみに、「-0」と「-2」を Start として戻しても Pod が立ち上げた2台に配置されるわけではありませんでした。
ひとまず、ここで Pod は削除します。
負荷に応じて Pod の数を変える（ハンズオンなし）
Kubernetes はスケーラビリティが高いというところがメリットですが、2種類のスケーラビリティのキーワードを学びます。
・スケールアウト（水平スケール）
➡簡易的な説明として「台数を増やすこと」
・スケールアップ（垂直スケール）
➡簡易的な説明として「リソースを増強すること」
Pod で考える水平スケールとしては前述でマニフェストファイルを書き換えましたが、コマンドの発行でも可能です。「kubectl scale --replicas=n ～～」でOKです。
ちなみに、Kubernetes は、CPU使用率やそれ以外の各種メトリックを使用して、Pod の数をスケールすることが可能です。機能としては Horizontal Pod Autoscaler です。
ちなみに、当機能は ReplicaSet だけでなくその他の Deployment や StatefulSet 等にも利用が可能です。マニフェストに記述して実現します。
とまぁ、ハンズオン含め長くなってしまいましたが、前回の その6 と今回の その7 にてPod の詳細と ReplicaSet の動き等は完了とします！
Kubernetes（AKS）をやさしく学ぶ旅 その6
まだまだつかめない Kubernetes の世界。。
その1～その5まで紹介してきている Kubernetes ですが、まだまだ、色々と理解しきれていないところがあります。そこで、今回は Pod についてもう少し掘り下げてみようと思います！
Pod とは
以前の記事で Pod の大まかな部分は記述していますが、設計思想を含め、Pod はどう扱っていくのが最適なのかの細かな話はできていません。
コンテナーの世界では「1コンテナーで1プロセス」という鉄則があるようで、シンプルな機能をもつアプリケーションにすることが理想とされています。ただし、Web - Proxy、SSL、OAuth等、メインコンテナーに付随する1つのまとまりになったコンテナーを作るのが便利なようです。Kubernetes では関連するコンテナーの集合体を Pod と呼びます。また、Podの特性を下記に記載します。
・アプリケーションのスケールアウトは Pod 単位
・Pod 内のコンテナーはネットワークとストレージを共有
Pod のデザインパターン
Pod をどのように設計していくかは作成するアプリケーションの機能・非機能要件によります。
・同一 Node で実行する必要があるか？
・同じタイミングでスケールする必要があるか？
プロキシの役割をするコンテナー
元は HTTP にしか対応していない Web アプリケーションを HTTPS に対応させる場合です。
上記のケースの場合、SSL Proxy Container から本来の HTTP Web Application に対しては http://localhost/ でアクセスできるので既存の Web Application のコードに対して変更は不要になります。
認証処理を行うコンテナー
Web Application が OAuth 認証を必要とする場合は Web Application 本体とは分離して認証処理の Pod を配置する必要があります。
上記2例は以上にして、注意点があります。それは Kubernetes のデプロイの最小単位は Pod だということです。アプリケーションを今後拡張していく上で将来的にどうスケールしたいかがデザインパターンを決定する上で重要になります。Web Application において前段のフロントとバックのビジネスロジックは必ずしもスケールのタイミングが一緒ではない（可能性が高い）ため、Pod は別管理にした方が望ましくなります。
Pod のその他もろもろ
Node のスケジューリングも学ぼうと思ったのですが、ボリュームも非常に多いため、こちらでは割愛致します。ちなみに、ざっくりとした概略等は前回の その5 で記載しております。
ReplicaSet について学ぼう（ハンズオン前まで）
クラスターに複数の Pod をデプロイする、ということで Kubernetes のコンセプトである自己修復機能を実現するための ReplicaSet について学びます。
ReplicaSet はクラスター内で動作させる Pod の数を設定した数字で維持する仕組みです。Node 障害で Pod が停止した際には ReplicaSet を使用し自動的に新しい Pod を立ち上げます。
ハンズオンは その7 にして、少々短いですが今回はここまでとします！
Kubernetes（AKS）をやさしく学ぶ旅 その5
今回はハンズオンなしです
前回、割とガッツリなハンズオンだったので今回は要点を押さえた座学？形式でまとめようと思います。
Kubernetes の仕組みを覚える為の用語たち
スケジューリングとディスカバリー
スケジューリング
アプリケーションを適切なところにデプロイする仕組みで個別の要件に合わせたものをマニフェストファイルで定義しクラスター内サーバーに（独自アルゴリズムで）デプロイする。
サービスディスカバリー
デプロイされたアプリケーションがどこにあるかを見つけだす仕組み。Kubernetes とセットのキーワードで良く挙げられる「マイクロサービス」型のアプリケーションでは小さな機能を提供する多数のサービスで組み合わされシステムを作る。その際のサービス間のやり取りを担う。サービスディスカバリーの種類としては「固定IPアドレス」や「構成レジストリ」が挙げられる。
Kubernetesのサーバー構成
Master
Kubernetes のクラスター全体を管理する役割を担う。Master は etcd と呼ばれる分散キーバリューストア（KVS）を使ってクラスターの構成情報を管理している。
Node
コンテナーアプリケーションを動作させるサーバー群。通常は Node を複数用意して、クラスターを構成する。クラウドでは仮想マシン（VM）インスタンスが Node になることが一般的。
と、ここまでをまとめるとこんな感じです。
図のように Master の API がクラスター全体を制御します。
Kubernetes のコンポーネントたち
Master
API Server
Kubernetes のリソース情報を管理するためのフロントエンドの REST API。各コンポーネントからリソース情報を受け取り、データストアである etcd に格納する役目を持っている。他のコンポーネントは etcd の情報に API Server を介してアクセスし、開発者／システム管理者がこの API Server にアクセスする際には kubectl コマンドを利用する。
Scheduler
Pod をどの Node で動かすかを制御するためのバックエンドコンポーネント。前回のその4 計5つの Pod をクラスターで動作させましたが、Kubernetes 内部では Scheduler によって Pod の配置先を割り当てていました。
Controller Manager
Controller Manager は Kubernetes クラスターの状態を監視し、あるべき状態の維持に努めるバックエンドコンポーネント。
データストア（etcd）
Kubernetes クラスターの構成を保持する分散KVS。Key - Value型でデータを管理する。マニフェストの内容が保存されるイメージを持つとよい。
Node
Kubelet
Node では kubelet というエージェントが動作しており、Pod の定義ファイルに従ってコンテナーを実行したりストレージをマウントしたりする機能を持つ。
kube-proxy
さまざまな中継、変換を行うネットワークプロキシ。
Kubernetes のリソースたち
アプリケーションの実行
Pod
Kubernetesでは複数のコンテナーをまとめて Pod という単位として管理する。Pod は Kubernetes においてアプリケーションのデプロイの単位となり、Pod の単位で作成や開始、停止や削除などを行う。
ReplicaSet
ReplicaSetはクラスター内で指定された Pod を起動しておく仕組み。起動中の Pod を監視し、何かしらの理由で停止してしまった場合に該当の Pod を削除し新たな Pod を起動するようにする。
Deployment
アプリケーションの配布単位を管理するもの。Deployment は ReplicaSet の履歴を持ち、Pod 内のコンテナーのバージョンアップを行いたい時に停止することなくローリングアップデートできる。また、ロールバック（1つ前の世代に戻す）もできる。
DaemonSet
ReplicaSet で Pod を配置する際には Node の選択ができないものの、「各 Node に Pod を1つずつ配置する」といった場合には DaemonSet で要件を叶える。
StatefulSet
基本的にコンテナーアプリケーションはステートレスであるが、データベースなど永続データと連携する場合は状態を保持する必要がある。その際に利用するのが StatefulSet。
ネットワークの管理
Service
Kubernetes クラスター内で起動した Pod に対してアクセスするときは Service を定義する。
Ingress
クラスター外部のネットワークからアクセスを受け付けるためのオブジェクト。
アプリケーション設定情報の管理
ConfigMap
アプリケーションの設定情報や構成ファイル等の固有識別情報を Pod から参照できる仕組み。
Secrets
ConfigMap と同様に構成情報をコンテナーアプリケーションに渡すものだが、DBに接続するときのパスワード他、秘匿性の高い情報を管理するときに利用。
バッチジョブの管理
Job
1つまたは複数の Pod で処理されるバッチ的なジョブ。
CronJob
決まったタイミングで繰り返す Job の実行に使われるリソース。
マニフェストファイル
Kubernetes は宣言的設定を行うときにマニフェストファイルを使用します。
マニフェストファイルの基本
Kubernetes ではクラスター内で動かすコンテナーアプリケーションやネットワークの設定、バッチ実行するジョブなどのリソースを作成します。リソースの具体的な設定情報はファイルで管理しておりそのファイルがマニフェストファイルです。（YAML形式）
ちなみに、マニフェストファイルをクラスターに登録する際は kubectl コマンドを利用します。
$ kubectl apply -f webserver.yaml
クライアントから受け取った命令をベースに Kubernetes Master の API Server が構成情報である etcd に書き込みます。ちなみに、クラスターから削除する場合は その4 でも実行しておりますが下記のコマンドで実現できます。
$ kubectl delete -f webserver.yaml
ちなみに、マニフェストファイルの書き方は下記が参考になります。
YAML はインデントでデータの階層構造を表すのでインデントが正常な形式でないとエラーになるので注意しましょう！私はそこで少しはまりました。。
その他、、
他にも Pod の管理に最適なラベル設定やリソースをまとめて仮想的に分離する Namespace という機能がありますがこれ以上書くと長くなってしまうので今回は割愛します・・・・。
Kubernetes（AKS）をやさしく学ぶ旅 その4
読了した本を参考にハンズオンしてみました
以前、記事に掲載していた可能性もありますが、下記本の Chapter 02 にて環境準備を実施しその後、クラスターを作成していることが前提です。
xxx > az aks create --name AKSCluster --resource-group AKSCluster --node-count 3 --node-vm-size Standard_DS1_v2 --generate-ssh-keys --service-principal 5b2eaf2e-XXXX-4304-XXXX-16XXXX1dXXXX --client-secret XXXX7bef-c468-XXXX-827d-bc2XXXX7XXXX （略） xxx > kubectl get node NAME STATUS ROLES AGE VERSION aks-nodepool1-11226562-0 Ready agent 8m4s v1.13.10 aks-nodepool1-11226562-1 Ready agent 8m6s v1.13.10 aks-nodepool1-11226562-2 Ready agent 8m1s v1.13.10
また、クラスター作成前に ACR（Azure Container Registry） にサンプルWebアプリケーションをデプロイしています。この時点では Kubernetes クラスターではアプリケーションが何も動いていない状態です。
アプリケーションのデプロイをするには？
デプロイの基本的な流れを把握する為、以下3点を実施する必要があります。
（1）マニフェストファイルの作成
（2）クラスターでのリソース作成
（3）アプリケーションの動作確認
マニフェストファイルの作成
Kubernetesではクラスターにどのようにアプリケーションをデプロイするか、またユーザからのアクセスがあった際にどう処理するかをマニフェストファイルという設定ファイルに定義します。JSONまたはYAML形式で定義可能ですが可読性の面からもYAML形式が推奨されています。中身は省略しますが、サンプルでは自環境のACR名に合わせてYAMLファイルを編集しました。
クラスターでのリソース作成
作成したマニフェストファイルをもとに、Kubernetesクラスター上にアプリケーションをデプロイして動かしてみるところまでやります。前提条件の振り返りですが、クラスター作成自に「Standard_DS1_v2」サイズにてノードを3つ作成しております。ここでPodの状態を確認してみます。Podは「コンテナアプリケーション」の集合体でこの旅の その1 で図解にて解説しております。
xxx > kubectl get pod No resources found.
アプリケーションをデプロイしていないため、このような表示になります。そこで前述のYAMLファイルを apply すると？
xxx > kubectl apply -f .\tutorial-deployment.yaml deployment.apps/photoview-deployment created xxx > kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES photoview-deployment-79448db46b-7f44h 1/1 Running 0 3m34s 10.244.1.3 aks-nodepool1-11226562-0photoview-deployment-79448db46b-c7hrq 1/1 Running 0 3m34s 10.244.2.3 aks-nodepool1-11226562-2 photoview-deployment-79448db46b-l54sg 1/1 Running 0 3m34s 10.244.0.8 aks-nodepool1-11226562-1 photoview-deployment-79448db46b-pwzzj 1/1 Running 0 3m34s 10.244.0.7 aks-nodepool1-11226562-1 photoview-deployment-79448db46b-zcbjw 1/1 Running 0 3m34s 10.244.2.2 aks-nodepool1-11226562-2
状態に変化がありました。5つのPodが稼働状態ということが分かります。ただ、ここまでの状態ではクラスター外のネットワークからはアクセスできない為、もう1つのYAMLファイルを apply します。
xxx > kubectl apply -f .\tutorial-service.yaml service/webserver created
アプリケーションの動作確認
2つ目のYAMLファイルの apply を経て Service の公開が成されるため、アクセスのアドレスをこの時点で確認できます。
xxx > kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.0.0.1443/TCP 98m webserver LoadBalancer 10.0.86.185 40.115.159.202 80:32429/TCP 8m44s
イメージとしては下記のようになります。既に（1）と（2）は割愛している前提です。
ブラウザで確認してみると・・・・。
無事、アクセスできました！ロードバランサで割り振られ、「10.240.0.5」にアクセスしているようです。ちなみに前述の図を見るとアクセスできるPodは5つあります。F5で更新していくと・・・・。
同一のグローバルIPにアクセスしているにも関わらず、別のところにもアクセスしていることを確認できました。そんなこんなで確認が完了したのでリソース削除して今回は完了とします。
xxx > kubectl delete -f .\tutorial-service.yaml service "webserver" deleted xxx > kubectl delete -f .\tutorial-deployment.yaml deployment.apps "photoview-deployment" deleted
これを実施することにより、クラスターが空の状態になります。もちろんですが、Webアクセスしようとしてもアクセスできません。
以上です！
MSDN サブスクリプションで Azure のクレジットを有効化する
皆さん、特典を忘れていませんか！
MSDN に限った話ではないのですが、製品には特典がついていることってありませんか？しかも、特典がついているのを有効期限が過ぎてからハッと思い出すとか。。
Visual Studio の MSDN を購入するとエディションにもよりますが、Professional の場合は月で \6,000 分、Azure のクレジットが付加されます。以降で記載する手順は Business Center で会社のドメインの関連付けが完了しており、サブスクライバーを登録した後の話のみなので前提条件が完了していない場合はそこまで進行ください。
その手順
組織でサブスクライバーの登録を実施すると上記のようなメールが飛んでくるので「サブスクリプションにアクセスする」を押下します。その後はマイクロソフトアカウント等を入力し進むと「my.visualstudio.com」の個人ポータルに入ることができます。
［Benefits］（言語による）をクリックし Azure の［Activate］をクリック。
必要項目を入力していきますが、「アグリーメント」の2つ目のチェックに関してはつけなくても先に進むことが可能です。
処理が完了するとメールが飛んでくるので Azure にサインインします。
上記のようにサインインできて \6,000 のクレジット残があることを確認できます。ただし、あくまでも開発用のサブスクリプションなので本番用としては利用できません！詳しくは前述のリンクのページ下部「知っておく必要のある制限は他にありますか？」をご参照ください。
追記（Appendix）
2019/11/04
当記事の Azure クレジットの有効化は10月頭に行った記憶なのですが、本日該当のサブスクリプションを確認したところまたリセットされて \6,000 の残になっていました。
Microsoft Azure Training Day: Fundamentals に参加しました（＋受験しました）
どんなイベントだったか？
connpass経由で知ったイベントで、AZ-900 の講座にバウチャー付で受講できるということで即飛びつきました！ちなみに、今後も定期的に実施されるみたいです。マイクロソフトさんとしてはこれを皮切りに Azure を利用してくれる企業（人）が広がってくれることと、上位資格を受験してくれることを願ってこんな太っ腹なイベントを開催してくれているのかなと。（に違いない！）
東京方面の直近の開催は確認できる限り、10/23（水）が最短なようです。別途、更新はされるかもしれませんのでご確認下さいませ。
AZ-900 の位置づけは？どんな試験？
Azure の中でも入門資格であり、エンジニアの方ならずとも受験されている資格のようです。
Exam AZ-900: Microsoft Azure Fundamentals
Azure ならずとも、他のパブリッククラウド（AWS・GCP）を利用する上でも共通として習得しておきたい知識も当資格で吸収できます。ただ、それは全体の1.5～2割程度でそれ以外は Azure に関する知識と考えておいた方が良いです。
ちなみに、CBT（PC受験）形式です。現状では44問を60分で解答するというのがベーシックみたいです。難易度としては入門資格なので優しい方だと思います！
勉強法は？
基本的には事前に Azure のサブスクリプションを取得して触っておくと当イベントの話がスムーズに入ってくると思います。逆に触ってなかったり事前知識がないとスムーズに入ってこない、、かもしれません。ただ、サブスクリプションを取得していなくても Microsoft Learn で事前予習しておけばある程度のところまでいけます。
Azure の基礎ラーニング パス - Learn | Microsoft Docs
このモジュール自体が AZ-900 向けなので、この中身を一通り理解していれば合格へのラインがグンと近くなります。ちなみに私の場合は6末頃に Azure のサブスクリプションを取得してから少しずつ触っていました。体系だった形で受講して知識にしたかったのもあり、年内には当試験を受験しようと考えていました。
今回のイベントに関しては、後程の受験でもOKですし、当日合格する自信があればそのまま受験してもOK（ただし人数に限りあり？）でした。
当日受験の結果は？今後は？
700点が合格点で86X点（最後の1桁は忘れました。笑）だったと思います。朝からぶっ続けで受講した上での受験なので体力的に中々厳しいですが知識が新鮮なうちに受験できるという意味では大きいかなと。
本当は11月頃に受験予定で合格は早まったので上位資格をどうしようか考えつつ、関連する事項をブログへアウトプットできれば理想です。
あとは、会社自体（パブリッククラウド活用なし。。）のクラウド人口を、当イベントの布教も兼ねて広めていきたいです。
これに続くロゴを貼っていきたい・・・・。笑
追記（Appendix）
2019/09/30
当イベントの狙いと思われる記事を先日発見しましたので共有致します。
デジタル人材・組織の育成を社内外で進めるマイクロソフトの狙い - ZDNet Japan
社内外問わず、人材・組織の育成を図るようです。その取り組みの一環として「Microsoft Learn」も取り上げられていました。
【Azure Studies その13】Microsoft Learnをはじめてみる（最終更新日：2019-08-25） - SE（しがないエンジニア）のブログ
Kubernetes（AKS）をやさしく学ぶ旅 その3
ちょっとグダってました・・・・。
3連休、PC周りに触れたかったのですがなんだかんだでグダってしまい、寝落ちを3連発してました・・・・かろうじて日曜日、お昼に下記のイベントに参加したのですが、ブログにアウトプットできる程の文字起こしができなさそうなので頭の中にこっそりしまっておきます。笑
everyone-cyber-security.connpass.com
＊イベントとしては多角的なセキュリティのLTを聞けたので楽しかったです！
話は変わり Kubernetes の本題に（～アプリケーションの実行まで）
どんな切り口でAKSに入ればよいだろうとウロウロしていると下記のサイトを発見しました。
Azure Kubernetes Service (AKS) のドキュメント - チュートリアル、API リファレンス | Microsoft Docs
まずは、「5分間のクイック スタート」部分にて。今回は「Azure Portal」を利用することにします。（スクリーンショットは細かいものではなくざっくりとです）
説明に沿ってこんな感じで作成します。ひとまず、ノードサイズはテスト的なものなので「Standard B2s」のお安いものにしました。ノード数も今回は「1」で。その後に「次: スケール > 」を押下します。「スケール」ではそのままを維持して「次: 認証 > 」を押下します。
「認証」はこんな感じで。（表示された設定のまま）
以降の設定もそのまま進んで検証に成功するとクラスターを作成できます。デプロイが開始して私の環境では10分程かかりました。ちなみに、AKSの利用料金に関しては下記を参照下さいませ。
価格 - Container Service | Microsoft Azure
リソース移動後の詳細はこんな感じです。ここからはクラスターへの接続を行いますが、Azure Cloud Shell を利用します。
ポータル画面上部の検索ボックス右にある中のアイコンをクリックします。
私の場合は初回利用だったこともあり、ストレージアカウントの作成を求められました。
完了するとこんな感じです。ここからが実践になります。kubectlを構成するには「az aks get-credentials」コマンドを使用します。リソースグループ「resgr」の私の環境下では下記のコマンドです。
az aks get-credentials --resource-group resgr --name myAKSCluster
「Merged ～～」のようなメッセージがリターンされればOKです。その後にクラスターへの接続を確認する際は「kubectl get nodes」を入力します。
Azure:/ Merged "myAKSCluster" as current context in /home/xxxxxxxx/.kube/configr Azure:/ NAME STATUS ROLES AGE VERSION aks-agentpool-19xxxx23-0 Ready agent 24m v1.13.10 Azure:/
このような感じで入力したコマンドはクリアされ、リターンの結果表示されます。ここまででクラスターへの接続確認が取れたので続いてアプリケーションの実行を行います。接続確認が取れたパスにて説明の通りYAMLファイルを作成します。作成後は「kubectl apply」コマンドを使用してアプリケーションをデプロイします。
viで作成したファイル名 ➡ azure-vote.yaml
実行コマンド ➡ kubectl apply -f azure-vote.yaml
deployment.apps/azure-vote-back created.yaml service/azure-vote-back created deployment.apps/azure-vote-front created service/azure-vote-front created
アプリケーションの実行後は Kubernets サービスにとって（サンプル）アプリケーション フロント エンドがインターネットに公開される形になります。状況監視は下記のコマンドで確認可能です。（Ctrl + C にてブレイク可能）
kubectl get service azure-vote-front --watch
Azure:/ NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE azure-vote-front LoadBalancer 10.0.243.139 52.243.36.91 80:32401/TCP 6m45s ＊本来は「EXTERNAL-IP」部分は Pending から遷移します
「EXTERNAL-IP」が開放され、自PCのブラウザで確認してみると？
デプロイされたアプリケーションが表示されます！勿論、ボタンを押下してカウントされ、リセットも動作します。
おまけ（Azure Monitor での正常性の監視とログ）
前述のクラスター作成時にコンテナーに対する Azure Monitor が有効になっている状態です。監視機能に関しては説明を確認する限りでは AKS クラスターとクラスター上で動作するポッドの両方の正常性メトリックを提供してくれるとのことです。ちなみに、クラスターやポッドの概念に関しては既に上げている記事を振り返り下さいませ。
こんな感じの その1 です。
こんな感じの その2 です。
こんな感じの その3 です。
「azure-vote-front」コンテナーに対するログを確認したい場合は上記のような形で確認可能です。と、色々と閲覧することが可能です。
ちなみに、今回サクッとアプリケーションがデプロイできたのは既に準備されたコンテナー イメージを利用した為です。YAMLファイルでそれを指定しており、サクッとできたように見えただけです。笑
今回の「Kubernetes（AKS）をやさしく学ぶ旅 その3」では感覚を掴む為に前述リンクのクイックスタートを利用しました。次回以降はステップバイステップに進みつつ、その先は応用にスライドしていければイイな、と思います。
忘れずに検証のクラスターは削除！
今回の検証したクラスターはクラスターこそ課金対象ではないものの付随する各種リソースが課金対象の為、忘れずに削除するようにします。（自環境では10分少々で削除されました）
az aks delete --resource-group resgr myAKSCluster --no-wait
Azure:/ PS Azure:\> az aks delete --resource-group resgr --name myAKSCluster --no-wait Are you sure you want to perform this operation? (y/n): y Azure:/ PS Azure:\>
＊関連するすべてのリソースも削除されます
ご利用は計画的に・・・・。
追記（Appendix）
2019/09/22
この記事のあとに「その4」と「その5」を上げたのですが、ステップバイステップの手順「4」で詰まってしまった為、混乱の元となるので記事は 2019/09/22 2:20 頃におろしました。「その4」に☆を付けて下さった皆様、申し訳ありません・・・・。
「その4」の Appendix にも記載したのですが、クラスター作成時に「--node-vm-size」オプションを付加しないと割と良いVMになってしまうようで。私の場合は1日放置してお布施が跳ね上がりました。泣
結果、詰まった上にお布施だけ払う結果になってしまいました！（また、別の形で検証はしようと思います。。）
Kubernetes（AKS）をやさしく学ぶ旅 その2
その2です
前回は Kubernetes の触りの部分を記事にしましたが、まったり優しく行く為、今回もハンズオンはナシです。次回くらいから触っていこうと思います。
今回の題材としては Kubernetes を利用することによって何が変わるのか？そのメリデメを学ぼうと思います。
Kubernetes で変わること、メリデメ。
下記の方のスライドがとってもとってもまとまってます！超が10回つくほどオススメです。スライドの P38 にもあるように変わることは非常に沢山あります。「とりあえず、 Kubernetes にしましょう。」というレベルでないことは一目瞭然です。が、インフラのコード化によって個々のバラバラだった環境を全て Kubernetes 環境下においてコントロールできるようになるのは大きいメリットです。
＊はてブロで Slideshare をリンクするとこうなるんですね！ステキ。
メリット
ベロシティ（速度）
Web システムを例にとると1日に数度改善を入れる、ということもある昨今。新しい機能を開発してデプロイするスピードが求められる中、単なるスピードだけではなく信頼性の高いサービスである必要があります。すなわち、可用性も高めた上で運用できる環境を求められ Kubernetes は実現します。下記のような例で考えるとお客様の立場からするとシステムは止まらずに稼働し続けているように見えます。
【Legacy】Ver 1.0 -> stop -> Update!! -> start -> Ver 1.1
【Kubernetes】Ver 1.0 -> running -> Update!! -> running -> Ver 1.1
イミュータブル（不変）
Legacy の時は「ミュータブル」であり、設定変更・OSのアップデート・コンポーネントの追加等の積み重ねでシステムが構築されます。それに対して Kubernetes は「イミュータブル」であり、その積み重ねを「新しいイメージを作成」することでシステムを置き換えてしまいます。前者は変更の履歴を持たないのに対して後者は作成した方法を明示的に持っており（Dockerfile）障害時のリカバリとしてその履歴を利用できます。
宣言的設定
イミュータブルであることはクラスタ上でコンテナを動作させるだけなく、 Kubernetes に対してアプリケーションを記述する方法にもあてはまります。 Kubernetes上ではあらゆるものが、システムの望ましい状態を表現する宣言的設定のオブジェクトです。
自己回復するオブジェクト
Kubernetes はオンラインで自己回復するシステムです。現在の状態が望ましい状態に一致するよう動き続けます。初期化やシステムを不安定にするという信頼性に影響を及ぼしかねない障害からシステムを保護します。
マイクロサービスの構築に適している
導入として下記の Google の文献（マイグレーション）は参考になります。日本語です。
Legacy の際は「モノリシック アプリ」を指し多い人数（ここでは18人と想像する）で全ての機能を載せた1つの大きなシステムの集合体を開発しているとします。これに対して Kubernetes が得意とする「マイクロサービス」は機能A・B・Cを6人ずつの開発者で分け独立したシステムを連携した形で表現します。チームの人数が機敏性に優れることをはじめとし、以下のメリットもあります。
・モノリシックに対して個別に機能を切り出している為、スケール化しやすい。
・マイクロサービス毎に言語を変えることもでき、環境を柔軟に変えられる。
・他の機能との境界が明確であり、影響を及ぼしにくい。
Kubernetes はこのマイクロサービスを最適化する為、抽象化層や API を提供しております。（マイクロサービスの話に関しては前述の記事にも参考があります）
・前回の記事の Pod という概念
➡さまざまなチームが開発したコンテナイメージをグループ化しデプロイ可能とする
・Service がマイクロサービス間の分離の為にロードバランシングやネーミングなどの機能を提供する
・Namespace がマイクロサービス同士の連携範囲を制御できるよう、分離とアクセス制御を行う。
・Ingress が複数のマイクロサービスをまとめつつ、単一の外部からアクセス可能なAPIを提供したりフロントエンドを提供できる。
と、良いことづくめに見えますが・・・・。
デメリット（私感含めて）
一言でまとめると「ハードルが高く感じる」（≒入門レベルではない）です。概念含め理解するのには時間がかかりますし一筋縄で行かないところも多いと感じます。ただ、そこで挫折するのではなくトライアンドエラーを繰り返しながら設計・構築しナレッジを少しずつ積み上げることで最終的に得られるメリットを恩恵として受け取れれば良いのかなと思います。
また、上記のサイト内の記載にもあるように Kubernetes は全てのシステムに対して万能ではない為、活用するのに適したシチュエーションがあります。そこを見誤らない目を磨くためにもやはりナレッジを蓄積していくのは大事なのかなと考えます。
Kubernetes（AKS）をやさしく学ぶ旅 その1
Kubernetes をやさしく学びたい
「Kubernetes」と聞くと「コンテナ系のアレでしょ」（実に曖昧）という感じで結局のところ良く分かっていないので今回 Kubernetes を初学者として学ぶにはどうすれば良いのかな、と考えました。AKS（Azure Kubernetes Service）を題材に何度かに分けてアウトプットしようと思います。
ちなみに、これからのアウトプットの為に読了した書籍（Kindle）は下記の書籍です。
まず第一に・・・・。
「Kubernetes」てなんやねん！というところから。Google検索すると 2019/09/04 現在で「約 23,200,000 件 （0.51 秒）」ヒットすることから世間の関心の高さは伺えます。また、転職市場でも非常にもてはやされており、国内でいうとヤフーさんが募集してます。また、海外の転職市場でも求人の伸び率は凄いみたいです！
ヤフー株式会社／Kubernetesエンジニアの求人情報 － 転職ならdoda（デューダ）
Kuberenetesのスキルは、いま飛び抜けて米国の転職で有利。米Dice＆米Indeed － Publickey
と、前置きで話が逸れたのですが一言でいうと「コンテナオーケストレーションシステム」です。「オーケストレーション」という言葉をピックアップすると「複雑なコンピュータシステム／ミドルウェア／サービスの配備／設定管理の自動化を指す」用語のようです。ここで「コンテナ」とくっつけると Docker のようなコンテナの管理を自動化するという解釈になります。ちなみに、 Docker と Kubernetes がどうくっついていったかの経緯は下記サイトが非常に参考になります。
コンテナオーケストレーションツールの“事実上の標準”という座をつかんだ「Kubernetes」。その重要性とは？ | 新野淳一コラム | 東京エレクトロンデバイス株式会社
Kubernetes自体はGoogleが開発したものですが、GKSというマネージドサービスで提供されており、AmazonはEKS、AzureはAKSで提供しております。ちなみに Alibaba Cloud や Oracle Cloud も同様のサービスを提供しており、どのパブリッククラウドを利用（メジャーどころ）しても Kubernetes のマネージドサービスは利用できるといった状況です。
Kubernetes を利用するのであれば Docker の前提知識も
オーケストレーションシステム（Kubernetes）を利用するのであればそのベースとなるコンテナを知る必要もあります。下記サイトは Docker の説明から各種環境の構築まで計6回に分けて記事を掲載しております。
Docker入門 #1 【Dockerとは】 - Qiita
Kubernetesをおさえる上で知っておきたい単語たち
・Node（ノード のーど）
Kubernetes の本を読んでいる中で一番頻出の単語。仮想サーバや物理サーバを指す。後述の Pod を実行する為に必要なサービスを保持してマスタ構成要素によって管理される。ノード上のサービスには Docker／kubelet／kube-proxy を含む。
・Cluster（クラスター くらすたー）
Kubernetes のリソースを管理する集合体のこと。リソースには前述の Node や後述の Pod が含まれるがリソースで一番大きな概念が Node となる。Cluster は1つの Master Node と 複数の Node から構成される。
・Pod（ポッド ぽっど）
Pod はコンテナの集合体であり、 Pod はNodeの中で動作して1つ以上のコンテナを持っている。 Kubernetes にデプロイする場合は Pod 単位に行う。
まず、ここまでの単語を汚い（スミマセン）概念図で表すと下記のような感じです。
更に、、
・Container（コンテナ こんてな）
Docker コンテナのこと。
・Replica Set（レプリカセット れぷりかせっと）
同一仕様の Pod を複数生成する仕組み。
・Service（サービス さーびす）
Pod にアクセスするための経路を定義する。
・Deployment（デプロイメント でぷろいめんと）
Replica Set の上位リソースにあたり、Replica Set を管理する。Replica Set が Pod を管理・操作するのと同様、Deployment は Replica Set を管理・操作する。Replica Set の新しいバージョンのリリースを可能とし世代管理を行うこともできる。その為、ロールバック（巻き戻し）も可能。
図の黄色部分に関しては「こんな用語があるんだな」くらいで今はご認識頂ければ。今後はこの概念図や用語を基に話を進めていこうと思います。
