落とし穴に立て札を立てるが如く

ハマりどころの解決が少しでも早くなることを願って書いていきます

cert-manager について簡潔にまとめておきますね

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

はじめに

最近触った環境で cert-manager というソフトウェアを使用していて、その概要について把握するのにまあまあ時間がかかったため、あとで忘れたときの備忘録として、そして同様にソフトウェアについて把握したい方向けに簡潔にまとめておきます。

cert-manager とは

Kubernetes や OpenShift 上で動作する TLS 証明書の管理ソフトウェアです。
Kubernetes 上で Pod として常駐し、証明書が期限切れになる前に定期的に証明書の更新を自動的に行ってくれます。
作成した証明書は Kubernetes の Secret として自動生成されます。
Helm またはマニフェストで直接インストール可能です。

インストール方法

※前提条件として Helm のインストールが必要ですが未インストールであれば別途インストールしてください

マニフェストでインストールする

kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.14.5/cert-manager.yaml  

これで、cert-manager ネームスペースに cert-manager がインストールされます

Helm でインストールする

helm repo add jetstack https://charts.jetstack.io --force-update  
helm repo update  
  
helm install \  
  cert-manager jetstack/cert-manager \  
  --namespace cert-manager \  
  --create-namespace \  
  --version v1.14.5 \  
  --set installCRDs=true  

インストールされるカスタムリソース例

cert-manager をインストールすると、cert-manager で使用するいくつかのカスタムリソースが Kubernetes 上にインストールされます。
cert-manager を使用しているクラスターには以下のリソースが存在するため、探してみてください。
インストールされるものの中で代表的なものは以下です。

Issuer

証明書を取得する認証局の設定を行います。
取得する元の認証局によって設定値が異なります。
https://cert-manager.io/docs/concepts/issuer/
パターンによる実装例はこちらから
https://cert-manager.io/docs/configuration/issuers/

ClusterIssuer

Issuer を全ての Namespace で使いまわす場合に使用します。
設定値は Issuer とほぼ同じです。Namespace の指定がないのが大きな差異です。

Certificate

作成する証明書の詳細設定を行うリソースです。
証明書の有効期限や期限の何時間前に更新処理を行うか、作成した証明書を保存する Secret リソースの名前、証明書の CommonName 等を設定します。
https://cert-manager.io/docs/usage/certificate/#creating-certificate-resources

何か問題が起きたときは

証明書発行に何か問題が起きた場合は、まず cert-manager の Pod のログを確認することをお勧めします。
デフォルトでは cert-manager ネームスペースに証明書更新を実行する Pod がいるはずなので、 kubectl logsコマンドで Pod のログを確認してください。

また、cert-manager は起動時の設定次第では Prometheus 用フォーマットでメトリクスを出力できるので、そのメトリクスを監視することで証明書の更新失敗を検知できそうです。
具体的にどんな値が取得できるかは未検証&ドキュメントが見つかりません・・・
https://cert-manager.io/docs/devops-tips/prometheus-metrics/

おわりに

以前作業を行った環境で、名前だけは聞いていた cert-manager について実際に操作する段階でいろいろと調べる羽目になったため、同様に調べるときに欲しそうな情報だけまとめておきました。
同様の場面に遭遇した誰かの役に立つと幸いです。

参考

まずは 106 ページまで読んでみよう まだ読んでいる途中だけど SRE 本についてまとめてみる

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

ハイライト

  • SRE 本は分厚く見えますが「SREとは何か」については 106 ページまでにまとまっているのでまずは 106 ページまで読んでみるといいですよ!

はじめに

SRE サイトリライアビリティエンジニアリング Google の信頼性を支えるエンジニアリングチーム」は、全 550 ページにもわたってサイトリライアビリティエンジニアリング(以下 SRE)というエンジニアリング手法とは何か、どのように行うのかについて書かれた本です。
通称 SRE 本とも呼ばれており、SRE というものについて知るための最初の一冊なのですが、何と言っても分厚いです。
自分でも気になって読み始めて、私物としても買って読み進めているのですが読み切るのにはかなり時間がかかりそうです。
ただ、全体で Ⅴ 部まであるうちの第 Ⅱ 部まで読み終わり、ここがキリがよさそうに見えたので今の段階で一度、この本がどのようなことが書いてあって、どのように読むのがよさそうかについて現状の自分なりにまとめられればと思います。
「なぜ全部読み切る前から書評を書くの?」というのはあるのですが、理由としては二つあります。

  • 職場に最近この本がやってきて、周りのメンバーが興味を持っていそうなので。できれば一度読んでほしいので。鉄は熱いうちに打つ意味で
  • おもに自分のため、現状での自分の認識を整理する意味で。この先読み進めて印象が変わればそれはそれで書籍を読んで成長したということです

ということで、この記事の第一目的は職場の同じ部屋にいる周りのメンバーが SRE 本を手にして読み始め、何かを得るところまで読み進めさせることになります。そうなるといいな。
他にも、これから SRE 本を読もうと考えている人にとって実際に読み始めるきっかけになったり、すでに読んでいる方にとってこの本が読みやすくなったりすると幸いです。

全容

この本は全体で 5 部構成になっています。その中に各章があります。
それぞれの部で書かれていることをざっくり紹介します。

第 Ⅰ 部 イントロダクション(1-24 ページ)

SRE とは何か、どのようなことをするのかについて、それが生まれた当時の Google の背景を交えながら説明しています。
ソフトウェアエンジニアの背景を持ったエンジニアで運用を行うことでソフトウェアエンジニアリングのアプローチで運用を考えること、それを通してサイトの信頼性を上げていくことが SRE であるというのが結論になるかと思います。

第 Ⅱ 部 原則(25-106 ページ)

SRE の仕事の原則について説明しています。
ここで言う原則とは、SRE ではどのような要素に関心を持つか、どのように仕事を進めるかに関する諸々のトピックになります。
そのため、この書籍を「サイトリライアビリティエンジニアがどのような仕事をするのかについて知りたい」というモチベーションで読むなら一番重点的に読むべきかと考えています。
自分が読んでいるのは現状ここまでです。

第 Ⅲ 部 実践(107-408 ページ)

この章は SRE で扱うトピックについて細かく、各論を述べています。
全体で 300 ページもありますが、一つ一つのトピックの粒度が細かいのでここではディテールを詰めていくために読むことになりそうです。

第 Ⅳ 部 管理(409-478 ページ)

この章では、実際に SRE チームを運用していくときの方法論について書かれています。
新人 SRE がやってきたときにどのように学習経験を積ませて一人前の SRE に成長させるかが主なトピックになります。
逆に、自分が新人 SRE であったときにどのように業務を学んでいくべきかについて書かれていると見ることもできます。

第 Ⅴ 部 まとめ(479-496 ページ)

本当にその通りで、まとめの一言(一言ではない)が書かれています。

まずは 106 ページまで読んでみよう

この書籍は全体で 550 ページもあります、一息では読み切れないのもごもっともです。
ただ、この書籍を読む最初の一番の目的は「SRE とは何か」であるかと思います。
その場合は、最初の 106 ページまで読むと大体ほしいものが見つかるかと思うので、まずはそこまで読んでみるのがおすすめです。
というのも、全容で書いた通り、第 Ⅱ 部では SRE の仕事の原則について説明しています。
ここを読めば、SRE の基本的な考え方やそのための概念を理解することができます。
SRE の話題でよく言われるトイルとは何か、SLI、SLO、SLA とは何か、エラーバジェットとは何か、エラーバジェットを使ってどのように仕事をするのかがわかります。
そしてそれらのためにどのように監視や自動化を進めていくのか、アプリのリリースはどのように行うかの具体的な方針が書かれています。
その前の第 Ⅰ 部では SRE とは何かの概要がつかめるので、第 Ⅰ 部と第 Ⅱ 部までで SRE についての概要と基本的な考え方が身に付けられてしまいます。
逆に、第 Ⅲ 部は 300 ページもあるものの中身としてはアラートや障害対応、ロードバランシングといった各論に入っていくのであとで時間を作って読むか、最低限気になったトピックだけ拾い読みする読み方でも良さそうです。
ということで、SRE 本を読むならまずは最初の 106 ページまでをそれなりに集中して読んで、それから他の部を読むのが SRE とは何かについて知る上では良さそうです。

次に読むなら?

第 Ⅳ 部が良さそうです。
というのも、第 Ⅳ 部では SRE の主に育成方法が解説されているのですが、逆に見ると自分が SRE らしいスキルを身に付けたいときにどのように動くべきか、学ぶべきかが書かれているともいえるためです。
第 Ⅰ 部、第 Ⅱ 部と読んできて SRE というエンジニアリング手法に興味が出てきたら次はそれを身に着けるための方法が知りたくなるかと思います。

  • プロジェクトの目的を理解しながら作業を行う
  • ポストモーテムを読む/書く
  • 他のメンバーが行っている障害対応を横で見る(シャドウイングする)
    など、目次を見ただけでもやるべきことが見つかりそうです。
    自分も、次に読むならここかなと考えています。

「SRE とは?」今答えるなら

今の理解を試すため、あとでもっと SRE について知ったあとで読み返して恥ずかしくなるために今の SRE についての理解を書いておきます。
サイトリライアビリティエンジニアリングとは、文字通りサイトの信頼性を高めることを目的としたエンジニアリング手法です。
業務としては主にインフラの運用を行うのですが、ここにソフトウェアエンジニアリングのアプローチを組み込むことでより良い運用を目指します。
例えば、サイトの許容できるレベルの信頼性について SLO をプロダクトオーナーと合意し、それを満たすことを目標にインフラの運用を行います。
SRE チーム内では許容できる SLO と現状の余裕分をエラーバジェットとして管理し、SLO を下回らないように(国内では「SLO を割る」という言い方もあるようです)プロダクト開発チームと折り合いをつけながらサイトの信頼性とプロダクト開発のスピードを両立します。
運用における繰り返しの仕事、オーバーヘッドをトイルと呼び、これについてはできる限りうまく自動化したり仕組みを改善(エンジニアリング)することで減らそうとします。

まとめると、特に運用をエンジニアリングで改善するという考え方をすることがソフトウェアエンジニアリングのアプローチをとるということで、サイトリライアビリティエンジニアリングそれがなのかな・・・と今は考えています。
そうするとサイトリライアビリティエンジニアリングという文字通りの意味「サイトの信頼性」からは少し離れている気もするのですが、そこは「はじめに」で著者も認めているとおり、その内容をはっきりと表現出来ていないということなのかなと思います。
最初に名前を付けた時と実際に運用していく中で振る舞いやコアにあるものが変わってくることはよくあることなので、これもそういうものなのかな・・・・・という理解です。

おわりに

今回の記事では「SRE サイトリライアビリティエンジニアリング」という書籍について、途中まで読んだ状態で内容をまとめてどのように読むと読みやすいかを考えて説明してみました。
全体ではかなり分厚い書籍ですが、まずは特に最初の 106 ページを読もうと考えて読むとそれなりにハードルが下がるかと思うのでおすすめです。
周りのメンバーや他の人がこの書籍から何かを得る助けになっていると幸いです。
また、自分でも 3 章から先も引き続き読み進めるつもりです。
全体を読んでから何か考えが変わったりしたらまたブログを書くと思います~

参考

TerraformでつくったAWS LambdaにEventBridgeのトリガーが有効にならない時は

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

シンプルな答え

aws_lambda_permission リソースを作成する必要があります。

resource "aws_lambda_permission" "this" {
  action        = "lambda:InvokeFunction"
  function_name = <作成したLambdaのリソース名>
  principal     = "events.amazonaws.com"
  source_arn    = <作成したaws_cloudwatch_event_ruleリソースのARN>
}

原因

TerraformでLambdaにEventBridgeからのトリガーを作成する際には、EventBridgeからLambdaにアクセスさせる権限を別途付与する必要があります。
この権限の付与はAWSコンソール上からトリガーを作成する際には自動で行われるのですが、AWS CLISDK、CloudFormation等の仕組みを使用してトリガーを作成する場合は手動で実行するする必要があるようです。
Terraformでもこれと同様で手動で権限を付与しなければEventBridgeからLambdaにアクセスできなくてトリガーが動作しないということなのですね。
EventBridgeのトリガー作成画面にも以下のような注意書きがあります。

注: EventBridge コンソールを使用する場合、EventBridge は選択したターゲットについて適切な許可を自動的に設定します。AWS CLI、SDK、または CloudFormation を使用している場合は、適切な許可を設定する必要があります。  

TerraformのLambdaのドキュメントにもNoteがあります。

To give an external source (like an EventBridge Rule, SNS, or S3) permission to access the Lambda function, use the aws_lambda_permission resource

症状

aws_lambda_permissionなしでもLambdaとEventBridge、そしてそのトリガー自体はエラーも起こさずに作成できてしまいます。
ただし、この状態ではEventBridgeで設定したトリガーは有効になっていません。
例えばcronを用いた定期実行を設定していても、そのタイミングでLambdaの実行がトリガーされることはありません。

コンソールからLambdaを確認すると、EventBridgeのトリガーが設定されていないことが確認できます。

一方でEventBridgeの方ではトリガーが作成されているのが確認でき、対象としてLambdaが設定されているように見えてしまうのですが、実際にはトリガーが設定されておらず動作もしません。
紛らわしいですよね~

解決策

ということで、TerraformでLambdaにEventBridgeからのトリガーを作成する際には、EventBridgeからLambdaにアクセスさせる権限を別途付与するためにaws_lambda_permissionリソースを作成します。
プレースホルダーのLambdaリソース名とEventBridgeのARNはそれぞれのリソースのものを設定してください。
Terraformの再apply後、コンソールのLambdaの概要画面でトリガーが設定されていれば成功です!

resource "aws_lambda_permission" "this" {
  action        = "lambda:InvokeFunction"
  function_name = <作成したLambdaのリソース名>
  principal     = "events.amazonaws.com"
  source_arn    = <作成したaws_cloudwatch_event_ruleリソースのARN>
}

おわりに

コンソールで行ったことをTerraformに書き落とせばそのまま動くと考えていたら罠がありました。
コンソールの設定画面やTerraformのLambdaのドキュメントには注意書きがありますが、引っかかるまでこの仕様のこととは気づきませんでした。
おそらく同じことをしようとすれば100人のうち120人くらいが引っかかるかと思います、そんな方の助けになれば幸いです~

参考

Kubestronaut の称号を得たのでちょっと自慢させてください

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

tech-blog.cloud-config.jp

はじめに

この度私ことなむゆこと南條祐輝は Cloud Native Computing Foundation (CNCF) が主催する Kubernetes 関連資格を見事全て取得し、Kubestronaut の称号を授与されましたのでこちらにて自慢させていただきたく存じます。
https://www.credly.com/badges/d7bb7a25-8784-4be3-b43b-fd6c438bfe2c

Kubestronaut とは

Kubestronaut は、CNCF が主催している Kubernetes 関連の資格 5 つ全てを同時に有効にした人に贈られる称号です。
2024 年 3 月に行われたKubeCon Europe の 4 日目の Keynoteにて教育アンバサダープログラム関連の動きの一つとして発表されました。
同時に有効にするというのは説明が必要なのですが・・・
Kubernetes の資格には合格してから 3 年間(2024 年 4 月 1 日以降に取得したものは 2 年間になりました、残念)の有効期限があり、その期限を迎えると資格が失効します。
そのため、同時に有効にするということは 5 つ全ての資格が全てそれぞれ最後に取得してから有効期限を迎えていない状態であるということです。
Kubernetes 関連の技術は日々変化しているため、試験に合格したことがあるというだけでなく、最新の Kubernetes の知識のキャッチアップがちゃんとできているかどうかも問われるようです。
5 つ全ての資格を取得した状態にすると最後の資格を取得してから 1 か月以内に CNCF からメールが届き、上記のように Credly で Kubestronaut の称号を授与されます。

Kubernetes 資格の特徴

CNCF が主催している Kubernetes 資格は 5 つあり、そのうちの 3 つ(CKAD、CKA、CKS)はハンズオン形式の試験になります。
ハンズオン形式なので、試験では実際の Kubernetes 環境に接続し、コマンドラインで操作を行って問題を解きます。
問題では Kubernetes の知識を問われるだけでなく、試験時間に対して問題数が多いため個々の操作を効率的に行うテクニックも要求されます。
詳しくはKubernetes が普段使いの人のための CKAD 対策の話の記事もどうぞ。
残りの二つの試験(KCNA、KCSA)は 4 択問題を解く形式で、こちらは残りの資格の入門レベルの位置づけになります。
Kubernetes 資格の目立つ特徴としては、受験コストがそれなりに高いことが挙げられます。
CKA、CKS、CKAD の試験の価格は 2024 年 4 月現在それぞれ 395$です。
KCNA、KCSAは250$です。
もちろん日本円で支払うと為替レートの影響も受けるため、ざっくり手計算で 60000 円強、37500 円強かかることになります。
試験を管理している Linux Foundation は頻繁に試験のセールを行っているため実際にはこの価格の 7 割~半額で受験していますが、それでもこれらの資格を全て取得しようとすると受験だけでもそれなりのコストがかかります。

特典は?

Kubestronaut になると以下のような特典があるそうです。

  • Kubestronaut ジャケット(こちらに写真があります)
  • CNCF のイベントや資格のディスカウント(資格の維持に助かります・・・が、具体的に何割引きになるかはまだ発表されていません)
  • CNCF の Ambassadorとして登録される(らしい)

なぜこの称号を狙おうと思ったのか

Kubernetes は元々業務で頻繁に使用していて自分にとって強みのある技術であると考えていたので、そのスキルが CNCF に称号として認めてもらえたら嬉しいかな、というのが一番のモチベーションでした。
副次的には具体的に有用な特典(特にディスカウントとか)もあるため、これから先 Kubernetes 資格を維持していくために有用かなと思えたのも理由の一つです。
あとは Kubestronaut Program が発表された段階で CKS、CKAD、CKA の資格を既に保持していたため、残りは入門レベルの資格である KCNA と KCSA の 2 つだけであったことも大きかったかと思います。
もし今 Kubernetes 資格を 1 つも取得していない状態で Kubestronaut Program のことを知ったとして、特典のために 1 つから資格を取得し始めていたかと思うとそうでもない気がします。
あくまでその時の状態で追加で支払うコストが比較的安くなっていたため目指しただけかもしれません。
それでもその時点で残りの 2 つの資格の取得のために 2 週間ほどの猛勉強の時間と 250$x2(セールの 3 割ほどのディスカウントはありました)のコストが必要だったのですが、その時はそれでも十分見合うだろうと考えていました。今もそう考えています。不思議です。

おわりに

今回は CNCF から発表された Kubestronaut という称号について自慢したり紹介したりしてきました。
Kubernetes の知見や取得した資格がまだない状態から狙っていくようなものではないかとは思いますが、それなりに Kubernetes について詳しかったり、すでに Kubernetes 資格を半分近く持っているという人にとってはこれまで積み上げてきたものが一つ公に認められるようなそういう称号であるように感じます。
そういった方は目指してみるべきかと思います。

参考

KubeCon + CloudNativeCon Europe 2024 Day four: Looking to the past and the future of Kubernetes (and more news
Announcing the Kubestronaut program
Kubestronaut program | CNCF
Kubestronaut Program - Linux Foundation
CNCF Ambassadors

前からあるけど意外と便利な iPhone のショートカット機能を使う

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

はじめに

PC の OS は Windows 専ですが、携帯電話は iPhone しか使わないなむゆです。 iPhone にはしばらく見ないうちにいろいろな便利機能が追加されてたりします。 大抵の機能は一度触ったらそれっきりになる気がしますが、一部はそこそこ便利で毎日使うようになるものもあったりします。 今回はそんな中の一つであるショートカット機能について紹介しようと思います。

ショートカット機能とは

ショートカット機能は、iOS 13 から追加された iPhone の機能です。 処理を実行する条件とその時にどのような処理を行うかを設定してやることで、iPhone 上で大なう作業を自動化することができます。 この記事を見に来るような方にとっては、Azure Logic Apps や Power Automate が感覚的に近いでしょうか。 処理を実行する条件としては時刻のようなオーソドックスなもののほかに、「特定の場所から出発/特定の場所に到着したとき」や「Wi-Fi/Bluetooth に接続したとき」、「充電器に接続したとき」など、携帯電話ならではのものが多く、iPhoneユースケースに沿った自動化が組めるようになっています。 実行する内容も iPhone の機能と結びついており、大半のデフォルトのアプリ(例えばアラームとか)をいじったりだとか、音量、画面の明るさ等 iPhone 自体の設定をいじるようなこともできます。 これらを組み合わせることで、普段 iPhone を通して頻繁に行う作業を自動化してより便利に処理を行うことができます。

で、何が便利なの

これだけ聞くと、そこまで便利かと言われるとそうでもないようにも思います。 実際自分も前は一回だけ触ってもののそんなに自動化することないなと思ってほったらかしてました。 ただ、後からよく考えてみるとなんだかんだで iPhone 使って毎日やることもなくはない名と気付きました。 例えば自分の場合、夜になってから次の日のアラームを仕掛けるのですが、仕掛けると言っても 5:30 か 7:00 のどちらかの二択になります。 常に片方のアラートだけをセットするなら、時計アプリの機能で毎日アラームを鳴らすようにすればいいのですが、若干選択をする部分があるのでシンプルに自動化することができません。 iPhone のオートメーションの機能はそういった若干要件が複雑になった自動処理や、途中に入力を求めるような処理にも対応でき、そんな意味で便利な機能なんじゃないかと思います。

使用例

さて、そんなオートメーション機能を使って実際に何か作ってみましょう。 今回は例として、自分も普段使いしている「夜 10 時になったら次の日何時にアラートを仕掛けるか決めてセットする」オートメーションを作っていきます。

まずはホーム画面から「ショートカット」のアプリアイコンを探してタップします。(当たり前) アイコンとしては下記のようなものです。iPhone のデフォルトでインストールされている便利機能系アプリは数が多いので探しやすいように念のため。

ショートカットアプリを開いたら、下のタブで「オートメーション」を選択します。 これまで作成したオートメーションの一覧が表示しますが、一旦無視して新規作成のため右上の「+」ボタンを押します。

「個人用オートメーションを作成」を選択してオートメーションの作成を始めます。

すると新規オートメーションの実行条件を選択することになるので「時刻」を選択します。

すると、周期と何時に実行するかを聞かれるので、この処理を実行したい時間を選択します。自分の場合は 22:00 を選択しました。

次に、その時間に実行するアクションを選択します。 実行時はまずはアラームを鳴らす時間を選択したいので、「すべてのアクション」から「メニューから選択」を選びます。

すると、アクションの一覧に「メニューから選択」のアクションが追加されます。 「-」ボタンの横に選択肢のラベルが編集できるようになっているので、設定したいアラームの時刻辺りをテキストで打ち込んでいきます。 上部の「プロンプト」にはメニューの表示時に表示するメッセージが設定できるので、分かりやすいメッセージを書き込んでおきましょう。

入力が完了したら、次はアクションを追加していきます。実際に行いたいのはアラームの設定なので、アクションの検索から「アラーム」と入力して検索し、「アラームを切り替える」を選択します。

するとアラームを設定するアクションが追加されるので、時間をタップして設定するアラームを選択します。 アラームを選択したら、そのアクションをドラッグし、5:30 など、作成した選択肢の下に移動させます。これによって、先に作成したメニューでそのラベルが選択された時の処理を記述することができます。

同様にして、もう片方の選択肢の実行時にセットするアラームのアクションを設定します。 ここまででオートメーションの作成は完了です、右下の実行ボタンを押してこのオートメーションを実行してみましょう。

画面上部からメニューが生えてきて、作成した選択肢が表示されるはずです。 どちらか片方を選択しましょう。

オートメーションの処理としてはそこで完了になります。iPhone のホーム画面に戻って「時計」アプリからアラームの一覧を見てみましょう。 選択した時間のアラームがオンになっているはずです。

おわりに

今回は iPhone のオートメーション機能について共有しました。 機能として追加されたのはもう 2 年前になりますが、使ってみると今更のように便利さを感じることもあります。 既に機能としてはご存知の方もいるかと思いますが、久々に思い出した方はこの機会に普段 iPhone を使用して行っている処理の一部を自動化できないか考えてみるのも楽しいかもしれないですね。

参考

【小ネタ】Kubernetes でバッチアプリをデバッグしたいときに使える Pod の command 上書きの話

f:id:nam_yu_sql:20220414083002j:plain この記事は後ほどcloud.config tech blogにもマルチポストする予定です。

使いどころ

Kubernetes 上で動かすバッチアプリケーションを開発しているとき、コンテナ動作がおかしくてデバッグしたくなることがあるかと思います。
バッチでない、普段起動状態でとどまるようなアプリケーションなら kubectl exec コマンドを使ってコンテナに入り、各種デバッグ作業ができるのですが・・・
バッチのような、デプロイ後すぐに動作をはじめ、動作が終わるとすぐに停止してしまうようなアプリケーションの場合起動している時間が短すぎるのでコンテナには言ってもすぐに Pod が停止して締め出されてしまいます。
そういった時に、コンテナの生存時間を無理やり伸ばしてコンテナ内でデバッグするのに使える便利な小ネタの話です。

やり方

アプリケーションの展開に使うマニフェストを用意します。
マニフェストの中のコンテナの設定をしている箇所で、以下の 5 行目のような行を挟み込みます。

...<前略>  
  containers:  
  - name: <何かしらコンテナ名>  
    image: <何かしらのイメージ>  
    command: ["/bin/sh", "-c", "sleep 100000"]  
...<後略>  

その後、マニフェストをデプロイします。
すると、コンテナが処理を始めなくなるのでコンテナ内を歩き回って各種調査をすることができます。

詳細の話

これは、Kubernetesマニフェストcommandのパラメータを使用した小技です。
コンテナを作るときに書く Dockerfile には、起動後に実行するファイルを指定するためにENTRYPOINT命令を書きます。
例えばバッチアプリケーションを実行する場合はそのアプリケーションの実行ファイルを指定しておくことで、コンテナが起動後すぐにそのアプリケーションを実行できます。
一方で、今回指定した Kubernetesマニフェストcommandパラメータは、これを上書きする効果があります。
これによって本来は起動後に Dockerfile で指定したバッチ用アプリケーションを実行するはずが、今回はここで書いた bin/sh -c sleep 100000 のコマンドが実行され、100000 秒間 sleep します。
コンテナは sleep 実行中は等に何も問題が起きない限り起動し続けるので、sleep している間にkubectl execコマンドを使ってコンテナ内に入り、探索することができるということです。
同じような効果のものとして、Kubernetes を使う前のコンテナの段階では、コンテナ実行時に docker run --endpoint <各種コマンド> と書くことでも、コンテナ起動時にエンドポイントを上書きできます。
こちらはローカルの Docker で動作確認を行う時に使える方法です。
話は戻りまして、 commandパラメータは他にも、busybox などの小型で便利ツールだけが詰まったようなイメージにおいては各種シェルコマンドを使うことでアプリケーション実装要らずの小規模なバッチ処理を書くこともできたりするので何かと便利です。
困ったときの小手三寸として検討してみるといいかと思います。

おわりに

今回は、起動後すぐに処理を実行してその後すぐに終了してしまうようなバッチ系のアプリが入ったコンテナをデバッグする方法として、コンテナの ENTRYPOINT を上書きして起動状態を維持する方法について紹介しました。
しばらく方法を考えていくつか検索をかけたら誰かしら思いついそうな気もする小ネタですが、最初に検索してこの記事に当たったあなたはちょっとラッキー(だといいな)ということで。

参考

Kubernetes のマニフェストファイルを手軽に色々チェックできる ValidKube を使ってみる

f:id:nam_yu_sql:20220318070916j:plain この記事は cloud.config tech blog にもマルチポストしています。

tech-blog.cloud-config.jp

はじめに

Kubernetesマニフェストを書いているとき、書いている内容が正しいか、ベストプラクティスに沿っているか確認したくなることがあるかと思います。
そんな時に使えるツールはいくつかありますが、その中でもブラウザ上で手軽に利用できそうなサービスがあったので紹介してみる回です。

ValidKube とは

ValidKubeは、ブラウザ上で動作する Kubernetesマニフェスト用のチェックを行える Web アプリです。
Kubernetesマニフェストについて、構造が正しいかどうか検証したり、不要な記述を除いたり、セキュリティ上の問題点がないかを調べたりすることができます。

このツールの実体はこの後ろで動いている個別の検証ツールで、それぞれ以下のツールがバックエンドで動いています。

Web アプリケーション上でマニフェストを入力して実行するとマニフェストがバックエンドに送られ、上記ツールを使用して検証を行い、検証結果を Web アプリケーション上で表示する仕組みで動いているようです。

使い方

ページを開くと右と左に 2 つのフォームがあります。
この中の左のフォームに検証したいマニフェストファイルの中身を張り付け、右側のフォームの上部にあるタブで検証の内容を選び、「Run」ボタンをクリックするとマニフェストの検証が行われます。
f:id:nam_yu_sql:20220318070943p:plain
今回は例としてサンプルのマニフェストを使用してみましょう。
左側のフォームの下の Example のボタンをクリックしてから Run ボタンをクリックすると以下のような結果が出力されています。
f:id:nam_yu_sql:20220318070955p:plain
結果の中に

'spec.replicas: Invalid type. Expected: [integer,null], given: string'  

とあることから、spec.replicas のパラメータの型が integer でなければならないのに string が入寮されているので不正であると言われていますね。

同様に、右側のフォームの上部のタブから「Secure」を選択してみましょう。
するとすぐに検証が実行され、以下のような結果が出力されるはずです。
f:id:nam_yu_sql:20220318071006p:plain
出力結果には様々な脆弱性yaml 形式で表示されていますが例えば以下のようなものが出力されています。

  - Description: A program inside the container can elevate its own privileges and  
      run as root, which might give the program control over the container and node.  
    ID: KSV001  
    IacMetadata: {}  
    Layer: {}  
    Message: Container 'nginx' of Deployment 'nginx-deployment' should set 'securityContext.allowPrivilegeEscalation'  
      to false  
    Namespace: appshield.kubernetes.KSV001  
    PrimaryURL: https://avd.aquasec.com/appshield/ksv001  
    Query: data.appshield.kubernetes.KSV001.deny  
    References:  
    - https://kubernetes.io/docs/concepts/security/pod-security-standards/#restricted  
    - https://avd.aquasec.com/appshield/ksv001  
    Resolution: Set 'set containers[].securityContext.allowPrivilegeEscalation' to  
      'false'.  
    Severity: MEDIUM  
    Status: FAIL  
    Title: Process can elevate its own privileges  
    Type: Kubernetes Security Check  

例えば上記の脆弱性だと、「コンテナ内のプログラムが権限昇格してコンテナやノードの中身を弄り回す危険があるので、マニフェストのコンテナの設定パラメータでsecurityContext.allowPrivilegeEscalationfalseに設定してください」といった内容になります。
ここで報告される脆弱性は、Aqua security という企業が公開している脆弱性データベースが元になっており、公開されている脆弱性の一覧はこちらで閲覧することができます。

このようにして、作成したマニフェストの検証をブラウザ上で簡単に行うことができます。

使い道

このアプリケーションの実体は 3 つの個別のコマンドラインツールです。
コマンドラインツールとして動くということで、CI パイプラインに組み込みやすいため、Git でのコミット毎、または PR 作成時にビルドパイプラインを実行するようにし、それらで個別のツールを使用し、マニフェストの検証を行うといった使い方ができます。
というか、これらのツールのユースケースはそういった場面が主に想定されています。
一方で、ビルドパイプラインを実行する前に開発を進める段階でマニフェストを検証するのにはマニフェストを簡単に検証できるため ValidKube を使用することになるのかなと思います。

また、ValidKube は Githubオープンソースとして公開されており、アプリケーションをビルドして自前の環境に展開する方法が Github リポジトリ上で紹介されています。
このアプリケーションはサイトで公開されているものなので、他人のサービスに自前のマニフェストを送信したくないという場合もあると思いますが、その場合は時前の環境に ValidKube を展開して身内にのみ公開することでマニフェストを外部に公開せずに ValidKube を利用することもできます。

マニフェストファイルの品質を上げたい場合や、Kubernetes に展開する前にマニフェストの整合性を検証しておきたい場合には検討できるツールかと思います。

おわりに

今回は kubernetesマニフェストの検証ツールである validkube を触ってみました。
マニフェストファイルの中身が妥当か判断するのは人の目だけだと難しい部分もあり、そのような部分をカバーするのに自動化されたツールはとても有用だと思います。
作成したマニフェストの検証方法に悩んでいる方の参考になれば幸いです。

参考