Kubernetesエンジニアのフリーランス案件で求められるスキルと経験

Kubernetesのフリーランス案件では、ワークロードにリソースを割り当てる設計、クラスターの内外の通信の設計、最小権限の権限設計、変更をGitから安全に届ける配布の仕組み、版上げ、障害の切り分けの6つの分野が見られます。どの分野も「設定できる」だけでなく、なぜその値や構成にしたかを説明できるかで評価が分かれます。

この記事では、分野ごとに案件で問われる中身と、経験の段階ごとの目安を整理します。信頼性の目標（SLO）や障害対応の仕組みづくりはSREの案件で求められるスキル、独立までの進め方はKubernetesエンジニアがフリーランスになるにはで扱っています。

案件で見られるスキルの全体像

これに、案件で使うクラウド（EKS、GKE、AKSなど）のネットワークと権限の知識が組み合わさります。クラウド側のスキルはAWSエンジニアのスキル、GCPエンジニアのスキル、Azureエンジニアのスキルの記事で扱っています。

ワークロードとリソースの設計

Kubernetesの公式ドキュメントでは、コンテナのリソースの「要求（requests）」はスケジューラーがPodを置くノードを決めるときに使われ、「上限（limits）」はkubeletが実行中に守らせると説明されています。CPUの上限を超えると処理が絞られ、メモリの上限を超えると、メモリが逼迫したときにカーネルによってコンテナが強制終了されることがあるとされています。

案件で問われるのは、この仕組みを知っていることではなく、実際のアプリで値をどう決めたかです。

• 実際の使用量を測ってから要求の値を決め、見直しの時期を決めていた
• メモリの上限による強制終了が続いたとき、上限を上げる前にアプリ側の原因を調べた
• 要求の合計とノードの台数の関係を見て、費用と余裕のバランスを取った

通信の設計

クラスターの内側はService、外部からの入り口はIngressやGateway APIで扱うのが基本です。2026年10月時点のKubernetesの公式ドキュメントでは、IngressではなくGatewayを使うことが推奨され、Ingress APIは凍結されて今後の変更はないと書かれています。一方で、Ingressは一般提供のAPIとして残り、削除する予定はないとされています。

Gateway APIは、インフラを提供する側、クラスターを運用する側、アプリを開発する側という役割に沿って設定を分けられるように作られています。案件では、誰がどの設定を持つかまで含めて入り口を設計できるかが見られます。Ingressからの移り方はKubernetesエンジニアの将来性で触れています。

あわせて、ネットワークポリシーで名前空間やアプリの間の通信を絞った経験や、クラウドのロードバランサーとの組み合わせで起きた問題を解いた経験も、具体的に話せる材料になります。

権限とセキュリティ

公式ドキュメントのRBACの推奨事項では、利用者やサービスアカウントに必要な権限だけを与えること、できるだけクラスター全体ではなく名前空間の単位で権限を付けること、ワイルドカードで権限を与えないことが挙げられています。ワイルドカードは、今あるリソースだけでなく、将来追加される種類のリソースへの権限まで与えてしまうためです。権限の設定を定期的に見直すことも勧められています。

案件で評価されやすいのは、次のような経験です。

• チームごとに名前空間を分け、権限をその範囲に限った
• 管理者の権限を日常の作業で使わない運用にした
• アプリのPodが不要にAPIへの権限を持たないよう、サービスアカウントを見直した
• クラウドの権限とKubernetesの権限の対応を整理し、誰が何をできるかを一覧にした

配布の仕組みとGitOps

マニフェストをどう管理し、どう本番に届けるかは、改善の案件で最もよく問われる分野です。Helmで部品化する、Kustomizeで環境ごとの差分を管理するといった方法に加え、GitOpsの経験を求める案件が増えています。

CNCFのワーキンググループがまとめたOpenGitOpsの原則では、望ましい状態を宣言的に書くこと、それを変更履歴の残る形で保管すること、エージェントが自動で取り込むこと、実際の状態と望ましい状態を継続的に突き合わせることの4つが示されています。

案件で問われるのは、ツールの導入より、運用のルールです。

• 本番への変更は、すべてリポジトリへの変更として、レビューを通す形にした
• 緊急時にkubectlで直接直したときの、リポジトリへの戻し方を決めた
• 環境ごとの差分を最小限にし、検証で確かめたものがそのまま本番に届くようにした

GitOpsの導入を含む開発の流れ全体の整備は、DevOpsの案件と重なる部分があります。Kubernetesの案件では、クラスターの側から見た配布の仕組みを説明できることが中心になります。

版上げと障害の切り分け

版上げでは、廃止されるAPIの洗い出し、アドオンやコントローラーの対応状況の確認、ノードの入れ替えの順番、戻し方の準備が問われます。手順どおりに上げた経験と、事前の確認から組み立てた経験は、面談で区別して聞かれます。

障害の切り分けでは、調べる順番を持っているかが見られます。Podの状態とイベント、コンテナのログ、ノードの状態、Serviceやエンドポイントの対応、と順に絞り込んだ経験を、具体的な場面とあわせて話せると説得力が出ます。実技の試験であるCKAは、この分野の裏付けとして読まれることがあります。詳しくはCKAの記事をご覧ください。

経験の段階ごとの目安

自分がどの段階にいるかを把握し、次の段階で問われる分野を一つずつ足していくと、案件の幅が広がります。

よくある質問

HelmやArgo CDなど、どのツールの経験が必須ですか？

案件ごとに使うツールは違うため、特定のツールが必須とは限りません。ツールの名前より、マニフェストをどう管理し、変更がどのレビューを通って本番に届くかを説明できるほうが評価につながります。そのうえで、案件票に書かれたツールを検証環境で一通り触っておくと安心です。

アプリのコードはどこまで書けると有利ですか？

基盤の案件でも、障害の切り分けでアプリのログや設定を読む場面は多くあります。シェルや、GoやPythonでちょっとした自動化を書けると、運用の手作業を減らす改善で力を発揮しやすくなります。

資格はどれを取ればよいですか？

クラスターの運用や障害対応を担う役割を狙うなら、管理者向けのCKAが範囲と重なります。ただ、資格がなくても参画できる案件は多く、実務で何を判断したかが先に見られます。評価される場面と準備の進め方はCKAの記事をご覧ください。