Kubernetes on kkato.dev

Prometheusリモートストレージの比較

Sat, 14 Mar 2026 12:00:00 +0900

Prometheusはデフォルトでローカルディスクにメトリクスを保存しますが、長期保存やHA構成を実現するためにリモートストレージが必要になります。代表的な選択肢としてThanos・Cortex・Mimirの3つがあり、業務で検討する機会があったので比較してまとめました。

比較表

	Thanos	Cortex	Mimir
開発元	コミュニティ (元Improbable)	コミュニティ (元Weaveworks)	Grafana Labs
GitHub Stars	~13,800	~5,750	~4,400
ライセンス	Apache 2.0	Apache 2.0	AGPL-3.0
CNCF	Incubating	Incubating	-
データ取り込み	Sidecar (pull) / Receiver (push)	remote_write (push)	remote_write (push)
マルチテナント	限定的 (Receiver経由)	ネイティブ対応	ネイティブ対応
ダウンサンプリング	あり (ネイティブ)	なし	なし
オブジェクトストレージ	S3, GCS, Azure, Swift, COS	S3, GCS, Azure, Swift	S3, GCS, Azure, Swift

Star History

各プロジェクトの特徴

Thanos

コミュニティ主導でCNCF Incubatingプロジェクトになっています。最大の特徴はSidecarパターンで、既存のPrometheusに手を加えずに横に並べる形でデプロイできます。

Cloudflare Tunnelを使っておうちk8sクラスタにアクセスする

Sun, 01 Mar 2026 13:27:12 +0900

Cloudflare Tunnelを使うと、パブリックIPやポート開放なしにKubernetesクラスタ上のサービスをインターネットに公開できます。今回はCloudflare Tunnelの作成から、cloudflare-tunnel-ingress-controllerを使ってKubernetesのIngressリソースで自動的にトンネル経由の公開を行う設定までをまとめました。

Cloudflare Tunnelの仕組み

通常、クラスタ内のサービスを外部に公開するにはパブリックIPの取得やルーターのポート開放が必要です。Cloudflare Tunnelを使うとクラスタ側からCloudflareへアウトバウンド接続を張るだけで、Cloudflare経由で外部からのアクセスを受けられるようになります。

cloudflare-tunnel-ingress-controllerを使うと、KubernetesのIngressリソースを作成するだけで自動的にCloudflare Tunnelのルーティングが設定されます。通常のIngress Controllerと同じ使い勝手でトンネル経由の公開が可能です。

Cloudflare Tunnelの作成

Cloudflareダッシュボードからトンネルを作成します。

ネットワーク > Tunnels に移動し、「トンネルを作成」をクリックします。

トンネル名を入力します。ここでは kkato.app としました。

トンネルが作成されると、環境のセットアップ画面が表示されます。ここに表示されるトンネルトークンを後ほど使います。

作成が完了するとトンネルの概要が表示されます。

Cloudflare APIトークンの作成

cloudflare-tunnel-ingress-controllerがCloudflare APIを操作するためのトークンを作成します。

CloudflareダッシュボードのAPIトークンページにアクセスし、「Create Token」から「Create Custom Token」を選択します。

以下の権限を設定します。

Account / Cloudflare Tunnel / Edit
Zone / DNS / Edit

シークレットをGCP Secret Managerに登録

External Secrets Operatorを使ってGCP Secret ManagerからKubernetesのSecretを自動生成する構成にしています。以下の3つのシークレットを登録します。

echo -n "<your-api-token>" | gcloud secrets create cloudflare-api-token --data-file=-
echo -n "<your-account-id>" | gcloud secrets create cloudflare-account-id --data-file=-
echo -n "<your-tunnel-name>" | gcloud secrets create cloudflare-tunnel-name --data-file=-

アカウントIDはCloudflareダッシュボードのURLやトンネルトークンのデコード結果から確認できます。

PostgreSQL Operatorの比較

Fri, 20 Feb 2026 15:00:00 +0900

Kubernetes上でPostgreSQLを運用するためのOperatorが複数存在します。以前どれを選ぶか検討する機会があったので、主要な4つのオペレーターを比較してみました。

比較表

	PGO	CloudNativePG	Zalando	StackGres
開発元	Crunchy Data	EDB / CNCF	Zalando	OnGres
GitHub Stars	4,400	8,000	5,100	1,400
ライセンス (Operator)	Apache 2.0	Apache 2.0	MIT	AGPL-3.0
ライセンス (コンテナイメージ)	独自 (制限あり)	Apache 2.0	MIT	AGPL-3.0
Patroni	使用	不使用 (独自実装)	使用 (Patroni開発元)	使用
CNCF	-	Sandbox	-	-

Star History

各オペレーターの特徴

PGO (Crunchy Data)

Crunchy Data社が開発するオペレーターで、Patroniを使ったHAに対応しています。Operator自体のソースコードはApache 2.0ですが、Crunchy Data が配布するコンテナイメージは独自のライセンス（Crunchy Data Developer Program）で提供されています。50名以上の組織では本番利用に有償サブスクリプションが必要になるため、注意が必要です。自前でイメージをビルドすれば回避できますが、手間がかかります。

CloudNativePG

EDBが開発を始め、現在はCNCF Sandboxプロジェクトになっています。Patroniに依存せず、独自のInstance Managerが各Pod内で動作し、Kubernetes APIを直接利用してリーダー選出やフェイルオーバーを行います。ライセンスもOperator・コンテナイメージともにApache 2.0で、制限なく利用できます。Star数も最も多く、コミュニティの勢いがあります。

Argo CDをインストールしてみた

Fri, 20 Feb 2026 11:00:00 +0900

Argo CDはKubernetes向けのGitOpsツールで、Gitリポジトリに置いたマニフェストをクラスタに自動で反映してくれます。今回はHelmを使ってArgo CDをインストールし、リポジトリの接続からApplicationの作成までを試してみました。

Argo CDのインストール

Helm Chartリポジトリを追加します。

helm repo add argo https://argoproj.github.io/argo-helm
helm repo update

argocd namespaceにインストールします。

helm install argocd argo/argo-cd \
  --namespace argocd \
  --create-namespace \
  --version 7.8.13

Podが正常に起動していることを確認します。

kubectl get pods -n argocd

Argo CD UIにアクセスする

port-forwardでArgo CDのUIにアクセスできます。

kubectl port-forward svc/argocd-server -n argocd 8080:443

ブラウザで http://localhost:8080 にアクセスします。

初期パスワードは以下のコマンドで取得できます。ユーザー名はadminです。

kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d

Gitリポジトリを接続する

Argo CDがGitリポジトリからマニフェストを取得するために、リポジトリの接続設定が必要です。

SSH鍵の作成

Argo CD専用のSSH鍵を作成します。

ssh-keygen -t ed25519 -f ~/.ssh/argocd -C "argocd" -N ""

GitHubにDeploy Keyを登録

生成した公開鍵をリポジトリのDeploy Keyとして登録します。

Kubernetesをv1.30からv1.31にアップグレードした

Sat, 24 Jan 2026 20:11:09 +0900

自宅で運用しているKubernetesクラスターをv1.30からv1.31にアップグレードしました。 kubeadmを使った標準的なアップグレード手順ですが、忘れがちなので備忘録として残しておきます。

公式ドキュメント: https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/

コントロールプレーンノードのアップグレード

コントロールプレーンノードから順番にアップグレードしていきます。

パッケージリポジトリの変更

まず、yumリポジトリの設定ファイルをv1.31用に変更します。

変更前（v1.30）:

[kkato@nuc01 ~]$ cat /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://pkgs.k8s.io/core:/stable:/v1.30/rpm/
enabled=1
gpgcheck=1
gpgkey=https://pkgs.k8s.io/core:/stable:/v1.30/rpm/repodata/repomd.xml.key
exclude=kubelet kubeadm kubectl cri-tools kubernetes-cni

変更後（v1.31）:

$ cat /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://pkgs.k8s.io/core:/stable:/v1.31/rpm/
enabled=1
gpgcheck=1
gpgkey=https://pkgs.k8s.io/core:/stable:/v1.31/rpm/repodata/repomd.xml.key
exclude=kubelet kubeadm kubectl cri-tools kubernetes-cni

参考: https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/change-package-repository/

kubeadmのアップグレード

まずkubeadmパッケージをアップグレードします。

sudo yum upgrade kubeadm --setopt=disable_excludes=kubernetes

アップグレード可能なバージョンを確認します。

sudo kubeadm upgrade plan

Components that must be upgraded manually after you have upgraded the control plane with 'kubeadm upgrade apply':
COMPONENT   NODE      CURRENT   TARGET
kubelet     nuc01     v1.30.1   v1.31.14
kubelet     nuc02     v1.30.1   v1.31.14
kubelet     nuc03     v1.30.1   v1.31.14
kubelet     nuc04     v1.30.1   v1.31.14

Upgrade to the latest stable version:

COMPONENT                 NODE      CURRENT    TARGET
kube-apiserver            nuc01     v1.30.4    v1.31.14
kube-controller-manager   nuc01     v1.30.4    v1.31.14
kube-scheduler            nuc01     v1.30.4    v1.31.14
kube-proxy                          1.30.4     v1.31.14
CoreDNS                             v1.11.1    v1.11.3
etcd                      nuc01     3.5.12-0   3.5.24-0

You can now apply the upgrade by executing the following command:

        kubeadm upgrade apply v1.31.14

アップグレードを実行します。

Helmコマンドまとめ

Sat, 27 Dec 2025 09:37:48 +0900

HelmはKubernetes向けのパッケージマネージャーで、複雑なアプリケーションのデプロイを簡単にしてくれるツールです。 Helmコマンドをよく忘れてしまうので、基本的なコマンドを備忘録としてまとめました。

リポジトリの追加

# リポジトリを追加する
helm repo add stable https://charts.helm.sh/stable
helm repo add bitnami https://charts.bitnami.com/bitnami

リポジトリの一覧表示

# 追加されているリポジトリを確認する
helm repo list

リポジトリの更新

# リポジトリのインデックスを更新する（新しいチャートバージョンを取得）
helm repo update

チャートの検索

# リポジトリからチャートを検索する
helm search repo nginx
helm search repo mysql

チャート情報の表示

# チャートの詳細情報を表示する
helm show chart bitnami/nginx
helm show values bitnami/nginx

インストール

# チャートをインストールする
helm install my-nginx bitnami/nginx

# 名前空間を指定してインストール
helm install my-nginx bitnami/nginx -n production --create-namespace

# カスタム値でインストール
helm install my-nginx bitnami/nginx --set service.type=LoadBalancer

リリース一覧の表示

# インストール済みのリリースを表示する
helm list

# 全ての名前空間のリリースを表示する
helm list -A

# 特定の名前空間のリリースを表示する
helm list -n production

リリース情報の確認

# リリースの詳細情報を表示する
helm get all my-nginx

# リリースの設定値を表示する
helm get values my-nginx

# リリースの履歴を表示する
helm history my-nginx

アップグレード

# リリースをアップグレードする
helm upgrade my-nginx bitnami/nginx

# 新しい値でアップグレード
helm upgrade my-nginx bitnami/nginx --set image.tag=1.21.0

ロールバック

# 前のバージョンにロールバックする
helm rollback my-nginx

# 特定のリビジョンにロールバックする
helm rollback my-nginx 2

アンインストール

# リリースを削除する
helm uninstall my-nginx

# 名前空間を指定して削除
helm uninstall my-nginx -n production

ドライラン

実際にはインストールせずに、何が実行されるかを確認できます。

kubectlで全てのリソースをgetする方法

Mon, 11 Aug 2025 13:02:00 +0900

kubectl get allだとCustom Resourceが表示されないので、全てのリソースが表示できずに困ることがありました。kubectl api-resourcesを使えば、Custom Resourceを含めた全てのリソースを表示することができます。

全てのリソースを表示する

以下のコマンドで、特定のnamespaceに存在する、全てのリソース(Custom Resourceも含めて)を表示することができます。

kubectl get $(kubectl api-resources --verbs=list --namespaced -o name | grep -v "events" | tr '\n' ',' | sed 's/,$//') -n openebs

kubectl api-resources: クラスター内のCustom Resourceを含む全てのKubernetesリソース名を表示
--verbs=list: list操作が可能なものに絞る
--namespaced: 名前空間に属するリソース名に絞る (NamespaceやNodeなどのcluster-scopedリソースは対象外)
-o name: kubectlでgetできるリソース名だけを出力
grep -v "events": eventsリソースは大量に出力されてしまうため、除外する
tr '\n' ',': 出力されたリソース名を、改行区切りからカンマ区切りに変換
sed 's/,$//': 末尾に付いてしまった余分なカンマを削除

kubectlとjqコマンドの便利な組み合わせ

Sun, 10 Aug 2025 19:52:30 +0900

jqコマンドとは、JSON形式のデータを処理・変換するためのコマンドです。普段はkubectlやAWS CLIと組み合わせて使うことが多いのですが、使い方やオプションをきちんと調べたことがなかったため、改めておさらいしようと思います。

keys関数

これまではjq '.'のように全階層をまとめて表示してキーを把握していましたが、keys関数を使うと一階層ずつキーを表示できます。

# labelのキーを取得する
kubectl get pod my-pod -o json | jq '.metadata.labels | keys'

select関数

select関数は条件にマッチした項目のみを抽出します。

# Running状態ではないPodの一覧を取得する
kubectl get pods -A -o json | jq '.items[] | select(.status.phase != "Running") | .metadata.name'

# namespace、Pod名、Podの状態も合わせて表示する
kubectl get pods -A -o json | jq -r '.items[] | select(.status.phase != "Running") | "\(.metadata.namespace) \(.metadata.name) \(.status.phase)"' | column -t

2つ目のコマンドではいくつかのオプションや機能を使っているため、それらについて説明します。

-r: ダブルクォートを削除するオプション(デフォルトでは"が付いてくる)
"\(filter)": 文字列の中で \(filter) を使うことで、抽出した値を文字列に埋め込める。これにより、複数の値を空白区切りで1行に表示できる
columnt -t: columnコマンドの-tオプションを使うことで、区切り文字を基準に列を揃えて表形式で表示できる

contains関数

contains関数は指定した文字列が含まれていればtrueを返します。

# コンテナ名に'ghr.io'を含むPodを検索する
kubectl get pods -o json | jq '.items[] | select(.spec.containers[].name | contains("gcr.io")) | .metadata.name'

まとめ

kubectl と jq の組み合わせは業務でよく使っていたものの、正直ちゃんと理解できていなかった部分も多かったので、今回改めておさらいできてよかったです。特に keys や select、contains などの関数を使うと、複雑な JSON から必要な情報をサクッと抜き出せるのが便利だなと感じました。

NUC上にk8sクラスタを構築する

Wed, 05 Jun 2024 21:20:47 +0900

しばらく放置していたNUC上にk8sをインストールして、おうちクラスタを運用していこうと思います。今回はkubeadmを使ってk8sをインストールしようと思います。

前提

ベアメタル(Intel NUC11PAHi5)上に構築
Control Planex1台とWorkerx3台の4台構成
OSはRocky Linux9.3
ルーター側の設定で固定IPを割り当て
各ノードのスペックは以下

CPU	メモリ	ストレージ
4コア	16GB	500GB

kubeadmのインストール

以下の手順を参考にします。

kubeadmのインストール

「始める前に」にSwapがオフであること、と記載がありますが、swapがオフになっていなかったので無効化します。

sudo swapoff -a

ポートの開放

kubernetesのコンポーネントが互いに通信するために、これらのポートを開く必要があります。 RockyはRHEL系なのでfirewall-cmdを使って、Control Planeノードのポートを開放します。

sudo firewall-cmd --add-port=6443/tcp --permanent
sudo firewall-cmd --add-port=2379-2380/tcp --permanent
sudo firewall-cmd --add-port=10250/tcp --permanent
sudo firewall-cmd --add-port=10257/tcp --permanent
sudo firewall-cmd --add-port=10259/tcp --permanent

ポートが開放されたことを確認します。

sudo firewall-cmd --reload
sudo firewall-cmd --list-ports

続いて各Workerノードのポートを開放します。

sudo firewall-cmd --add-port=30000-32767/tcp --permanent
sudo firewall-cmd --add-port=10250/tcp --permanent

ポートが開放されたことを確認します。

sudo firewall-cmd --reload
sudo firewall-cmd --list-ports

コンテナランタイムのインストール

コンテナランタイムの手順を参考に、各ノードに設定をしていきます。

Alertmanagerのwebhookを試してみる

Sun, 13 Aug 2023 13:11:42 +0900

Kubernetes上でAlertmanagerがちゃんと通知できるか、どんな内容が通知されているのか確認してみようとすると、連携するためのSlackが必要であったり、Emailを送信するにもメールサーバが必要だったりと、意外と気軽に試せないということがありました。

なので、今回はwebhookの機能を使ってNginxにリクエストを飛ばし、リクエストの内容をログから確認してみようと思います。

webhookとは?

Alertmanagerのreceiverには以下が指定できます。

Webhookとは特定のエンドポイントに対してHTTP POSTリクエストでアラートの情報を送信するというものです。外部サービスではないので、自分自身でエンドポイントを用意し、自分自身で後続の処理を実装する必要があります。

例えば、以下のように設定します。

receivers:
- name: "nginx"
  webhook_configs:
  - url: 'http://nginx-svc.default:8080/'

webhookの連携先としてnginxを使う

今回はwebhookの連携先としてnginxを使用します。

nginxを使って実現したいことは以下のとおりです。

エンドポイントを用意する
リクエスト内容を確認する

nginx.confの初期設定をベースにしていますが、そのままだとリクエスト内容を確認することができないので、設定を追加しました。 log_formatで$request_bodyを指定し、/にアクセスした時に$request_bodyがログとして標準出力に出るように設定しています。

しかし、$request_bodyを有効化するにはproxy_passなどの後続処理が必要になります。なので、proxy_passで/trashというエンドポイントにリクエストを転送し、/trashで特に意味のない処理(1x1ピクセルのgifを返す)をしています。

The variable’s value is made available in locations processed by the proxy_pass, fastcgi_pass, uwsgi_pass, and scgi_pass directives when the request body was read to a memory buffer.

http://nginx.org/en/docs/http/ngx_http_core_module.html#var_request_body

user  nginx;
worker_processes  auto;

error_log  /var/log/nginx/error.log notice;
pid        /var/run/nginx.pid;


events {
    worker_connections  1024;
}


http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    # -------------------追加設定---------------------
    log_format  postdata escape=none $request_body;

    server {
        listen   8080;
        location / {
            access_log /dev/stdout postdata;
            proxy_pass http://127.0.0.1:8080/trash;
        }
        location /trash {
            access_log off;
            empty_gif;
            break;
        }
    }
    # ----------------------------------------------

    sendfile        on;
    #tcp_nopush     on;

    keepalive_timeout  65;

    #gzip  on;

    include /etc/nginx/conf.d/*.conf;
}

上記の設定をConfigMapとして作成し、nginxのPodに対してConfigMapをマウントしてあげます。nginx-svcというServiceも作成します。

KubernetesのCronJobが失敗したときにアラートをあげる

Tue, 08 Aug 2023 19:48:39 +0900

CronJobは、指定したcronフォーマットに基づいて定期的にJobを実行するという機能です。主にバックアップの取得やメール送信など、定期的な処理を実行する際に便利です。

一方で、CronJobが失敗した際にどのように検知すべきかについては、あまり情報がありませんでした。なので、今回はそちらについて考えてみたいと思います。

kube-state-metricsを活用する

kube-state-metricsとはKubernetesクラスタ内のリソースの状態をメトリクスとして提供してくれるというものです。 kube-state-metricsではCronJobやJobの状態をメトリクスとして取得することができます。この方式採用している記事が多かったので、こちらで検討を進めてみたいと思います。

※記事

どのメトリクスを使い監視するか

CronJobはcronフォーマットで指定された時刻にJobを生成し、そのJobがPodを生成するという3層の親子構造になっています。また、CronJobとJobの関係は1対多で、JobとPodの関係は1対多になります。

Jobが完了するのはcompletions個のPodが正常終了した場合、もしくはbackoffLimit個のPodが異常終了した場合に限ります。

completions
- completions個のPodが成功すると、Jobが完了したとみなされる
- デフォルトは1
backoffLimit
- 失敗したと判断するまでの再試行回数で、この回数を超えるとJobは失敗とみなされる
- デフォルトは6

そして、アラートを上げたいのはJobが失敗した時です。言い換えると、backoffLimit個のPodが異常終了したときにアラートを上げるということになります。何個のPodが異常終了したのか監視することも可能だと思いますが、ここではJobのステータスを監視するのが適切かと思います。

メトリクス	対応する項目	説明
kube_job_status_succeeded	.status.succeeded	Jobの管理下で正常終了したPodの数
kube_job_status_failed	.status.failed	Jobの管理下で異常終了したPodの数
kube_job_complete	.status.conditions.type	Jobが成功したかどうか
kube_job_failed	.status.conditions.type	Jobが失敗したかどうか

参考: https://github.com/kubernetes/kube-state-metrics/blob/main/docs/job-metrics.md

Jobに関するメトリクスは複数ありますが、この中でも特にkube_job_failedを使ってアラートを上げるのが良さそうです。以下の設定だと、Jobが失敗したときにアラートが上がります。

kube_job_failed > 0

アラートが発火し続けてしまう問題

失敗したJobは削除されずに残り続けるので、アラートが発火し続けてしまいます。なので、JobのttlSecondsAfterFinishedを設定し、数分後にJobが削除されるようにします。

ttlSecondsAfterFinished
- 指定秒後にJobを削除できる

CronJobのfailedJobsHistoryLimitを設定するという方法も思いつきましたが、0にしてしまうとそもそもアラートが上がらないと思うので、こちらは1のままにしておきました。

failedJobsHistoryLimit
- 失敗したJobを指定個数分残しておける
- デフォルトは1

まとめ

今回はkube-state-metricsを活用して、CronJobが失敗した時のアラートを設定しました。CronJob失敗時にアラートを上げる方法についてはあまり参考になる記事がなく、私なりに考えてみました。他にもっといい方法をご存知の方は教えていただけるとありがたいです。

kubesprayでk8sクラスタを構築する

Mon, 01 May 2023 10:07:31 +0900

k8s構築ツールはいろいろありますが、公式ドキュメントでは以下が紹介されています。

学習環境
- Minikube
- Kind
プロダクション環境
- kubeadm
- kops
- kubespray

※各ツールの違いについてはこちら

今回はその中でもkubesprayというツールを使ってk8sクラスタを構築してみようと思います。kubeadmは1台ずつインストールを実施するのに対し、kubesprayはAnsibleを使い、各ノードで一斉にインストールを実施します。なので、kubesprayは台数が多いときに便利です。

ちなみに、kubesprayは内部でkubeadmを使っているので、kubespray = kubeadm + Ansibleという感じです。また、kubesprayを使うと、コンテナランタイム(デフォルトはcontainerd)やPod間通信のネットワークプラグイン(デフォルトはcalico)などが自動でインストールされるので、非常に便利です。

構築

前提:

ベアメタル(Intel NUC11PAHi5)上に構築
Control Planex1台とWorkerx3台の4台構成
OSはRocky Linux9.1
ルーター側の設定で固定IPを割り当て
各ノードのスペックは以下

CPU	メモリ	ストレージ
4コア	16GB	500GB

ssh公開認証の設定

手元のPCからパスワードなしでssh接続できるように公開鍵認証の設定をします。 ssh-keygenのパスワードには空文字を指定します。

kkato@bastion:~$ ssh-keygen
kkato@bastion:~$ scp ~/.ssh/id_rsa.pub 192.168.10.xxx:~/

公開鍵の情報を各ノードのauthorized_keysに追記します。

kkato@nuc01:~$ mkdir ~/.ssh
kkato@nuc01:~$ chmod 700 /.ssh
kkato@nuc01:~$ cat id_rsa.pub >> ~/.ssh/authorized_keys
kkato@nuc01:~$ chmod 600 ~/.ssh/authorized_keys

/etc/hostsの編集

手元のPCから各ノードへホスト名で接続できるように、/etc/hostsを編集します。

kkato@bastion:~$ cat /etc/hosts
---
192.168.10.121 nuc01
192.168.10.122 nuc02
192.168.10.123 nuc03
192.168.10.124 nuc04

ユーザーの設定

各ノードのユーザーがパスワードなしでsudo実行できるよう設定します。

Raspberry Pi上にk8sクラスタを構築する

Sun, 23 Apr 2023 16:13:42 +0900

最近ラズパイを手に入れたので、kubeadmを使ってk8sクラスタを組んでみたいと思います。 Control Planeノードx1 Workerノードx3の構成です。

準備

準備したものは以下のとおりです。

アイテム	個数
Raspberry Pi 4 Model B / 4GB	4
Raspberry Pi PoE+ HAT	4
ケース	1
microSD 64GB	4
スイッチングハブ	1
LANケーブル 0.15m	4
LANケーブル 1m	1
SDカードリーダー	1
HDMI変換アダプター	1

PoE(Power over Ethernet)+ HATを使うと、LANケーブルから電源供給できるのでとても便利です。今回はPoE+ HATを使っているので、スイッチングハブもPoE対応のものを購入しています。ラズパイのOSをSDカードにインストールする必要があるので、SDカードリーダーも購入しました。あとは、ディスプレイと繋ぐときにmicro HDMIに変換するためのアダプタも購入しました。

OSの設定

OSのインストール

手元のPCはUbuntu 22.04 LTSなので、以下のコマンドでRaspberry Pi Imagerをインストールします。

$ sudo apt install rpi-imager

そして、microSDカード4枚全てにUbuntu Server 22.10 (64-bit)を焼きます。

$ rpi-imager

microSDカードを差し込み、ディスプレイ(micro HDMI)とキーボード(USB)を接続し、OSの初期設定を行います。初期ユーザー名とパスワードはubuntuです。パッケージを最新にしておきます。

$ sudo spy update
$ sudo apt upgrade -y

新しくユーザを作成し、ユーザにsudo権限を付与します。sudoをパスワードなしでできるように追加の設定もします。

Kubernetes on kkato.dev

Prometheusリモートストレージの比較

比較表

Star History

各プロジェクトの特徴

Thanos

Cloudflare Tunnelを使っておうちk8sクラスタにアクセスする

Cloudflare Tunnelの仕組み

Cloudflare Tunnelの作成

Cloudflare APIトークンの作成

シークレットをGCP Secret Managerに登録

PostgreSQL Operatorの比較

比較表

Star History

各オペレーターの特徴

PGO (Crunchy Data)

CloudNativePG

Argo CDをインストールしてみた

Argo CDのインストール

Argo CD UIにアクセスする

Gitリポジトリを接続する

SSH鍵の作成

GitHubにDeploy Keyを登録

Kubernetesをv1.30からv1.31にアップグレードした

コントロールプレーンノードのアップグレード

パッケージリポジトリの変更

kubeadmのアップグレード

Helmコマンド まとめ

リポジトリの追加

リポジトリの一覧表示

リポジトリの更新

チャートの検索

チャート情報の表示

インストール

リリース一覧の表示

リリース情報の確認

アップグレード

ロールバック

アンインストール

ドライラン

kubectlで全てのリソースをgetする方法

全てのリソースを表示する

kubectlとjqコマンドの便利な組み合わせ

keys関数

select関数

contains関数

まとめ

NUC上にk8sクラスタを構築する

前提

kubeadmのインストール

ポートの開放

コンテナランタイムのインストール

Alertmanagerのwebhookを試してみる

webhookとは?

webhookの連携先としてnginxを使う

KubernetesのCronJobが失敗したときにアラートをあげる

kube-state-metricsを活用する

どのメトリクスを使い監視するか

アラートが発火し続けてしまう問題

まとめ

kubesprayでk8sクラスタを構築する

構築

ssh公開認証の設定

/etc/hostsの編集

ユーザーの設定

Raspberry Pi上にk8sクラスタを構築する

準備

OSの設定

OSのインストール

Helmコマンドまとめ