Dockerとk8sはどこまで学べば実務で足りるのか、深さの話

「Docker、どこまで覚えればいいんですか」という相談は、Gitについての相談とよく似た顔をしている。だが答えの構造は違う。Gitの場合、足りるかどうかを決めるのは覚えた「順番」だった。DockerとKubernetes(複数のコンテナを複数のマシンにまたがって配置し、落ちたら再起動するといった運用を自動化する仕組み。以下k8s)の場合、足りるかどうかを決めるのは覚える「量」ではなく、自分がどの層に立つ人間かということだ。これを量の問題だと思い込んだまま学習を始めると、たいてい同じ場所でつまずく。使わない知識に時間を溶かし、肝心のDockerfile(コンテナの作り方を書いた設計図)やcompose(複数のコンテナをまとめて起動する設定)の扱いが薄いまま終わってしまう。

DockerとKubernetesの入門教材をひとつなぎに眺めると、学習ロードマップは驚くほど美しい一本道に見える。Dockerでコンテナの概念を学び、Dockerfileを書き、composeで複数のコンテナを束ね、そのままKubernetesのPod・Service・Deploymentという部品に進み、最後にはクラスタそのものの構築やネットワークポリシー、独自の拡張機能の開発まで辿り着く。教材の目次としては正しい。だが実務でこの目次を最後まで塗り終える必要がある人は、思っているより少ない。

「全部覚える」がそのまま罠になる理由

アプリケーションを作る開発者にとって必要なのは、自分のアプリがどういうコンテナの上で動いていて、それが期待通りに起動・終了し、環境変数やポート、ボリュームのマウントが正しく反映されているかを確認できる力だ。Kubernetesで言えば、クラスタの中で自分のアプリがどう動いているかをマニフェスト(YAMLで書かれた、Podやサービスの望ましい状態を定義したファイル)から読み取り、デプロイして、落ちたら理由を推測できる力。ここまでで、実務の大半は足りる。一方、クラスタそのものを新しく構築し、ノードの数を増減させ、ネットワークの内部で何が起きているかまで手を入れるのは、SREや基盤チームの仕事だ。この二つは同じ技術スタックの上に立っているが、求められる深さがまったく違う層に属している。アプリ開発者が運用者と同じ深さまで潜ろうとすると、普段使わない知識に時間を溶かし、肝心のDockerfileやcomposeの扱いが浅いまま止まってしまう。

この層の違いは、技術記事の話題量を見てもうっすら輪郭が出る。Kubernetesは日本語の記事では「k8s」という略記も広く使われるため、両方の表記を合わせて数えると、Dockerの言及はKubernetes(k8s表記含む)より多いものの、差はおよそ1.8倍に留まる。極端な差ではない。輪郭がはっきり出るのは、言及量より職種の切り分け方のほうだ。Kubernetesのクラスタ構築・運用はSRE(Site Reliability Engineer、信頼性維持を専門に担う職種)や基盤エンジニアという、アプリ開発者とは別枠の採用職種として成立している。Dockerにそこまで独立した職種は立たない。Dockerが「ほぼ全員が触れる土台」であるのに対し、Kubernetesの深い部分は「専門職として切り出されるほど片手間では済ませにくい層」だという違いが、言及量の差よりもよほど輪郭を示している。

境界線はどこに引けばいいか

具体的な最低ラインを引くなら、こうなる。Dockerについては、自分が普段触るアプリをDockerfileで素早く書け、composeで依存サービスをまとめて立ち上げられ、ログを見てコンテナの異常に当たりをつけられること。これより先、マルチステージビルド(ビルド専用と実行専用のイメージを分けて最終的な容量を減らす手法)の細かい最適化やネットワークドライバーの内部実装まで踏み込む必要があるのは、イメージサイズや起動速度そのものがボトルネックになっているチームにいる人だけだ。

Kubernetesについては、マニフェストを読んで、自分のアプリが今どういう状態で動いているかをkubectl(クラスタを操作するコマンド)で追え、デプロイして、落ちたときにログとイベントから理由の仮説を立てられること。ここまでで、アプリ開発者として関わる現場の大半は事足りる。クラスタの構築、オートスケールの設計、複数クラスタをまたいだ運用、ネットワークポリシーの細部まで極めるのは、それ自体が専門職として成立している領域であり、無理に自分の担当範囲に加える必要はない。

「どこまで学ぶか」は役割が決まる前に決めなくていい

ここで一度、順番そのものを疑ってみてほしい。多くの人は「自分の役割が運用寄りか開発寄りかが決まったら、それに応じて学ぶ範囲を決めよう」と考える。だが実際には逆の順番のほうが安全なことが多い。先に自分が担当しているアプリを一つ、実際にDockerfileで固めてcomposeで動かしてみる。そこで詰まった場所が、自分にとって今まだ薄い層だ。次に、その同じアプリを既存のKubernetesクラスタに、マニフェストだけ書いてデプロイしてみる。これも詰まった場所が薄い層だ。この二回の体験だけで、自分が今どの層の知識を要求されているか、そしてどこが足りていてどこが足りていないかが、教材の目次を上から読むより正確に分かる。網羅から入るのではなく、実際に自分のアプリを動かしてみて、詰まった場所だけを深掘りする。これが、量ではなく層で学習範囲を決めるということの、具体的なやり方だ。

Docker・Kubernetesの学習を「資格レベルまで極めるべきか」「触れる程度でいいのか」という二択で悩む必要はない。自分がアプリ開発者としてこの技術の上に立っているなら、マニフェストを読めて、自分のアプリをデプロイしデバッグできるところまでで足りることが多い。その先のクラスタ内部やネットワークの深いところは、必要になったときにその都度掘ればいい。まずは自分のアプリを一つ、Dockerfileとマニフェストの両方で実際に動かしてみることから始めてほしい。

tasklogは、Docker・Kubernetesのような技術が技術記事でどれだけ言及され、伸びているかを/learn配下の各ページで実測のまま確認できるようにしているサービスだ。どの層まで学ぶか迷ったときの参考に、自分の目で数字を見てみてほしい。

https://s-tasklog.com/learn/docker

https://s-tasklog.com/learn/kubernetes

※本文中のDocker/Kubernetes言及数の比較は、Qiita API実測(Kubernetes・k8s表記を合算、2026年10月31日時点)の暫定値。