Kubernetes が普段使いの人のための CKAD 対策の話

この記事は cloud.config tech blog にもマルチポストしています。

tech-blog.cloud-config.jp

はじめに

Kubernetes を普段業務で使っている方で、業務で培った技術力の証明のために CKA(Certified Kubernetes Administrator)や CKAD(Certified Kubernetes Application Developer)といった資格を受験したいと考える方っていると思います。
実際普段から Kubernetes を触っている人がこれらの受験しようとすることは試験に合格しようとする上では Docker やコンテナ等の前提知識が備わっている点や試験内容である実際にコマンドラインで問題を解くという点において大きなアドバンテージになります。
しかし、一方で試験の形式や問題を受ける場面は普段の Kubernetes を用いた運用や開発を行う場面と大きく異なっている点もあります。
例えて言うならば、普段業務で Kubernetes を使うことはそれなりに力を使うので仕事をしているだけで筋肉が鍛え上げられていくのですが、試験では仕事で使うのとは違う筋肉を使うこともあるようなイメージです。
なので、試験を受ける場合はそちらで使うことになる筋肉も鍛えておかなければならないのですね。
今回は、Kubernetes 系資格の中でも特に CKAD において普段から Kubernetes を業務で使っている人向けに受験に向けた学習のコツのようなものを共有できればと思います。

できる限りコマンドでリソースを作成、操作する

普段 Kubernetes を用いて業務を行っているとき、アプリケーションを展開するときにはまずマニフェストファイルを作成してそれを kubectl apply -f <ファイル名> のようなコマンドで展開しているかと思います。
アプリケーションの kubernetes へのデプロイはできる限り宣言的な方法でコードで記述した方が分かりやすく、管理もしやすいためです。
一方で、この CKAD という試験は、試験の内容でも書いたとおり、この試験の制限時間は 2 時間でその間に 15~20 問の問題を解かなければなりません。そのため、1 問にかけられる時間は 6~8 分になります。
そんな中で、ある程度複数の概念が組み合わさったようなリソースを展開しなければならなくなった場合、いくら公式ドキュメントが参照できると言っても、マニフェストを作成して適用する方法だと以下のような手順を踏むことになります。

1. Pod リソースを kubernetes ドキュメントで検索する
2. Pod リソースのマニフェストのサンプルを vi にコピペしてくる
3. サンプルマニフェストの余計な部分を削除し、Pod 名、イメージ名等を書き換える
4. 個別の概念(livenessProbe とか env とか)について調べてマニフェストのサンプルを探す
5. それぞれの概念のマニフェストのサンプルを vi にコピペしてくる
6. 適用

この方法だとさすがに、1 問を解くのに時間がかかりすぎてしまいます。
なので、できる限り kubectl コマンドでリソースを作る方法を覚えるべきです。
例えば、イメージだけを指定した簡単な pod を作成したい場合は以下のようなコマンドだけで一発で Pod を作成できます。

kubectl run <podの名前> --image=<image名>  

このコマンドを覚えて使うことは、マニフェストファイルの内容を丸覚えしていたとしてもそれを vi で記述してkubectl applyしたり、あるいは忘れていた場合は kubernetes の公式ドキュメントで Pod リソースのページを開いてマニフェストのサンプルをコピペして余計な部分を消してリソース名とイメージ名を修正してそれからkubectl applyしたり・・・なんてするよりはずっと早いです。
このようなリソースの展開方法をドキュメントではImperative Commandsと呼んでいます。
これを習得しましょう。
一応この方法にもデメリットがあり、それはこのコマンドの引数だけでは設定できない部分もあることです。
例えば kubectl run コマンドだけでは作成する Pod に対する livenessProbe や ReadinessProbe の設定ができません。
他にも、ConfigMap リソースから env を引っ張ってくる等の設定もkubectl runコマンドだけでは行えません。
これらはマニフェストファイルにパラメータを設定することでしか設定することができません。
では Imperative Command は実際の試験で使えないのかというとそんなこともないです。
例えば、先程のそこそこ複雑な要件の Pod を作成する例で例えると、Imperative Command を使うと以下ただ、な手順になります。

1. kubectl run <pod名> --image=<image名> <その他色々、オプションで設定できる限りの設定を行う> --out-put=client -o=yaml > <ローカルに作成するファイル名>のコマンドを実行する
2. 個別の概念(livenessProbe とか env とか)について調べてマニフェストのサンプルを探す
3. それぞれの概念のマニフェストのサンプルを vi にコピペしてくる
4. 適用

1 番のコマンドについては追加で説明するべき点が 3 つあります。
一つは、--out-put=clientのオプションの部分で、これによってコマンドの実行を実際には行わず、コマンドを実行した場合どのような結果になるかだけを取得します。
二つ目は、-o=yaml の部分です。これは、コマンドの実行結果を yaml 形式で出力するものです。pod を作成するコマンドにこのオプションを実行すると、yaml 形式で表現された Pod の情報が出力されます
この出力をコピペしてマニフェストを生成すると、適用するとコマンドで生成するのと同じリソースが作成できます。
三つめは、リダイレクト>です。ご存知の方はご存知かと思うのですが、これで出力結果をそのままファイルに出力できます。
これらを行うことで、マニフェストを 1 から作る際の手順の 1~3 を省略することができ、時間も大きく節約できます。
戦術としては、Imperative Commands で設定できる限りの設定をオプションで行い、それで設定しきれない部分についてはマニフェストに吐き出して個別に調べて設定、適用するというような形になります。
Imperative Command で設定できる項目については、kubectl コマンドのリファレンスに載っているので、試験に備えてブックマークしておくのであればここはマークしておくべきかと思います。
CKAD は制限時間がタイトな都合上、Imperative Commands を使いこなせるようになることがほぼほぼ必須なところがあります。
ぜひ覚えましょう。

普段あまり使っていない分野の学習に集中する

普段 Kubernetes を触っている人が CKAD のような試験の学習をすることは、それらを全く触っていない状態から学習を始めることよりははるかに初期の知識において優位にあるかと思います。
学習の方法としては様々な他の人が書いているようにCKAD-excerciseや udemy コンテンツのKubernetes Certified Application Developer (CKAD) with Testsあたりが有名どころですが、これらのコンテンツの全体を同じ濃度でやるよりは、自分の弱点になっている分野を重点的に学習した方が有利です。（当たり前といえば当たり前）
普段触っていても忘れていたり知らなかったりする部分を学ぶために一周は全体を流しても、二週目は普段触っていなかったり各種サンプル問題を解いてみて分かりづらかった部分を重点的に学習するのが効果的です。
自分の場合は Security Context や Volume 周り、NetworkPolicy 周りが弱かったのでその周りを集中して学習しました。
また、2021 年の試験の更新で試験範囲に helm も加わったため、そこも重点的に学習しています。

コマンドラインでのファイル編集には慣れておく

普段業務でマニフェストを触る時、コマンドラインで扱える vi 以外で編集を行っている人も多いと思います。
ただ、CKA/CKAD 本番では試験を受けるためのブラウザのタブとドキュメント確認用のタブを一つ開くことだけを許されているので、マニフェストファイルなどのファイル編集になれておく必要があります。
自分の場合 vi を使うことにしたのですが、普段そこまで vi 操作になれていなかったので自分用のショートカット集的なものを作って学習中はちょくちょく読み直していました。
自作のよく使うショートカットは以下の 4 つでした。

's,'ed  
vi中でms,meコマンドを打ってマーク付けした間の行を削除(マークは目立つ形では表示されない)  
  
's,'ey  
vi中でms,meコマンドを打ってマーク付けした間の行をコピー(マークは目立つ形では表示されない)  
pキーでペースト  
  
u  
アンドゥ  
  
dd  
１行削除  

おわりに

ちなみにここまで対策を書いておいてなのですが、実は試験はまだ受けていません。来週あたりを予定しています。
こういった記事は合格してから書けよという話ですが、最近この辺りの話を周りの人とする機会ができたためそれに合わせて先に書いています。
ここまで書いておいてもし受験して落ちたりしたら、その時は笑ってやってください。

3/23 追記
その後、無事合格しました。

CKAD受かったたった

— なむゆ (@namuyuy) 2022年1月21日

ついでにCKAも取得しました。

CKA受かりました
やったね

— なむゆ (@namuyuy) 2022年2月21日

参考

• Managing Kubernetes Objects Using Imperative Commands
• kubectl のコマンドリファレンス
• CKAD-exercises
• Kubernetes Certified Application Developer (CKAD) with Tests

AKS で NodePool の VM のサイズを変えるには

この記事は cloud.config tech blog にもマルチポストしています。

tech-blog.cloud-config.jp

はじめに

Azure Kubernetes Service こと AKS を運用していて、スペック不足や運用費節約の目的で NodePool で使用する VM のサイズを変更したくなることが時たまあるかと思います。
その際のやり方には実はひと手間必要だったりするので、同じようなことで詰まった他の人向けに共有できればと思います。

1. まずは変更先の NodePool を作成する

まず前提知識として、一度作成した NodePool の VM サイズを変更することはできません。
なので、NodePool で使用する VM サイズを変更したい場合、新しい NodePool を作成して古いものを削除するという手順が必要になります。
「ノードプールの追加」から、新しい NodePool の追加画面に移ります。

追加画面では、まず「モード」をシステムにします。
この設定は NodePool に他にシステムモードが設定されているものがない場合は必要です。
AKS の NodePool には、「システムモード」と「ユーザーモード」があり、少なくとも一つの NodePool がシステムモードで稼働する必要があるためです。
システムモードの NodePool に含まれる Node は Kubernetes Cluster でいうところの「マスターノード」となり、Kubernetes Cluster の管理者的な役割を果たします。
そのため、少なくとも 1 台の Node がマスターノードである必要があり、AKS では NodePool 単位でマスターノードとする Node の集まりをシステムモードの NodePool として設定している形です。

余談は置いておいて、あとは VM のサイズとスケール範囲を指定して NodePool を作成します。

2. 変更元の NodePool を削除

新しい NodePool が作成できたら、NodePool の一覧画面に戻り、古い方の NodePool を選択します。

NodePool の概要画面に移動したら、その NodePool の削除を行います。

この時、もし他の NodePool が全部ユーザーモードだったりそもそも他の NodePool が存在しなかった場合はこの削除ボタンがクリックできません。
他に NodePool があるのに削除できない！という時は他の NodePool のモードが原因である可能性があるので、確認してみましょう。

また、余談として、ユーザーモードとシステムモードの違いとして、ノード数の範囲の最小数を 0 にできるかできないかという違いがあります。
システムモードの NodePool は、少なくとも 1 台は動いている必要があるので最小数を 0 にすることができませんが、ユーザーモードの NodePool は最低で 1 台も動いていなくても問題ないということなのですね。
という豆知識でした。

おわりに

今回は若干素直ではない AKS の NodePool の VM サイズの変え方について共有しました。
覚えておくこととしては、NodePool のうち一つはシステムモードである必要があること、NodePool の VM サイズそれ自体は変更できないというあたりでしょうか。
分かってしまえば難しいことではないので、同じことで困っている人が居たら助けになれば幸いです。

参考

• Azure Kubernetes Service (AKS) でシステム ノード プールを管理する
• Kubernetes のコンポーネント

Kubernetes をゲーム感覚で腕試しできるサイト 「Game of PODs」で遊ばないと年を越せない 2021 冬

この記事は Fixer tech blog にもマルチポストしています。

tech-blog.cloud-config.jp

はじめに

最近 CKAD の受験して一旗上げようと画策しているなむゆです。
Kubernetes について学ぶ中で、腕試しに使えそうな面白そうなサイトを見つけたので紹介してみようという回です。

Game of PODs とは

Game of PODs とは、無料で遊べる Kubernetes の問題集です。
Kubernetes クラスターにアプリケーションを展開したり、クラスターで起きている問題を解決することを通してそれらの方法を学ぶことができます。
この問題集はKodeKloudというサービスに提供されている教材の一つで、KataKodaという教材用環境サービス内でホストされている仮想環境にアクセスしてハンズオン形式で課題を解くことができることが特徴です。
問題の内容としては、あるアーキテクチャが与えられて、「このアプリケーションの Pod を立ててね」「その Pod には Service を作ってこのポートでアクセスできるようにしてね」「インターネットからはこのポートでアクセスできるようにしてね」といった条件を満たした環境を作り出すことを目指すものです。
これらの条件は一つ一つクリアしていく形式ではなく、全体を作り切ってから確認ボタンを押して全体として目標を満たしているか確認する形式なので、それなりに一問の分量は多く、また、設計全体を実体に落とし込むための総合的な知識が求められます。
また、一つのアーキテクチャ全体を制限時間 1 時間の中で解く必要があるので、それなりの瞬発力も求められます。
難易度としてはそこそこ高め、Kubernetes でのリソースについて一通り理解して作成できるようになったレベルの人向けの問題集です。

始め方

Game of PODs を始めるには、まずは KodeKloud にユーザー登録を行います。
ユーザー登録できたら、以下の URL にアクセスし、「Start Course」をクリックします。
https://kodekloud.com/courses/game-of-pods/

教材ページに進んだら、「Introduction」のビデオを見て概要を確認したり、「References」でハンズオンに登場するアプリケーションについての概要を眺めたのち、「Access the Game!」からワールドマップ的なページを開きます。
この中の煙が上がっている個所がそれぞれの問題の入り口になります。

いずれかの個所をクリックして、「Let's fix it!」ボタンを押すと仮想環境のある KataKoda のページに遷移します。

このページの下の方にある「START SCENARIO」をクリックするとしばらく仮想環境が作られるのを待ち、完了すると問題を解き始めることができます。

ただし、DATALAKE、SERVICES、INGRESS は鋭意コンテンツ作成中のようで、また、FIREWALL と PRODUCTIONCLUSTERS については現在新しいインフラに移行中のようで 2021 年 12 月 7 日現在アクセスができません。
なので、実際取り組める問題は BRAVO、PENTO、TYRO、REDISISLANDS の 4 つのようです。
難易度としては TYRO = PENTO > REDISISLANDS > BRAVO
となっているので、BRAVO あたりから始めてみましょう。

遊び方

問題を解くビューには、ターミナルとクイズポータル、そして問題の環境への外部からのアクセスリンクのタブがあります。

クイズポータルのタブをクリックするとクイズポータルが開きます。ここでは、問題の中で解くべきアーキテクチャと残り時間が確認でき、左の「Check」ボタンを押すと答え合わせをすることができます。

答え合わせは何度でもすることができるので、一部分ができたら毎回その部分が正しいかどうか確認するために押すといいです。
アーキテクチャ図のそれぞれの要素をクリックすると、その部分で満たすべき条件が表示されます。例えば「サービスの名前は」
「サービスのタイプはとしてセットアップしてください」
「ポート番号は***で設定してください」
みたいな形です。
ターミナルではこの条件を満たすようにコマンドを駆使して設定していきましょう。

Check して全部の条件を満たすと、問題が解決できたことになります。
パスワードが表示されるので、それをコピーしましょう。
コピーしたパスワードは、KodeKloud がわのワールドマップで問題を選んだ際に表示される「Magic Chant」のテキストボックスに入力して「Submit」ボタンを押すことで登録できます。

Magic Chant の内容が合っていれば煙が上がっていた部分が正常に戻ります。
やったね！

詰まったら？

どうしても詰まったら、KodeKloud の教材一覧にそれぞれの問題の解答動画があります。
わからない部分については動画で確認しながら進めるのも手です。

おわりに

今回は Kubernetes の腕試し用教材の Game of PODs について紹介してみました。
Kubernetes 学習に一息つきたいときや腕試ししてみたいときにはぜひ試してみてください。

参考

• KodeKloud
• KataKoda

普段何となく使っているレベルからもう 1 ミリだけ詳しくなる Kubernetes の Service とは何ぞや

この記事は Fixer tech blog にもマルチポストしています。

tech-blog.cloud-config.jp

はじめに

Kubernetes にアプリケーションを配置するときに使用するリソースの一つに Service があります。
仕事で普段既に構成されたマニフェストを利用していると、その役割としてやっていることを忘れがちになっていたので思い出しがてら記事にしてみます。

サービスディスカバリ とは

Kubernetes の Service について説明する前に Kubernetes 上に展開したアプリケーションに対してどうやってアドレスを特定して接続を行うかを説明する必要があります。
Kubernetes 上に展開されるアプリケーションは Pod 内のコンテナとして存在しています。
そして、その Pod はそれぞれ Kubernetes クラスターのネットワーク内で指定された個別のプライベート IP アドレスを持ちます。
なので、最低限そのプライベートアドレスを知っていれば、Kubernetes クラスター内部からはアクセスが可能です。
しかし、その IP アドレスは Pod が再移動するたびに毎回変更されてしまうので、もしプライベート IP アドレスを用いて Kubernetes クラスター内で通信しようとすると接続先の Pod 再起動の度に接続先 IP アドレスの設定が必要になるので現実的ではありません。
そこで、DNS のような仕組みを作って同じ名前のアドレスにアクセスすると自動で目的の Pod にアクセスでき、しかも Pod 再起動の度に自動でアクセス先のプライベート IP アドレスを再設定してくれる仕組みがあればええやんという発想が出てきます。
この発想を「サービスディスカバリ」といいます。
直訳するとサービスを発見すること、もうちょっと意訳すると接続先のアプリケーションのアドレスを発見することになります。
そしてそれを実現するための仕組みの一つが、CoreDNS です。
これは、Kubernetes の中に仕込まれている仕組みの一つで、Kubernetes でのサービスディスカバリのデフォルトの実装となっています。
Kubernetes をインストールして起動すると、自動的に CoreDNS の pod がいくつか立ち上がり、後述の Service で規定した条件に従ってアドレスと Pod の IP アドレスの結び付けを行ってくれます。

Service ってなんぞや

そんな CoreDNS に対して、「このアドレスにやってきた通信はこっちの IP に流して！」と指示する役割を持つのが Service になります。
Service を作成するときには、そのリソースの名前と、通信の流し先の Pod の選択条件を記述します。
リソースの名前とネームスペース名から通信を受け付けるアドレスが決まります。
通信の流し先の Pod の選択条件は Service リソースの Selector として記述します。
Service で規定したアドレスにやってきた通信は、Selector の条件を満たす Pod からランダムに一つ選んで流されます。
そうです、Selector では通信の流し先の Pod の選択条件を規定するので、その条件に合う Pod は一つとは限りません。
複数の Pod が条件に当てはまればその条件に当てはまる Pod にほぼ平等に通信を分配するので、同じ Pod を複数用意しておけばその間でロードバランシングのようなこともできます。
その他、標準的な方法ではないのですが、Service では Kubernetes クラスター内からリクエストだけでなくクラスター外部からやってきたリクエストを Node のポート番号を指定して受け入れることもできます。
とはいえ、この方法だけだとインターネットからアクセスする際のアドレスは kubernetes クラスターに属するそれぞれの node のパブリック IP アドレス+ポート番号になってしまうので、アプリケーションを外部公開する際には素直に「Ingress」という別の仕組みを使うのが吉です。

おわりに

今回は思い出しがてらに Kubernetes の基本的な構成要素の Service についてその役割ややっていることについて説明しました。
知っている人にとっては当たり前のこと鳴きもしますが、復習がてらドキュメントを読み直してみるのも役に立つかと思います。

参考

• Kubernetes Service
• Service と Pod に対する DNS
• Kubernetes Ingress

明日 Kubernetes が少し楽しくなる認証の話

この記事はcloud.config tech blogにもマルチポストしています。

tech-blog.cloud-config.jp

はじめに

この記事を読んでいる方は、普段 Kubernetes をどのように利用しているでしょうか。
多くの方が、アプリケーションのデプロイを日常的に行っているか、あるいはその処理を自動化する作業を日々行っていると思います。
アプリケーションをデプロイすると、当たり前のように Pod が展開されて動き始めますが、その後ろでは普段気にしなくても様々なパラメータが扱われており、それを使って処理が行われています。
そのことをそこまで深く知らなくても Kubernetes を扱うことができますが、知るともう少しだけ Kubernetes を深く知り、アプリケーションを展開するときに「あ～今頃 Kubernetes ではこんなことが起きてるんだな～」と思えるようになります。
今回はそんなお話、Pod が立ち上がるたびにやりとりされる認証関連のお話です。

Kubernetes には２種類のアカウントが居る

実は、Kubernetes には 2 種類のアカウントが居ます。
一つは、普段 Kubernetes 外部からユーザーが Kubernetes を操作するために使うユーザーアカウントです。
これは、ユーザーが Kubernetes を操作する際にその操作を行っていいかの認可処理や、そもそもその操作をしようとしているユーザーが何者かを認証するために使用されます。
ユーザーアカウントの認証はローカルに置かれている ~/.kube/config にある kubeconfig ファイルの中にあるクライアント証明書というものを用いて行います。

users:  
- name: docker-desktop  
  user:  
    client-certificate-data: <クライアント証明データ>  
    client-key-data: <クライアントキー>  

上は docker-desktop にアクセスする際のクライアント証明書です。
Kubernetes にアクセスするときは上記のデータを Kubernetes 側に渡して、自分が何者であるか証明し、割り当てられている権限を用いて操作を行います。

2 種類のアカウントのうちもう一つは、サービスアカウントです。
こちらは、Kubernetes 内部のプロセスが使用するアカウントになります。
サービスアカウントは Namespace 毎に作られます。
そして、サービスアカウントが作られると、その資格情報としてトークンがSecret内に作られます。
つまり、作りたてほやほやの Namespace にも Secret とサービスアカウントが一つずつ作られています。

ローカルの Kubernetes で試してみましょう。
「そもそもローカルに Kubernetes 仕込んでないよ・・・」という方はこちらの記事を参考にしてローカル PC に Kubernetes を仕込んでみてください。
意外と簡単です。

kubectl create Namespace sample  

上記のコマンドで Namespace を新規作成します。

kubectl get serviceaccount, secret  

次に、上記のコマンドを実行して serviceaccount と secret のリソースの一覧を取得します。
結果は以下のようになるはずです。

NAME                     SECRETS   AGE  
serviceaccount/default   1         11d  
serviceaccount/sample1   1         2d  
  
NAME                         TYPE                                  DATA   AGE  
secret/default-token-8g2zb   kubernetes.io/service-account-token   3      11d  
secret/sample1-token-5b9pr   kubernetes.io/service-account-token   3      2d  

それぞれのリソースに、sample1 という名前のサービスアカウントと Secret が追加されています。
さらに、それとは別に「default」という名前のサービスアカウントと Secret も見えます。
こちらは、Namespace がまだ一つも手動で生成されていないときに自動で生成される Namespace で、Namespace を指定せずに作成されたリソースは全部 default の Namespace に作られます。

このように、namespace を新規作成するとそのたびに Secret とサービスアカウントが生成されます。

実は全部の Pod はサービスアカウントの資格情報を持っている

Kubernetes が動いているマシンの中で動いている Pod のプロセスも Kubernetes それ自体と通信することがあります。
ただ、Kubernetes と通信を行って何かしら操作しようとするマシン内のプロセス全部が Kubernetes のものとは限りません、ひょっとしたら何かしら悪意のあるプロセスがマシン内で動いていて Kubernetes を乗っ取ろうとしているかも？
ということで、プロセス側がそのような悪意のあるものでないと証明するのに使うのがサービスアカウントです。
Pod それぞれにサービスアカウントの資格情報を持たせることで、その Pod から kubernetes への通信に資格情報を含めて送ることでその通信がちゃんとした kubernetes のプロセスのものであると証明しています。
なので、全ての Pod は実はサービスアカウントの資格情報を持っているのです。
「え、これまで Pod 作るときにサービスアカウントの資格情報とか渡してないんだけど・・・」と思うかもしれませんが、大丈夫です、資格情報は指定しなくても自動的に default サービスアカウントのものが Pod に渡されています。

確認してみましょう。

kubectl run nginx --image=nginx  
kubectl get pod nginx -o=yaml  

すると、get pod コマンドを打った結果の大量の出力の中に次のような行があるかと思います。

  serviceAccount: default  
  serviceAccountName: default  

このように、サービスアカウントとしては Pod の生成時に明示的に指定しなくても、自動的に default のものが割り当るようになっています。
あるいは、サービスアカウントを作成してこれらのパラメータに設定することで明示的に「これを使って！」と宣言することもできます。
デフォルト以外のサービスアカウントを設定する目的としては、RBAC を用いて Pod 毎に厳密に権限をコントロールすることが挙げられますが、普段はあまり気にしないかもです。

おわりに

今回の記事では kubernetes の中で実は暗黙的に行われている認証の話について語ってみました。
ユーザーが認証、認可を受けて kubernetes とやりとりしているように、個々の Pod も認証、認可を行って kubernetes とやりとりしています。
これらの設定については普段触らなくても暗黙的にやってくれているものですが、知っておいて損はないかと思います。
明日からは「あ～今 kubernetes の中ではそれぞれの Pod にサービスアカウントが割り当っててそのおかげで Pod のプロセスが kubernetes とやりとりできているんだな～」と思いながらアプリケーションをデプロイしてください。

参考

• Kubernetes ドキュメント:認証

今更ながら学ぼう kubernetes での Pod の立て方

この記事はfixer tech blogにもマルチポストしています。

tech-blog.cloud-config.jp

はじめに

これを読んでいる方は普段 kubernetes で Pod 立てるときどんなふうに立てているでしょうか？
多くの場合、既に作成されているマニフェストファイルを共有されて、それを一部書き換えて apply するやり方をしているのではないかと思います。
それはそうすることで作成する kubernetes リソースをスクリプトとして管理できるという便利な側面があるからなのですが、一方でその後ろで行っていることの理解はしづらくなることもあるかと思います。
普通にアプリケーションを kubernetes 環境にデプロイする業務をするにはそこまで深く理解しなくても問題ないのですが、その後ろでどのようにして Pod が立っているか理解したくなっている気分の方はこの記事を読んでみてください。

そもそも Pod ってなんだ

Pod の概観
kubernetes での Pod というのは、アプリケーションのデプロイができる最小単位のリソースです。
この中には、一つまたは複数のコンテナが動いています。
コンテナというのは・・・・・
それぞれの中でアプリケーションなどが動いている環境です。
今回はコンテナについてはこれ以上掘り下げません。
kubernetes ではアプリケーションをコンテナ単位で動かすことはできず、アプリケーションをデプロイするということはほぼイコール Pod をデプロイするということになります。
ただ、Pod をデプロイする方法が kubernetes にはいくつか用意されており、それによって同時にデプロイされるリソースや機能が変わってきます。
以下ではその種類について解説します。

Pod の立て方その 1、Pod をそのまま立てる

Pod をそのまま立てる方法です。
Pod を立てるにはマニフェストファイルを作成してそれを apply する方法もあるのですが、Pod を立てることそれ自体はコマンド一つで実行できます。
今回は nginx のコンテナが一つ動く Pod を作成します。

kubectl run nginx --image=nginx  

実行が成功したら、以下のコマンドで作成されたリソースを確認してみましょう。

kubectl get all  

コマンドの出力としては、以下のようなものになるはずです。
Pod のリソースができました。
これが、Pod をそのまま立てる方法になります。

NAME        READY   STATUS    RESTARTS   AGE  
pod/nginx   1/1     Running   0          67s  

確認出来たら、今回作成した Pod は以下のコマンドで削除できます。

kubectl delete pod nginx  

Pod の立て方その 2、ReplicaSet を立てる

ReplicaSet
次は、ReplicaSet と呼ばれるリソースを作成する方法です。
この方法はコマンドだけで実行することはできず、マニフェストファイルの作成が必要になります。
新しい yaml ファイルを作成し、以下のコードを書き写して保存します。

apiVersion: apps/v1  
kind: ReplicaSet  
metadata:  
  name: nginx-replica-set  
  labels:  
    app: nginxReplicaSet  
spec:  
  replicas: 3  
  selector:  
    matchLabels:  
      app: nginxPod  
  template:  
    metadata:  
      labels:  
        app: nginxPod  
    spec:  
      containers:  
        - name: nginx  
          image: nginx  

保存出来たら、以下のコマンドで作成したマニフェストを apply し、kubernetes 上にリソース作成を指示します。

kubectl apply -f <作成したマニフェストファイルのパス>  

コマンドの実行が成功したら、以下のコマンドを実行してどのようなリソースが作成されたか確認してみましょう。

kubectl get all  

結果としては以下のようなものになるはずです。(STATUS 等は状態によって変わるかと思います。)
マニフェストファイルで定義したのは ReplicaSet のみですが、その定義の中にある template の内容に従って、Pod のリソースも同時に作成されています。
ReplicaSet は同じ Pod が常に複数立っている状態を維持してくれるリソースで、これが生きている限り template で指定した設定の Pod の個数をreplicas:のパラメータで指定した個数に保とうとしてくれます。
この働きによって、ReplicaSet のリソースを作成するとその ReplicaSet によってコントロールされている Pod が個別にコマンド実行することなく自動生成されます。
なので、ここで例えば作成されている Pod を一つ削除したりすると、すぐに新しい Pod が立ち上がってきて頭数を合わせてくれます。

NAME                          READY   STATUS              RESTARTS   AGE  
pod/nginx-replica-set-fb9vq   0/1     ContainerCreating   0          9s  
pod/nginx-replica-set-hz2cb   1/1     Running             0          9s  
pod/nginx-replica-set-zxxfp   1/1     Running             0          9s  
  
NAME                                DESIRED   CURRENT   READY   AGE  
replicaset.apps/nginx-replica-set   3         3         2       9s  

今回作成した ReplicaSet は以下のコマンドで削除できます。
ReplicaSet を削除すると、コントロールされていた Pod も同時に削除されます。

kubectl delete replicaset nginx-replica-set  

Pod の立て方その 3、Deployment を立てる

Deployment
3 つ目の方法は、Deployment を立てる方法です。
Deployment を立てることによっても Pod が立ちます。
Deployment についてはマニフェストを実行する以外にもコマンド一つで立ち上げる方法があります。

kubectl create deployment nginx-deployment --image=nginx --replicas=3  

コマンドが成功したら、どのようなリソースが作成されたか見てみましょう。

kubectl get all  

コマンドの事項結果は以下のようなものになるはずです。
今回立てた Deployment のほかに、Pod、さらに先程は手動で作成していた ReplicaSet も自動生成されています。
この Deployment というリソースは、Pod のデプロイ周りをコントロールしてくれるリソースで、デプロイされている Pod の個数を維持するために、Pod だけでなく ReplicaSet もコントロールします。
Pod の個数を維持するだけであれば ReplicaSet で十分な気もしますが、Deployment にはもう一つ別の機能があります。
それは、アプリケーションの更新時に Pod を止めずに更新することです。
例えば、Deployment 作成のコマンドの image を nginx から redis に更新して実行すると、Pod を全部削除せず、新しい Pod を作成しながら一部分だけ削除して全体を置き換えていくような動きをします。
これによって、例えば Pod で動かすコンテナのバージョンを上げた際にアプリケーション全体を止めることなく、更新をかけることができます。
ReplicaSet だと、例えばマニフェストファイルの中の image を redis に変えて実行するとそれだけだと Pod の更新が行われません。
更新するには、Pod を手動で削除して置き換えていく必要があります。
Deployment だとそのあたりもコントロールしてくれます。

NAME                                    READY   STATUS              RESTARTS   AGE  
pod/nginx-deployment-84cd76b964-578g2   1/1     Running             0          8s  
pod/nginx-deployment-84cd76b964-bf67f   0/1     ContainerCreating   0          8s  
pod/nginx-deployment-84cd76b964-j2ltp   1/1     Running             0          8s  
  
NAME                               READY   UP-TO-DATE   AVAILABLE   AGE  
deployment.apps/nginx-deployment   2/3     3            2           8s  
  
NAME                                          DESIRED   CURRENT   READY   AGE  
replicaset.apps/nginx-deployment-84cd76b964   3         3         2       8s  

この辺りのことを弄り終わったら、以下のコマンドで deployment を削除できます。
deployment を削除すると、自動的に ReplicaSet も Pod も削除されます。

kubectl delete deployment nginx-deployment  

おわりに

今回は、Pod をデプロイするということについて、kubernetes の機能を段階的に紹介しました。
一般的には Pod をデプロイする際には Deployment リソースをデプロイしていると思います。
なぜなら、レプリカ数の設定による可用性の維持や、更新時にもアプリケーションの動作を止めないようにすることなどは Web アプリとしては目指すべきところである上にコストもほとんどかからないためです。
ただ、その後ろでは ReplicaSet が立って、さらにそれが Pod を立てて・・・みたいなことをやっていることを知ることで、kubernetes についてもう一段深く知ることができるのではないかと思います。

参考

• Pod の概観
• ReplicaSet
• Deployment

Azureの資格試験「DP-100」を取得したので合格者の視点から語ってみる

この記事はcloud.config tech blogにもマルチポストしています。

tech-blog.cloud-config.jp

はじめに

マイクロソフト資格MCPにはRoleに合わせた様々なものがあるのですが、その中には機械学習系のRoleに関するものもあります。
以前から気になってちょくちょく勉強したりしていたのですが、最近ついに受験して合格してきたので、今回はそのDP-100という試験について共有したいと思います。

DP-100ってどんな試験？

公式サイトこちらです。
AzureのAI、機械学習系のサービスに関する資格試験の一つで、特にAzureのサービスを使って機械学習を用いたモデリングや分析を実際に行う方法に関する理解度を問われます。
機械学習の分析手法のことだけでなく、モデリングに使用するマシンの用意の方法から作成したモデルの運用まで、データサイエンスの業務のフロー全般が試験範囲になっています。
似た分野の試験はいくつかあります。例えば、AI-900という試験は人工知能と機械学習の全般的なトピックを扱っています。特にAzure Bot ServiceやQnA Maker、Cognitive Serviceを用いた人工知能系のサービスに重点が置かれています。
他には、DP系試験の中にDP-203という試験があったりするのですが、こちらは機械学習そのものというよりは、機械学習に使用するためのデータの扱いが焦点となっています。
Azure SynapseやDatabricksを使用して様々な種類の大量のデータをどのように扱うかといった内容が試験範囲になっており、分析それ自体よりも機械学習で使用するためのデータの扱い方に興味がある方はこちらの方が向いているかもしれないです。
DP-100はそれらの中では機械学習の分析を行う方法の周りに焦点が置かれているのが特徴といえます。

DP-100ってどんな人向け？

Azureの機械学習系サービスに興味がある人、あるいはそれらを用いて業務を実際にこなしている人。
機械学習と言っても分析することだけでなく、マシンリソースの話から作ったモデルを運用するところまで含めて興味がある人向けの試験のように思います。
人工知能の分野も含めるとAI-900も候補に挙がりますが、チャットボットを作ったり画像内の物体検知したり云々というよりはデータを基にしてモデリングを行い、知見を抽出するデータサイエンスのトピックに興味がある人はDP-100が向いているように思います。
あるいは、次章のトピックを眺めてみて面白そうだったら受けてみるという決め方もいいかもしれません。

出題範囲のトピック色々

出題範囲は、サービスとしてみるとAzure Machine LearningサービスとDatabricks周りがメインになるのですが、機械学習系の業務のフローで見ると大きく分けて分析前の下準備の話、モデリングの話、モデリング後のデプロイや運用の話の3つくらいに分けられるように思います。
今回もその中で個人的におもしろそうだと思ったトピックをピックアップしていきます。
気になった部分がある方は、試験ページのLearnから、対応するトピックを探してみてください。

下準備

• データの取得元の話。SQL Database、Databricks、Azure Storage等に配置したデータを分析対象にしたり。
• データには欠損値や偏りがありがち。その解消方法とか。
• 機械学習には分析のための高性能なマシンが必要。その設定方法とか。
• 大量のデータを扱うのに使えるDatabricksというサービスのお話。

機械学習モデリング

• モデリングに使用するデータはプライバシーの塊。個々人を特定できないようにしながらデータから有効な知見を得るための方法
• 機械学習モデルの説明責任の話。
• Azure Machine Learning ワークスペースを使うことでPythonコードを書くだけで機械学習に使うインフラから実験の内容まで全部設定できちゃう話。
• 実際にモデリングで使う分析手法色々。回帰分析からディープラーニングまで！
• Azure Machine Learning デザイナーを使うとドラッグ&ドロップで機械学習ができちゃう話。こちらで記事にもしてます。

デプロイ&運用

• 作ったモデルはaksクラスターにWebアプリとしてデプロイして利用することができる。そのやり方とか。以前記事にも書きました。
• いわゆるMLOpsの話。一度デプロイしたモデルを、時間の経過とともに更新して新しいデータに対しても精度を落とさないようにするには？
• Application Insightsと連携してデプロイしたWebサービスからメトリックを出力し、運用状況を監視したり。

おわりに

今回は、最近試験を受けて合格したMicrosoft試験のDP-100について語ってみました。
この資格の試験範囲はAzureを使って実際にどういったやり方で機械学習を行うのかを学ぶのに一番適しているように思います。
興味が出たら、実際に試験を受けないでも、試験ページの下にある試験範囲に対応したLearnを見て興味のある分野について学んでみてください。

参考

• 試験 DP-100: Designing and Implementing a Data Science Solution on Azure
• 試験 DP-203: Data Engineering on Microsoft Azure
• 試験 AI-900: Microsoft Azure AI Fundamentals