Microsoft Azure を学ぶ上で役に立ちそうなリンク集
From Microsoft より
Microsoft Azure
言わずと知れた Microsoft Azure の公式ページです。まずはココから。
Azureの最新情報をキャッチ
日々更新される Azure の情報をキャッチする際に便利です。特に終了系の記事に関しては要チェックです。（終了系は寂しいですが。。）
分からないときはここを参照
Microsoft Azure のドキュメント | Microsoft Docs
Docs サイトです。最近は本当にドキュメントが充実しており助かります。各機能の簡易的なチュートリアルも掲載されていたりします。
Azureのサブスクリプション（課金）を気にせず気軽に学びたいなら
Microsoft Learn | Microsoft Docs
当ブログでも何度か取り上げている Microsoft Learn です。レベル上げの要素があり、RPG感覚で楽しめるので一度で二度おいしい感じです。最近はもくもく会も各地に少しずつ広がっています。
設計図を作成する際のアイコン集
リンク先のzipファイルをダウンロードし解凍すると利用用途によって分かれたフォルダ群が表示されます。かなり豊富です。
セミナー系
Webinar で学ぶ
JAZUG (Japan Azure User Group)
今年で丸9年を迎えた老舗？Azure コミュニティ。基本は月1でイベントが開催されており、東京地区はイベント開催から僅かな時間で登録が埋まってしまう程の超人気。
前述の Microsoft Learn のもくもく会に関するコミュニティです。一緒にもくもくするなら同志の方と進めるのが楽しいですよね！
おまけでTwitterアカウントも
Daiyu Hatakeyama (@dahatake) | Twitter
マイクロソフトの畠山様です。AI（Data Scientist） をメインとし、ソフトウェアのアーキテクチャ関連の Tweet もお届けくださってます。
Toru Makabe (@tmak_tw) | Twitter
マイクロソフトの真壁様です。インフラからアプリまで何でもござれの凄いお方です。海外の Tweet も含め Azure の最新情報を展開してくださるので勉強になります。
Shinya Yamaguchi (@izuru_yamarara) | Twitter
マイクロソフトの山口様です。Azure Active Directory 関連の Tweet （Qiita記事）がメインです。また、エンジニアの成長に関する Tweet もつぶやいてくださってます。
他、下記のリンクより Microsoft MVP (Azure) 受賞者一覧のページに飛べるので Twitter のリンクがある方はフォローしてみてはいかがでしょうか？（2019/10/30 42人）
他、何かあればまた追記していきます！
Kubernetes（AKS）をやさしく学ぶ旅 その10
更にディープな Kubernetes を学ぶ旅へ
その9 まではハンズオンを交えつつ記事にしていきましたが、以降はドキュメントサイトを参考にしつつアーキテクチャを学んでいく記事にします。幸いなことに昔に比べるとマイクロソフトのドキュメントは充実の一途を辿っており、基本はドキュメント先を見るだけでも十分学べると思います。笑
押さえた方がよい（と思う）アーキテクチャに関して
Reconciliation Loops
読了した本の共著の方でもあるマイクロソフトの真壁様の登壇資料（超良資料です！）でこのキーワードのことを詳しく解説されています。全画面で閲覧することをオススメします。
ネットワーク
読了した本で参考例として記載されていたのは kubenet と Azure SDN の話がメインでしたが、リンク先には CNI（Container Network Interface） のことも詳しく記載されています。大事なポイントとしては Kubernetes では Node 間だけでなく Pod 間の通信も視野に入れたネットワーク設計が必要になります。
可用性
「可用性」はこの業界にいるとよく聞くキーワードですが「システムが継続して稼働できる能力のこと」を指します。以前の記事にも記載している通りで Pod のレプリカ数を2以上に定義すれば複数の Node に Pod を分散できます。また Pod が動作している Node が NG になった際の挙動に関してもハンズオンしてみました。
視点を変えて、Kubernetes 本体（の可用性）を考えてみます。Kubernetes のコントロールを司るコンポーネント群は主に Master サーバー上に配置されます。（例：API Server / etcd / Controller Manager / Scheduler 等）
特に etcd はクリティカルな要素であり、それを冗長化するために Master サーバーを冗長化することが重要です。
ただし、注意点として前述の例で挙げた前2つは冗長化した環境においてアクティブ／アクティブですが後2つはアクティブ／スタンバイとなります。
後ろ2つは API Server 経由でウォッチされており、状態維持に努めるため、他とのオブジェクト操作に競合を起こさないようにアクティブ／スタンバイとしております。
Master と同様、Node の可用性も同じ構成のサーバーを増やすスケールアウトがベースのアプローチなようです。他は分散数等を考慮したりします。
拡張性
Kubernetes のアドオンとして開発されている Cluster Autoscaler が Node の水平自動スケール機能を担います。機能として「Pod に割り当て可能な空きリソースがどの Node を見てもない場合に、Node を追加する。」・「Node 追加後にクラスターのリソース利用率が下がったら Node を減らす。」を持っております。判断基準は「Pending の Pod」があるかです。詳しくは下記をご覧下さい。
柔軟な拡張性を活かすことで突発的なアクセス増に対応することが可能（ただし、スケールアウトには仮想マシン作成と Kubernetes のセットアップが必要なため、予めアクセス増が分かっている場合は自動ではなく手動で増やした方がよい。）になります。また、その7 で挙げた Pod の水平自動スケールである Horizontal Pod Scaler も自動スケールの重要なキーワードです。リンクは当記事中部にも掲載しておりますが下記に再掲します。記事の下部です。
なお、Node の水平自動スケールと Pod の水平自動スケールは共存可能です。
今回はここで終了です。
Kubernetes（AKS）をやさしく学ぶ旅 その9
デプロイ方法を知ったあとは ConfigMap
アプリケーションの Deployment を知ったあとは、デプロイの世界からは少し離れたものを学ぶようにします。
アプリケーション内で利用する設定情報や外部へのAPIキーは環境に依存するため、アプリケーションのコンテナイメージで管理せず別方法で管理することが望ましくなります。これを実現するための解として Kubernetes では「ConfigMap」という仕組みが準備されています。
ちなみに、ConfigMap を作成する方法としては3つの方法が存在します。
1 ➡ Kubernetes のマニフェストファイルを作成
2 ➡ アプリケーションの config ファイルをマウント
3 ➡ kubectl コマンドから作成
1の作成方法に関しては前述の blog 記事でも記載されております。2の作成方法に関しては「kubectl create configmap」を利用する方法です。
また、ConfigMap の値の参照方法としては
・環境変数渡し
・Volume としてマウント
があります。前者の場合はマニフェストファイルの [containers] - [env] フィールドを利用（[valueFrom] - [configMapKeyRef]）します。後者の場合もマニフェストファイルには記載しますが [containers] - [volumeMounts] （[volumes] - [configMap]）フィールドの設定で ConfigMap をコンテナーのどこにマウントするか具体的に指定します。
つづいて Secret !!
一般的なアプリケーションは他システムの呼び出しで使用するAPIキー、データベースへの接続のための ID / パスワード等、機密データを扱います。その管理の際には Secrets リソースを使います。ConfigMap との違いとしては ConfigMap が何も暗号化されていないのに対して Secrets は etcd の中で暗号化された状態で管理される、といった違いがあります。
ちなみに、作成する方法としては2つの方法が存在します
1 ➡ Kubernetes のマニフェストファイルを作成
2 ➡ 機密情報のファイルをマウント
また、ConfigMap の際と同様に値の参照方法としては
・環境変数渡し
・Volume としてマウント
があります。同じですね。前者の場合はこれまた ConfigMap と同様ですがマニフェストファイルの [containers] - [env] フィールドを利用（Secrets の場合は [valueFrom] - [secretKeyRef]）します。後者の場合もこれまたマニフェストファイルに記載しますが [containers] - [volumeMounts] （[volumes] - [secret]）フィールドの設定で Secret をコンテナーのどこにマウントするか具体的に指定します。
今回はハンズオンなしとなりますが、環境依存する部分に関しては ConfigMap や Secrets で設定を保持する、と覚えておきます！短いですがこんなところで。
Kubernetes（AKS）をやさしく学ぶ旅 その8
アプリケーションのデプロイの観点から
Kubernetes には流行りの CI / CD を実現する上で重要なデプロイの機能を備えています。今までにキーワードとしては出ていないですがデプロイを管理する「Deployment」が便利です。
アプリケーションのバージョンアップの考え方として、「より安全（テスト済）に、より迅速に。」が重要です。そんな中でデプロイする手法として代表的なものは以下のようなものです。
ローリングアップデート
アプリケーションのバージョンアップの際にまとめて一気に変更せず、稼働状態を保ちながら少しずつ順繰り更新する方法です。ちなみに、更新中は新旧のアプリケーションが混在するため、ローリングアップデートに対応した仕組みになっている必要があります。
ブルー／グリーンデプロイメント
バージョンが異なる新旧2つのアプリケーションを同時に動作させておき、ネットワークの設定を変更して対応する方法です。ブルー（旧）とグリーン（新）を切り替えることからそう呼ばれます。
ブルーを本番としてグリーン側で機能追加したものでテストし確認できた上で切り替えます。万が一、アプリケーションに障害があってもブルーに切り戻せることがメリットです。
その他キーワードとして一部利用者のみに新機能を開放して問題ないことを確認した上で残りを大規模展開することを「カナリアリリース」といいます。
Deployment とは？
その5 でスケジューリングの話をチラッとしましたが、Pod をどの Node に配置するかはこのスケジューリングで実現します。クラスター上の Pod はラベルによって管理されており、バージョンアップの際にそのアクセスする Pod を変える、という制御を管理するのが Deployment になります。
ちなみに、Pod や ReplicaSet は履歴の概念がないのでリリース後に変更のないアプリケーションを管理するのに適しています。Deployment の場合は履歴の概念があります。すなわち、、
➡ Pod のロールアウトやロールバックができる
➡ ロールアウトの方式を指定したり条件や速度を決められる
アプリケーションの世界では一般的に「作成したらそれで終わり！」というものが基本は少ないため、Deployment の積極利用が勧められます。
ここからハンズオン
Deployment 用のマニフェストファイルを準備し進める形となります。
https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#deployment-v1-apps
xxx > kubectl apply -f Deployment/nginx-deployment.yaml deployment.apps/nginx-deployment created xxx > kubectl get deploy NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 3/3 3 3 21s
Deployment の作成と共に自動的に ReplicaSet と Pod もできあがるようです。
xxx > kubectl get replicaset,pod NAME DESIRED CURRENT READY AGE replicaset.extensions/nginx-deployment-789d949f8b 3 3 3 3m21s NAME READY STATUS RESTARTS AGE pod/nginx-deployment-789d949f8b-cq9mv 1/1 Running 0 3m21s pod/nginx-deployment-789d949f8b-hq4pg 1/1 Running 0 3m21s pod/nginx-deployment-789d949f8b-xbpf7 1/1 Running 0 3m21s
Deployment 名を元に ReplicaSet と Pod の名称がつけられていることが分かります。
xxx > kubectl describe deploy nginx-deployment （略） OldReplicaSets:NewReplicaSet: nginx-deployment-789d949f8b (3/3 replicas created) （略）
この詳細を確認するコマンド実行結果を見ると上記2つで履歴をとっていることが分かります。次に一度 apply したファイルの中身 [spec] - [template] - [spec] - [containers] - [image] の行を変更します。
xxx > kubectl apply -f Deployment/nginx-deployment.yaml deployment.apps/nginx-deployment configured xxx > kubectl describe deploy nginx-deployment （略） OldReplicaSets: nginx-deployment-789d949f8b (1/1 replicas created) NewReplicaSet: nginx-deployment-69fdb6677 (3/3 replicas created) （略）
再度 apply した上で確認すると、変化の途中を捉えたものですが、「789～～」が「69f～～」になっています。
xxx > kubectl get replicaset --output=wide NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR nginx-deployment-69fdb6677 3 3 3 7m26s nginx nginx:1.15 app=nginx-pod,pod-template-hash=69fdb6677 nginx-deployment-789d949f8b 0 0 0 21m nginx nginx:1.14 app=nginx-pod,pod-template-hash=789d949f8b
Deployment の場合は内部で ReplicaSet の履歴を持っており、Label 確認コマンドを実行すると「pod-template-hash」というのを持っていることが分かります。ここでお馴染みの delete を発行します。
xxx > kubectl delete -f Deployment/nginx-deployment.yaml deployment.apps "nginx-deployment" deleted xxx > kubectl get pod,replicaset,deploy No resources found.
Deployment の削除と共に紐付いている ReplicaSet や Pod も削除されることが上記で分かります。
Deployment のしくみ
Kubernetes では大分類として2つのアップデート方式があります。
1つ目は「Recreate」方式で旧 Pod を全停止した上で新 Pod をその名の通り再作成する方法です。何となく勘の良い方はおわかりだと思うのですが、これではダウンタイムが発生します。すなわち、ダウンタイムが許される開発環境などで使用します。
2つ目は前述もしている「RollingUpdate」です。こちらは「Recreate」と違い順繰りに変更していくため、新旧が混在するもののダウンタイムはありません。当方法はマニフェストファイル上では [strategy] - [type] で設定できます。明示的に指定しない場合は「RollingUpdate」になるようです。
再度ハンズオンに入る前に「ロールアウト」という言葉を覚えておきます。この用語はアプリケーションをクラスター内にデプロイしサービスを動作させることを指します。
xxx > kubectl apply -f Deployment/rollout-depoyment.yaml deployment.apps/rollout-deployment created service/rollout created xxx > kubectl rollout status deploy rollout-deployment deployment "rollout-deployment" successfully rolled out xxx > kubectl get pod NAME READY STATUS RESTARTS AGE rollout-deployment-fc7c7cbdc-78d29 1/1 Running 0 66s rollout-deployment-fc7c7cbdc-7wwhj 1/1 Running 0 66s rollout-deployment-fc7c7cbdc-8k5sh 1/1 Running 0 66s rollout-deployment-fc7c7cbdc-cwzc9 1/1 Running 0 66s rollout-deployment-fc7c7cbdc-k8mkw 1/1 Running 0 66s rollout-deployment-fc7c7cbdc-knjdj 1/1 Running 0 66s rollout-deployment-fc7c7cbdc-v2hx4 1/1 Running 0 66s rollout-deployment-fc7c7cbdc-w5n4f 1/1 Running 0 66s rollout-deployment-fc7c7cbdc-xbdfn 1/1 Running 0 66s rollout-deployment-fc7c7cbdc-zjwd6 1/1 Running 0 66s xxx > kubectl get service NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.0.0.1443/TCP 3d1h rollout LoadBalancer 10.0.160.142 40.115.182.229 80:32053/TCP 101s
Deployment だけでなく Service のリソースも作成されています。また、「kubectl rollout ～～」でDeployment の結果を確認できます。Pod は 10個 できており、外部からのアクセスIPは「40.115.182.229」といった状態です。アクセスしてみると？
アクセスできました。
xxx > kubectl describe deploy rollout-deployment Name: rollout-deployment （略） Annotations: deployment.kubernetes.io/revision=1 （略） Selector: app=photo-view Replicas: 10 desired | 10 updated | 10 total | 10 available | 0 unavailable StrategyType: RollingUpdate MinReadySeconds: 0 RollingUpdateStrategy: 25% max unavailable, 25% max surge ～～～～～ Pod Template: Labels: app=photo-view Containers: photoview-container: Image: sampleacrregistry999.azurecr.io/photo-view:v1.0 Port: 80/TCP （略） Conditions: Type Status Reason ---- ------ ------ Available True MinimumReplicasAvailable Progressing True NewReplicaSetAvailable OldReplicaSets:NewReplicaSet: rollout-deployment-fc7c7cbdc (10/10 replicas created) Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set rollout-deployment-fc7c7cbdc to 10
Deployment の概要が表示され「Annotations」行には「revision=1」があります。履歴管理のためのものでローリングアップに際して増分します。「Selector」行以降でローリングアップデート状況を確認できます。「Pod Template」行以降で Pod の仕様等を確認できます。
続いて その4 で ACR に登録した v2.0 を利用して挙動確認します。準備としてマニフェストファイルの一部を v1.0 から v2.0 に変更します。
xxx > kubectl apply -f Deployment/rollout-depoyment.yaml deployment.apps/rollout-deployment configured service/rollout unchanged xxx > kubectl get deploy NAME READY UP-TO-DATE AVAILABLE AGE rollout-deployment 10/10 10 10 28m xxx > kubectl describe deploy rollout-deployment Name: rollout-deployment （略） Annotations: deployment.kubernetes.io/revision=2 （略） Pod Template: Labels: app=photo-view Containers: photoview-container: Image: sampleacrregistry999.azurecr.io/photo-view:v2.0 （略） OldReplicaSets:NewReplicaSet: rollout-deployment-7bfc98cff8 (10/10 replicas created)
（略）
見比べてみると、「Annotations」行には「revision=2」となり「Image」行は「v2.0」となっております。また、Old と New の ReplicaSet も勿論変更されております。内部的な動作としては新しい ReplicaSet を作成してそちらの Pod を増やす、古い方の Pod を減らす、そして0になるまで続けるといった塩梅です。外見としては把握しにくいですが整合を取りつつ内部ではロールアウトしています。
では、次にロールバックを見てみます。マニフェストを当初の v1.0 に戻します。
xxx > kubectl apply -f Deployment/rollout-depoyment.yaml deployment.apps/rollout-deployment configured service/rollout unchanged xxx > kubectl describe deploy rollout-deployment Name: rollout-deployment （略） Annotations: deployment.kubernetes.io/revision=3 （略） Pod Template: Labels: app=photo-view Containers: photoview-container: Image: sampleacrregistry999.azurecr.io/photo-view:v1.0 （略） OldReplicaSets:NewReplicaSet: rollout-deployment-fc7c7cbdc (10/10 replicas created) （略）
「Annotations」行には「revision=3」となり「Image」行は「v1.0」となっております。その上で Old と New 行なのですが、「revision=1」の際の英数文字の羅列に戻っております。revision こそ進んでいるものの内部の履歴を参照しロールバックをしていることが分かります。
また、ロールアウトは条件として Pod のテンプレートを変更したときのみ行われます。一通りの動きが分かったので削除します。（コマンドは割愛します）
ローリングアップデートの制御に関して
describe のコマンド結果にも表示されていましたが、使用できない Pod の制御として「maxUnavailable」の指定、クラスターで Pod を作成できる最大数として「maxSurge」を指定できます。共にデフォルト値は 25% です。こちらのマニフェストファイルの変更のハンズオンは割愛します。
実際には前述している「ブルー／グリーンデプロイメント」もハンズオンしようと思ったのですがここまでにたっぷりと触れてしまったので その8 はここで打ち切り（笑）にします。
ざっくりとした内容としてはブルー用（旧）のマニフェストファイル v1.0 とグリーン用（新）のマニフェストファイル v2.0 を準備し共にクラスターへデプロイします。apply 方法はいつもと変わりありません。3つずつ Pod がある想定で計6つ Pod が共存する形になります。
これに加え外部からアクセスする際の Service マニフェストを作成する際に v1.0 へ向けるようにするとブルー用（旧）へ向く形となります。v2.0 での確認を一通り終えたところで Service マニフェストを v2.0 へ向けるようにすれば当デプロイメント完了です！
解散！
第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 の動き等は完了とします！
MOTEX DAYS 2019 ユーザー事例発表会に登壇させて頂きました
かれこれ 3～4 ヶ月前のこと
MOTEX社様と打ち合わせをする機会がありまして、打ち合わせの中で登壇のご依頼を頂きました。弊社を担当して下さった営業さんは実は前職でも担当して下さってた経緯もあり、そんなこんなの縁での依頼でした。縁って大事ですね。
去年頃に同じ依頼を受けていたら実はお断りしていたかもしれません・・・・が、今年はこのブログでのアウトプットを始めとして、「色々なことに挑戦したい！」と決めた年だったので依頼を受けました。
資料作成～当日登壇前
資料作成自体はMOTEX社様が流れのテンプレートを作成して下さってたので叩き版自体、割と早いタイミングで完成しておりました。社内で数度レビューした後に実際に修正の上、模擬プレゼンも数度行いました。ちなみに、持ち時間は20分だったのですが、一度目の練習は25～30分近くかかってしまってました。笑
当日も付き添ってくれた上司の方と数度模擬練習を行った上で最終的には20分ちょっとまで縮んだのであとは本番で微調整しながら、という感じで臨みました。
当日の行きは品川まで新幹線だったのですが、乗った車両でまさかのライバル会社の宣伝が！しかし、今日の藤原君は応援するかのような視線を送ってくれているようにも見えました。（100.1%違う）
ココが事例発表会が開催された品川インターシティホール。ドキドキ。しているうちにリハーサルが始まり、基調講演が始まりと自分自身の出番が近づいてきました。。
登壇（本番）
予定通り、持ち時間20分を頂いてスタート。ほぼほぼ予定通りの流れで本筋の話とおまけ的な話も出来ました。聴講してくださった方はMOTEX社様の社員の方々も合わせて50人程でした。冒頭でもお話したのですが他のセッションが割と注目のキーワードだった中、当セッションにお越し頂き、誠に有難う御座いました！
初登壇でよかったこと・悪かったこと
よかったこと
・発表時間が予定通りの20分程で完了できたこと（ほぼニアだったかと）
・原稿らしい原稿は用意せず、練習通り、自然体で話せたこと。
・初志貫徹で決めたこと（極力技術寄りにならず平易に話すこと）を実践できた
悪かったこと
・作成したパワポが自社テンプレートでフォント埋め込みだったことを忘れていたこと。結果、大きなズレはなかったものの失態です。。
・プラスして一部のスライドのオブジェクトが大幅にズレていたこと。結果、登壇前に修正できたので良かったですが、振り返ればPC持ち込みにすれば解決した気がします。
・途中咳払いしてしまった、後半少し声が枯れてしまった。
➡ちゃんと水分を取っておくべきでした・・・・。
とまぁ、あっという間に発表は終わり、その後のセッションを拝聴しMOTEX社様と懇親を深めつつ、帰路につくのでした。ちなみに、以前のブログ記事で記載した3つのポイント（セキュリティの重要性を伝える・同業者の方と繋がる・コミュ障を克服する）は大方達成できたのかなと思うので満足です！
御礼
まずは今回の会がMOTEX社様の力なくしては開催されなかったこと、このようなイベントで登壇させて頂きまして、誠に有難う御座います。また、会が行われる中でお会いしたことのある社員の方々とコミュニケーションを取ることができて非常に嬉しかったです。
続きまして、前述もさせて頂いておりますがセッションに足を運んでくださいました皆様。拙い点が多々ありお聞き苦しかったとは思いますが、最後までご静聴頂きまして有難う御座いました！
最後におまけのような感じではありますが、午後帯一杯、終始おつきあい頂いた弊社の上司の方にも心から感謝しております。
Next LanScope？
事例発表の場には立たせて頂いたのですが、弊社もまだまだ LanScope Cat を活用してやりたいことが多々あります。スライドにも盛り込んでいたライセンス管理・セキュリティパッチ適用の平準化・MDM・Cylance Protect などなど。
LanScope An を利用していることもあり、MDM強化のため、「Syncpit」は導入したいなと考えております。ビジネスチャットの普及も後押ししていると思います。
また、マルウェア対策を強固にするため、CylancePROTECT の導入も考えたいです。特別講演で拝聴しましたが、他社の有名な製品と比べても見劣りしない、むしろ、（ほぼ）完全無欠の状態に引き上げることができます。
製品自体への「愛」を含めて社内のセキュリティレベルを上昇させたいです！！！！！
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 にして、少々短いですが今回はここまでとします！
DevRel/Beginners #6 に参加しました
DevRel とは？
10/11（金）に関連セミナーに参加しました。当セミナーの主催者はMOONGIFTさんという方、実は業務中にも色々と参考にさせて頂いていたWebページの管理者の方だったので驚きでした。笑
話を戻し DevRel ですが一言でいうと Developer Relations で自社製品やサービスと開発者の良好な関係性を築くためのマーケティング施策となります。
セミナーで得た気付き メモ編
内容が盛り沢山（＋ワークショップ）だったので抜粋して記載致します。
なぜ、DevRel というものが存在するのか？というのは「認知度の向上を目指す」これに尽きます。マインドシェアを上げ、自社製品（またはサービス）を土俵に上げてもらうことが重要です。
その上でなぜ開発者にリーチするのか？という点に関しては「調査するのが面倒だから」これに尽きます。開発者は広告を嫌う傾向があるようでリテラシーも高いです。そうとなると、直接開発者に知ってもらう機会が必要になります。かつ、ソーシャルやブログ保有率が高いこともあり、情報の拡散を狙える一面もあります。
しかし、DevRel の活動を行う上で注意する点もあります。それは「すぐに効果が出ない」ということです。あくまでも中長期的な戦略として実施する必要があり、その先の KGI / KPI は明確に定めておく必要があります。（ただし、KPI は水増ししないものを。）
ちなみに、DevRel 界隈にも超有名な方がいらっしゃって「ガイ・カワサキ」さん（元Appleのエバンジェリスト）は講演して頂くとなるとその額もスゴいんだとか。それ程、DevRel の開発者に向けての影響度というのは重要なのでしょう。
ちなみに、DevRel を行う目的としては「採用に繋げるためのもの」か「自社製品を良く見せるか」で大分され、日本で前者の企業として有名なところでは DeNA や クックパッドがあげられます。これに関してはどちらが良い悪いというのはないようです。
日本でも（特に）大きな企業から広まりつつある DevRel ですが海外は本質でもあるマーケティングが進んでいるというところもあり、日本はこれから追いついていくといったイメージでした。ただ、日本も決して遅れているわけではなくコミュニティ形成他進んでいる部分もあるそうです。ちなみに、海外の事例はそのまま日本では使えないので日本風なアレンジが必要とのことでした。
セミナーで得た気付き 実践編
セミナーは座学だけでなくところどころワークショップのようなものが入りました。中には時間の関係上、割愛されてしまったものもありましたが、実際の DevRel 活動に役立ちそうなものが多かったのでセミナー資料を元に後程振り返りたいと思います。
自社の DevRel は直接収益型？間接収益型？
下記ページが参考になります。
DevRelの取り組みを分ける三つの価値 | DEVREL - 開発者向けマーケティング支援サービス -
自社製品のターゲットは国内・世界どちら？
それぞれのターゲットの違い、人的・市場的なものを理解していますか？それぞれのターゲットに向けた戦略は用意されていますか？というものでした。
また、自社分析をする上で有名な SWOT 分析をするのはオススメとのことでした。
DevRelにおける戦略の立て方、考え方 | DEVREL - 開発者向けマーケティング支援サービス -
上記ページはセミナーで習ったことの多くのエッセンスが詰まっているので是非是非閲覧した方が良いと思います！
セミナーで得た気付き その他編
DevRel の施策の決定
ローリスクでハイリターンの追求が必要だそうです。かつ、時間のかかる施策はなるべく予算をかけずに続けるのが重要とのこと。登録したらプレゼント系に関しては一時的にユーザを惹きつけるものの、その後が続かないのでオススメしませんという話でした。ココはキモであり、難しそうです・・・・。
ブログは Q & A 記事で書くのがオススメ
これは話を聞いて納得しました。言われてみると自分自身も眺めるブログ記事の大半は Q & A 記事で、かつ、結論にいかに早く辿り着けるものに惹かれる傾向があります。
セミナーに参加して結局自分はどうするのか？
まだまだ、DevRel 初心者ということもあり、何から手をつければ良いのか、というところではありますが、「もっと自社製品を多くの人に知ってほしい」・「もっと自社のことをより多くの人に知ってほしい」という気持ちは強まりました。現職はまだ2年半ということもあり、まずは自社をもっと勉強した上で施策を練って行かなければなぁと感じます。
今年は connpass を始めとしたセミナー参加、事例発表会の登壇等、外部の方との交流が増えた一年でした（まだあと2ヶ月くらいありますが）が少しずつ自社・自分自身を知っていって頂き本格的な DevRel 活動に繋げていきたいと思う所存です。m(_ _)m
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 という機能がありますがこれ以上書くと長くなってしまうので今回は割愛します・・・・。
