Kubernetes

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を使うと、パブリック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やトンネルトークンのデコード結果から確認できます。 ...

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は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にアップグレードしました。 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 アップグレードを実行します。 ...