認定Kubernetesアプリケーション開発者を目指そう!

はじめに

本連載も、今回で最終回となります。ここまで、9回にわたってアプリケーション開発者がKubernetesを利用するために必要なトピックを解説してきました。これで一通りの学習が完了したことになりますが、では本当にKubernetes上でアプリケーションを構築する準備ができているかというと、自信を持てていない方もいるのではないかと思います。そこで今回は、下記のような方々に向けて「Linux Foundation認定試験のススメ」を伝授します。

• 一通りの学習が完了したけど自信が持てない方
• 知識を身に着けたことを証明したい方
• 改めて知識を整理して身に着けたいという方

Linux Foundationによる
Kubernetes認定試験

第1回でも触れたように、認定試験を受けることは大いに役に立ちます。せっかく学習したのですから、対外的に知識を示す肩書きとして取得することも有益です。2021年11月現在、Kubernetesに関する認定試験はLinux Foundationによって4種類が提供されています。

	CKA(Certified Kubernetes Administrator): 認定Kubernetes管理者 Kubernetes管理者の責任を遂行するスキル、知識、および能力を備えていることを保証する
	CKAD(Certified Kubernetes Application Developer): 認定Kubernetesアプリケーション開発者 Kubernetesのクラウドネイティブアプリケーションを設計、構築、および展開できることを証明する
	CKS(Certified Kubernetes Security Specialist): 認定Kubernetesセキュリティスペシャリスト さまざまなベストプラクティスのスキル、知識、およびコンピテンシーを備え、ビルド・デプロイ・ランタイム時にコンテナベース アプリケーションやKubernetesプラットフォームを保護できることを保証する
	KNCA(Kubernetes and Cloud Native Associate): Kubernetesとクラウドネイティブアソシエイト Kubernetesと広範なクラウド ネイティブ エコシステムに関する基本的な知識とスキルを証明する

本連載の主な対象者であるアプリケーション開発者の方は、この中でも特に認定Kuberneteアプリケーション開発者(CKAD)の認定を取得するのが良いでしょう。これまで学んできた、アプリケーションをKubernetes上で設計、構築するためのスキルが問われます。

上記4つの試験のうち、KCNA試験のみが初級レベル、その他3種類は中級レベルと位置づけられています。4種類の試験全てがすべてオンラインで行われます。人が出入りしないこと、余計な音が入らないこと、など条件付きではありますが、自宅など任意の場所から受験が可能です。KCNAを除く中級レベルの3試験では2時間の制限時間の中でKubernetesクラスタの操作についていくつかの課題が与えられます。受験者はWebブラウザに表示されるコンソール上でkubectl等のコマンドを用いて実際にKubernetesクラスタを操作して課題に回答します。ペーパーテストのように選択肢の中から正答を選ぶような形式ではないので、知識だけでなく実際にKubernetesクラスタの操作に習熟していることが必要です。

また、試験中にはkubernetes.ioの公式ドキュメントを参照できます。そのため、細かな知識まで暗記する必要はありません。与えられた課題に対して情報を参照しながら素早くクラスタを操作できるかが問われます。初級レベルと位置づけられているKCNAについては試験時間が90分、出題形式も演習形式ではなく選択肢から正答を選ぶものと、他の3種類と毛色が異なります。

試験終了後、1日程度で結果が通知されます。合格の場合には合格証が授与されます。非常に重要な点として、不合格でも1回に限り再受験できるため、試験内容が想像しづらい、どこまで準備をすれば良いかわからない…という場合でも、一度受験することをおすすめします。網羅的な内容なので学習の指標になりますし、学習の初期に受験するのもひとつの手です。

では、実際に認定Kubernetesアプリケーション開発者、CKADの試験内容を見てみましょう。筆者は認定を取得しているため試験問題を把握していますが、詳細を解説することは禁止されているので、公開されている内容に基づいて紹介します。

認定Kubernetesアプリケーション開発者試験

カリキュラムはLinux Foundationの公式サイトに記載があります。これらの内容をひとつひとつ見ていきましょう。

アプリケーションの設計と構築

アプリケーションコンテナをPodとして起動するための知識を問うような内容です。

• コンテナイメージを定義、構築、変更する
• ジョブとCronJobsを理解する
• マルチコンテナポッドのデザインパターンを理解する(サイドカー、initなど)
• 永続的で一時的なボリュームを利用する

このうち、ジョブとCronjobs、マルチコンテナポッドについては本連載であまり触れていませんので、ここで簡単に説明します。

ジョブとCronJobsは、バッチ処理のような非常駐のプロセスをPodとして実行するために使われるKubernetesのリソースです。マニフェストのサンプルを見てみましょう。これは円周率を計算して出力するコンテナです。

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
  backoffLimit: 4

このJobリソースが作成されると、templateフィールドに設定された通りにPodが生成されます。Podが返り値0で終了すれば、そのままPodが終了後に削除されて Jobが成功となります。失敗した場合はbackoffLimitの設定値を上限としてPodが再作成されます。CronJobはこのJobを定期的に作成するためのリソースです。設定値はJobとほぼ同一で、作成のスケジュールをCron形式で記述します。こちらは、公式ドキュメントのCronJobを参照してください。

Podには複数のコンテナを含めることができます。複数のコンテナで構成されたPodをマルチコンテナポッドと呼んでいます。多くの場合で、マルチポッドコンテナは1つのアプリケーションコンテナと、アプリケーションコンテナを補助するサイドカーコンテナ、起動時にのみ動作するinitコンテナで構成されます。サイドカーコンテナの典型的な役割はログフォワーダやメトリクスエクスポーターです。アプリケーションコンテナとvolumeやlinux namespaceを共有することで、アプリケーションコンテナの主機能に影響なく補助的な機能を提供します。initコンテナはデータのダウンロードなどの初期化処理にしばしば使われます。こちらは公式ドキュメントのInitコンテナが翻訳されていますので、一読することをおすすめします。

アプリケーションの展開

アプリケーションを実際にKubernetesクラスタにデプロイしたり、アップデートするための知識を問うような内容です。

• Kubernetesプリミティブを使用して、一般的なデプロイ戦略(青/緑またはカナリアなど)を実装する
• 展開とローリング更新の実行方法を理解する
• Helmパッケージマネージャーを使用して、既存のパッケージをデプロイする

DeploymentやServiceを利用したアプリケーションの展開については第3回、第7回で解説しました。Helmパッケージマネージャーの詳細は解説していませんが、第8回では実際に既存パッケージとしてPrometheus、Grafana、Lokiをインストールしています。HelmはKubernetes公式の日本語ドキュメントが用意されていないので、Helmの公式ドキュメント(英語)を参照するか、書籍やWebサイトを探してみてください。既存パッケージをデプロイするのであれば、深い知識は必要ありません。

アプリケーションの可観測性とメンテナンス

アプリケーションのオブザーバビリティに関する内容です。第8回、第9回で取り組んだ内容ですが、一部触れていないところがあるので、簡単に解説します。

• APIの非推奨を理解する
• プローブとヘルスチェックを実装する
• 提供されているツールを使用してKubernetesアプリケーションを監視する
• コンテナログを利用する
• Kubernetesでのデバッグ

これまで扱ってきたKubernetesリソースのマニフェストに、apiVersionという項目を記述していたことを覚えているでしょうか。apiVersionには「v1」 のほかに「v1beta1」「v1alpha1」などの値を設定することがあります。このapiVersionによっては、将来廃止されたり、破壊的な変更が入る可能性があります。

第2回ではKubernetesクラスタをv1.20で構築していました。実はこのバージョンだと、Ingressリソースについて第3回で扱ったnetworking.k8s.io/v1のほかに、extensions/v1beta1、networking/v1beta1というapiVersionを使用することもできます。このIngressリソースは、1つ前のバージョン1.19で Stableのnetworking.k8s.io/v1がリリースされました。それまではv1beta1が使用されており、マニフェストファイルのスキーマが一部異なっています。この v1beta1も現時点の最新リリースv1.22でついに削除され、使えなくなりました。v1.19以前にv1beta1でIngressを扱っていた場合には、v1に対応するようにマニフェストファイルを書き換えておく必要があるわけです。

プローブとヘルスチェックも重要な機能です。非コンテナアプリケーション同様にコンテナアプリケーションにも異常が発生することがありますし、その際には当該コンテナへの通信を遮断したり、コンテナの再起動が必要になることもあるでしょう。Podにプローブを設定することで、これらの制御をコマンド実行やHTTPリクエストによるヘルスチェックを通して自動化できます。下記の例では、/tmp/healthyファイルの存在をcatコマンドで確認します。/tmp/healthyファイルが存在しない場合は異常発生と判断してコンテナを再作成します。詳細はPodのライフサイクルを参照してください。

apiVersion: v1
kind: Pod
metadata:
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: liveness-app
    args:
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy

コンテナログやデバッグについては、第8回、第9回で解説しました。実務でも頻繁に利用する内容なので押さえておきましょう。

アプリケーション環境、構成、およびセキュリティ

コンテナアプリケーション自体の動作というよりも、セキュリティやリソース制限などのコンテナの動作環境に関する知識を問う項目です。これらはあまり本連載で触れてきませんでしたが、特に複数のチーム、複数のアプリケーションが同一のKubernetesクラスタで稼働するような場合には、特にこうした知識が必要になります。それぞれ学習のポインタを示しながら簡単に触れていきます。

• Kubernetes(CRD)を拡張するリソースを見つけて使用する
• 認証、承認、アドミッションコントロールを理解する
• リソースの要件、制限、および割り当てを理解して定義する
• ConfigMapを理解する
• シークレットを作成して使用する
• ServiceAccountsを理解する
• SecurityContextsを理解する

CRD(Custom Resource Definition)は、Kubernetesリソースを自身で定義するものです。PodやDeployment、Serviceなど、これまで様々なリソースを操作してきましたが、独自のリソースを自身で定義することも可能です。独自のリソースを定義するためのCRDというリソースがあります。環境やCNIによってはすでにいくつかのCRDが定義されているはずです。kubectl get crdコマンドで確認してみてください。

認証、承認、アドミッションコントロールは、Kubernetesクラスタへのアクセス制御の仕組みです。kubectlコマンドを利用してkube-apiserverにリクエストを送る際に、これらの仕組みで操作の許可、拒否が判定されるようになっています。上記のCRDと合わせて、公式ドキュメントのKubernetesを拡張するを参照して理解を深めてください。

Kubernetesでは各コンテナにmemory、cpuの使用量を制限したり、namespace単位でmemory、cpuの使用量や作成できるPod、Serviceの数などを制限したりできます。コンテナ単位の制限についてはコンテナのリソース管理を、namespace 単位の制限についてはリソースクォータを参照してください。

ConfigMap、Secretについては、第4回で実際にアプリケーションに利用しました。アプリケーションを構成する上では欠かせない内容です。

ServiceAccoutsは、Podなどに設定するKubernetesのユーザです。Podを作成すると、設定されたServiceAccountに対応する認証情報がPod内に配置されます。このServiceAccoutnsに権限を付与することでPodはkube-apiserverにアクセスできます。このときPodの作成権限など不適切な権限を与えてしまうと、Podへの侵入が発生した場合に足がかりになるなどセキュリティホールを作ることになるため、注意しましょう。詳細は公式ドキュメントのConfigure Service Accounts for Podsを参照してください。

SecurityContextsは、Podに設定するセキュリティ制限です。例えば、コンテナがルートユーザを利用することを禁止したり、SELinuxやAppArmorを強制することでコンテナのセキュリティを高めることができます。設定方法と項目については、公式ドキュメントのConfigure a Security Context for a Pod or Containerを参照してください。

サービスとネットワーキング

最後はネットワーキングに関する内容です。入力ルールとは、おそらくIngree Ruleのことですね。Service、Ingressについては第3回で解説したので、ここではNetworkPoliciesだけ簡単に解説します。

• NetworkPoliciesの基本的な理解を示す
• サービスを介したアプリケーションへのアクセスの提供とトラブルシューティング
• 入力ルールを使用してアプリケーションを公開する

NetworkPolicyはPod間の通信を制御するためのKubernetesリソースです。デフォルトではKubernetesのPod間の通信はすべて許可されています。ここにファイアウォールのような制限をかけるのがNetworkPolicyです。NetworkPolicyが有効になっているクラスタでは、Namespace、Podのラベル、IPアドレスをベースに通信を拒否したり、許可したりできます。下記は「role: db」のPodに「role:frontend」のPodからTCP/6379の通信のみを許可するNetworkPolicyの設定例です。詳細はネットワークポリシーを確認してください。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379

CKADのカリキュラムはここまでです。連載で扱ったもの以外にも、実際にアプリケーションを構築するうえで必要になる可能性のある内容が多く含まれています。これらの項目について、一度触ってみてからドキュメントをすぐに引けるような状態にしておくと、試験に回答できるようになります。

おわりに

今回は、これまでの内容を振り返りながら、Kubernetes上でアプリケーションを構築する開発者のための試験であるCKADのカリキュラムを紹介しました。CKADに実際に挑戦し取得することで、アプリケーション開発者としては十分Kubernetesを扱えるようになったと言って差し支えないでしょう。

さて、これで本連載は終了です。全10回の内容を終えても、まだまだKubernetesの世界には沢山のトピックがあります。実際にKubernetesクラスタでアプリケーションを構築、運用する中ではどんどん新たなリソースや技術要素に出会うことかと思いますが、それでも本連載はそのための足がかりとして十分な内容になっていると思います。

最後に宣伝になりますが、弊社クリエーションラインではKuberentesを使うための技術トレーニングについて、基礎から応用まで豊富にコースを取り揃えています。改めて網羅的に学習したいという方や、サービスメッシュやセキュリティなど、特定のトピックについて集中的に学習したい方も、受講をご検討ください。