Kubernetesエンジニアのフリーランス案件の仕事内容｜案件の種類と働き方

フリーランスのKubernetesエンジニアの仕事は、クラスターを安定して動かし、変更を安全に届け、版上げや構成の見直しを計画どおりに進めることです。ただし、運用の担い手として入るのか、移行を任されるのか、基盤を一から設計するのか、開発チーム向けの基盤を整えるのかで、1日の過ごし方も、向き合う相手も、手元に残る成果物も大きく変わります。

この記事では、Kubernetesの案件を4つの種類に分け、それぞれの1日と1か月の流れ、関わる相手、成果物を整理します。報酬の決まり方はKubernetesエンジニアの報酬の記事、求められるスキルはKubernetesの案件で求められるスキルで扱っているので、ここでは「参画したら実際に何をしているか」に絞ります。

仕事の中身は「任される範囲」と「基盤の状態」で決まる

同じ「Kubernetesエンジニア募集」でも、仕事の中身を分けるのは主に次の2つです。

• 任される範囲：決まった手順で運用を回すのか、構成や運用ルールを自分で決めるのか
• 基盤の状態：安定して動いているのか、版上げや移行を控えているのか、これから作るのか

この2つを掛け合わせると、Kubernetesの案件はおおむね次の4種類に分けられます。

以下では、それぞれの1日と1か月の流れを典型的な例として紹介します。時間の配分は案件ごとに違うため、目安として読んでください。

運用・保守の案件の仕事

1日の流れ（例）

朝は、夜間のアラートと監視の画面を確かめ、気になる動きがあれば原因を調べます。午前中は、アプリの開発チームからの依頼に対応します。「新しい環境変数を追加したい」「Podが再起動を繰り返す」「リソースの上限を上げたい」といった依頼を受け、マニフェストを修正してレビューに出します。午後は、定例の打ち合わせで前週の障害や作業の予定を共有し、残りの時間で手順書の更新や、繰り返し起きる問題の調査を進めます。

自分で構成を大きく変えることは少なく、依頼を正しく受け、小さな変更を安全に積み重ねるのが中心です。

1か月の流れ（例）

• 月初：前月の障害と依頼の件数を振り返り、繰り返し起きた問題を洗い出す
• 毎週：基盤チームの定例で作業の予定と変更の予定をそろえる
• 月の半ば：証明書の期限、ノードのイメージの更新、アドオンの更新など、定期の保守作業をこなす
• 月末：稼働の実績をまとめ、改善の提案があれば次月の予定に入れてもらう

成果物

修正したマニフェストとそのレビューの記録、障害の調査の記録、手順書、定期作業の記録などです。運用の案件では、作業の記録が後から来た人の手順書になるため、書き残す量が評価に直結します。

版上げ・移行の案件の仕事

Kubernetesは年に数回、新しいマイナーバージョンが出て、各版のパッチ提供は約1年で終わります（2026年10月時点、Kubernetesの公式サイトによる）。そのため、版上げは一度きりの作業ではなく、定期的に必要になる仕事です。外部からの入り口の作り替え、自前の基盤からマネージドサービスへの移行、GitOpsへの切り替えなども、この種類に入ります。

1日の流れ（例）

計画の段階では、廃止されるAPIを使っているマニフェストを洗い出し、アドオンやHelmチャートの対応状況を一覧にします。アプリの各チームに影響を説明し、修正をお願いする打ち合わせも多くなります。検証の段階では、検証環境で手順を何度も流し、問題が出れば手順書を直します。切り替えの当日は、関係者と時間を決めて作業し、結果を確かめて報告します。

1か月の流れ（例）

• 前半：影響の調査、作業の範囲と順番の決定、関係者への説明
• 半ば：検証環境での手順の確認、戻し方の確認、各チームの修正の取りまとめ
• 後半：本番に近い環境、本番の順に切り替え、終わったら振り返りをまとめる

1か月で終わるとは限らず、複数のクラスターを順に上げる場合は、この流れを繰り返します。

成果物

影響調査の一覧、作業計画、手順書と戻しの手順、検証の結果、切り替えの報告、振り返りの記録です。移行の案件では、「なぜこの順番で、なぜこの日に切り替えたか」を説明する資料の重みが増します。

設計・新規構築の案件の仕事

1日・1か月の流れ（例）

最初の数週間は、要件の整理に時間を使います。載せるアプリの数と性質、求められる可用性、セキュリティの方針、使うクラウドの決まりなどを、発注元のアーキテクトやセキュリティ担当と詰めていきます。そのうえで、クラスターの分け方、名前空間と権限の切り方、通信の入り口、監視とログの集め方、変更の届け方を設計書にまとめます。

設計が固まった後は、TerraformなどのIaCでクラスターと周辺のクラウドの資源を作り、検証用のアプリで動作を確かめます。1か月の単位では、設計のレビュー、構築、検証、運用への引き継ぎの準備が順に進みます。

成果物

構成の設計書、権限と名前空間の一覧、通信の経路図、IaCのコード、運用の手順書、運用チームへの引き継ぎの資料です。新規構築の案件は、構築した後に誰が運用するかで成果物の重心が変わります。自分が抜けた後に別のチームが運用するなら、手順書と設計の理由を残す比重が大きくなります。

開発者向けの基盤づくりの案件の仕事

複数の開発チームが同じクラスターを使う現場で、各チームが自分たちでアプリを安全に出せるように、仕組みとルールを整える仕事です。プラットフォームチームと呼ばれる体制に入ることもあります。

1日・1か月の流れ（例）

日々の仕事は、配布の仕組み（CI/CDやGitOpsのツール）の改善、アプリの新規登録のテンプレートの整備、開発チームからの質問への回答です。1か月の単位では、利用するチームの要望を集めて優先順位を決め、基盤の改善の計画を立てます。

成果物

配布の仕組みの設定、Helmチャートやマニフェストのテンプレート、利用者向けの手引き、ポリシーの設定、利用状況の報告などです。この種類では、作った仕組みが実際に使われているかが評価の軸になるため、利用者の声を聞く時間が欠かせません。

どの案件にも共通する仕事

種類が違っても、次の仕事はほぼすべてのKubernetes案件にあります。

1. 変更をレビューに通す：マニフェストやIaCの変更は、差分を示してレビューを受けてから反映する
2. 障害の切り分け：イベント・ログ・指標を見て、原因がアプリ、クラスター、クラウドのどこにあるかを絞る
3. 記録を残す：作業の手順と判断の理由を、後から来た人が追える場所に残す
4. 関係者への説明：開発チームやクラウドの担当に、影響と依頼事項を分かる言葉で伝える

フリーランスならではの仕事として、自分の稼働の記録と報告もあります。障害の対応や切り替えの作業で稼働が延びることがあるため、日々の作業時間をつけておく必要があります。

関わる相手と、その相手に出すもの

信頼性の目標づくりや障害対応の仕組みまで担う案件は、SREの仕事と重なります。SREの働き方はSREの仕事内容の記事、配布の仕組みづくりが中心の案件はDevOpsエンジニアの仕事内容の記事をご覧ください。働く場所については、変更をGitで管理する現場ほどリモートで進めやすくなります。詳しくはKubernetesのリモート案件の記事で解説しています。

よくある質問

Kubernetesエンジニアは、アプリのコードを書くことはありますか？

アプリの機能を作ることは少ないものの、配布の仕組みの設定、運用を助ける小さなツール、IaCのコードを書くことはよくあります。どこまで書く想定かは案件ごとに違うため、参画前に確かめておくと、稼働の見込みとのずれを防げます。

夜間や休日の作業はありますか？

版上げの切り替えや障害の対応で、利用の少ない時間帯に作業することがあります。頻度と、そのときの稼働の扱いは案件によって違うため、契約前に確かめておきましょう。確かめ方はKubernetes案件の選び方で整理しています。

参画して最初の1か月は何をすることが多いですか？

クラスターの構成と権限の把握、変更の届け方の確認、監視とアラートの見方の確認から始めるのが一般的です。初月の進め方はKubernetesエンジニアの参画初月にやることで詳しく解説します。