---
title: "非マネージドkubernetesを味わおう | grasys blog"
url: "https://blog.grasys.io/post/nakamura-kento/unmanaged-kubernetes"
description: "はじめまして、grasysの中村です。 今回は、最近クラウドサービスであるGKE, AKS, EKSを中心に使用しているみなさんに向けて、 原点回帰して アンマネージド(非マネージド)Kubernetesについてお話ししたいと思います。 実はクラウドサービスではこんなことをやっていたんだ、 クラスターの中にnodeが…"
---

# 非マネージドkubernetesを味わおう

-   ![](/_astro/noicon.CTHOhNiB_1HMs6A.webp)[nakamura kento](/authors/nakamura-kento/)
-   公開日：2026年3月4日
-   カテゴリー：[Tech](/categories/tech/)
-   タグ：[#Google Cloud](/tags/google-cloud/)[#Kubernetes](/tags/kubernetes/)

![非マネージドkubernetesを味わおう](/_astro/hero.3NqdOhbP_ZDCxcx.webp)

はじめまして、grasysの中村です。  
今回は、最近クラウドサービスであるGKE, AKS, EKSを中心に使用しているみなさんに向けて、  
原点回帰して  
アンマネージド(非マネージド)Kubernetesについてお話ししたいと思います。

実はクラウドサービスではこんなことをやっていたんだ、  
クラスターの中にnodeがあり、その中にpodがあるといった認識をされている方も多いかと思います。そこで、普段ブラックボックス化しがちなKubernetesの構造を紐解いてみたいと思います。

下記はイメージ画像

![非マネージドkubernetesを味わおうを示す構成図](/_astro/01-Blank-diagram-3da2f5eb.BWykF8kA_Z2wtKp1.webp)

上記の画像から使用しているコンポーネントについてまとめたのが下記となります。

## コントロールプレーン(※クラウドだと操作不可)

| コンポーネント名 | 概要 |
| --- | --- |
| kube-apiserver | 心臓・全てのコンポーネントとやりとり |
| etcd | バックアップ保管場所 |
| kube-scheduler | podをどのnodeに配置するか決めてくれる指揮官 |
| kube-controller-manager | バランサー、理想の状態を維持してくれる |

## ノードエージェント

| コンポーネント名 | 概要 |
| --- | --- |
| kubelet | 監視者 |
| kube-proxy | ネットワークバランサー |
| コンテナランタイム | コンテナ本体 |

## アドオン

| コンポーネント名 | 概要 |
| --- | --- |
| CNI | ネットワーク層 |
| coreDNS | IPアドレスではなく、名前解決を行うための仕組み |
| Dashboard | 管理画面 |
| Metrics Server | kubectl topの結果元、HPA設定時のデータ元 |
| Cluster-level Logging | コンテナログの保管先 |
| cloud-controller-manager | クラウドプロバイダー固有のコントローラー。Kubernetes環境とクラウド環境を連携させる。 ※v1.27以降コントロールプレーンから移行済み。 |

## クラウド管理のコンポーネント

上記のコントロールプレーン全般はクラウド側が管理しております。  
そのため、コントロールプレーンの設定には触れませんが、自動で作成されておりコントロールプレーンの費用として管理費という料金が発生しています。

また、他の設定も特に設定変更はできません。  
基本的にクラウドの場合、自由度が低いため3大クラウド全体それぞれ設定できる部分に多少の差分はありますが、ほぼ設定できないのが主になります。

ただ、非マネージドのクラウドを設定するにはまずどれが何か？という事を理解する必要があるので、まずはこちらを説明させていただきます。

## kubernetesのコンポーネントについて

非マネージドのkubernetesを理解するにはまずコンポーネントがどのような役割をしているのか理解する必要があるのでこちらを書かせていただきます。

-   kube-apiserver  
    全てのコンポーネントとやりとりします。kubectlコマンドなどを叩いた時に応答するのがこちらです。
    
-   etcd  
    バックアップ保管場所であり、キーバリュー形式で保存されています。etcdがある事で、アップデートした時などにリストアすることができます。
    
-   kube-scheduler  
    podをどのnodeに配置するか決めてくれるものです。どのノードで動かすべきなのか？を判断して自動で配置してくれています
    
-   kube-controller-manager  
    バランサー、理想の状態を維持してくれています。例えば、特定のnodeがダウンした場合、同時にpodもダウンします。その際に、代わりのpodを起動してくれます。
    
-   kubelet  
    ノード上の監視者。コンテナがpodの中で実際に動いているのか？というのをみてくれています。
    
-   kube-proxy  
    ネットワークバランサーです。ノードの外部からのアクセスを適切なコンテナに転送してくれるため、podとの通信ができています。
    
-   コンテナランタイム  
    コンテナ本体です。ツールを触ったことがあるのであれば、dockerが一番有名かもしれません。ただ、現在はcontainerdが動いているのが主流になります。
    
-   アドオン  
    CNI  
    ネットワーク層です。podが新しく作られた時にIPアドレスが割り振られると思いますが、そちらを担当します。また、CNIは公式で提供しているものがなく「通信の仕組み」は外部のプラグインです。  
    そのため規格があるのですが、そちらが  
    **すべての Pod は、NAT（アドレス変換）なしで他のすべての Pod と通信できること。**  
    **すべてのノードは、NAT なしですべての Pod と通信できること。**  
    **Pod が自分自身を認識する IP アドレスは、他者がその Pod を認識する IP アドレスと同じであること。**  
    とのことです。  
    代表的なのはCalicoやFlanelなどかと思います。  
    ちなみにクラウドの場合はデフォルトの設定だとそのクラウドのオリジナルのCNIを使用しています。
    
-   coreDNS  
    IPアドレスで指定する事ではなくpod名などの名称でやりとりするために必須なコンポーネントです。
    
-   Dashboard  
    公式が提供しているプラウザでクラスターの状態を管理/操作できるWeb UIです。
    
-   Metrics Server  
    各ノードやPodのCPU・メモリ使用率を収集しています。kubectl topの結果元であったり、HPA設定時の判断材料になったりしています
    
-   cloud-controller-manager  
    クラウドプロバイダー固有のコントローラーです。Kubernetes環境とクラウド環境を連携させています。  
    例えば、NodeとVMやロードバランサとServiceのType: LoadBalancerなどです。  
    もともとコントロールプレーンに入っていましたが、v1.27以降コントロールプレーンから移行しています。
    

## さいごに

つらつらと書かせていただきましたが、kubernetesのインフラ側の説明は以上になります。  
ただ、上記に記載した通りコンポーネントや設定項目は無数に存在します。  
かつてはこれらを一つひとつ手動で設定する非常にハードルの高い作業でしたが、現在ではベストプラクティスが定型化されています。  
そのため、マネージドサービスに頼らなくても、手軽に非マネージドのKubernetes環境を構築できる便利なツールが広く普及しています。次回は、そうした環境構築ツールについてご紹介させていただこうと思います。

ありがとうございました。

## この記事を書いた人

[![](/_astro/noicon.CTHOhNiB_Z24aAgM.webp)](/authors/nakamura-kento/)

### [nakamura kento](/authors/nakamura-kento/)

nakamura kentoのプロフィールと執筆記事をご覧いただけます。

[プロフィールと記事一覧](/authors/nakamura-kento/)