kkato.dev

Prometheusはデフォルトでローカルディスクにメトリクスを保存しますが、長期保存やHA構成を実現するためにリモートストレージが必要になります。代表的な選択肢としてThanos・Cortex・Mimirの3つがあり、業務で検討する機会があったので比較してまとめました。 比較表 Thanos Cortex Mimir 開発元 コミュニティ (元Improbable) コミュニティ (元Weaveworks) Grafana Labs GitHub Stars ~14,200 ~5,900 ~5,200 ライセンス 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 各プロジェクトの特徴 Thanos コミュニティ主導でCNCF Incubatingプロジェクトになっています。最大の特徴はSidecarパターンで、既存のPrometheusに手を加えずに横に並べる形でデプロイできます。 各コンポーネントの役割: Sidecar: PrometheusのPodに並べてデプロイするコンテナ。PrometheusがローカルにTSDBブロックをフラッシュするタイミング（2時間ごと）でオブジェクトストレージにアップロードします Store Gateway: オブジェクトストレージ上の過去データを読み出し、クエリに応答するコンポーネント Querier: PromQL互換のクエリエンドポイント。SidecarやStore Gatewayに問い合わせて結果を集約し、Grafanaに返します Compactor: オブジェクトストレージ上のブロックをダウンサンプリング・コンパクションするバックグラウンドプロセス graph LR A[Prometheus + Sidecar] -->|アップロード| B[オブジェクトストレージ] B --> C[Store Gateway] B --> D[Compactor] C --> E[Querier] E --> F[Grafana] ダウンサンプリング（5分・1時間粒度）をCompactorがネイティブでサポートしているため、数年分の長期データを扱う場合でも高速にクエリできます。マルチテナントはReceiverコンポーネント経由で実現できますが、CortexやMimirと比較すると後付けの印象が強いです。 ...

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やトンネルトークンのデコード結果から確認できます。 ...

GitHub Container Registry (ghcr.io) は、GitHub が提供するコンテナイメージのレジストリです。 Public Packages であれば無料で利用でき、GitHub Actions と組み合わせることでデータ転送料金も無料になります。 ghcr.io は2通りの使い方があります。 ローカルから Docker CLI を使ってイメージをビルドしてプッシュする方法 GitHub Actions を使ってコードの変更に合わせて自動でイメージをビルドしてプッシュする方法 今回はGitHub Actions を使って自動でイメージをビルドしてプッシュする方法を紹介します。 GitHub Actions から自動でプッシュする GitHub Actions を使えば、コードをプッシュするだけで自動的にイメージのビルドとプッシュができます。以下はワークフローの例です。 name: Docker Build and Push on: push: branches: - main # GHCR へのプッシュには packages: write が必要 permissions: contents: read packages: write jobs: build-and-push: runs-on: ubuntu-latest steps: # ソースコードをチェックアウト - name: Check out code uses: actions/checkout@v4 # ghcr.io にログイン - name: Log in to GitHub Container Registry uses: docker/login-action@v2 with: registry: ghcr.io username: ${{ github.actor }} # デフォルトの GITHUB_TOKEN を利用 password: ${{ secrets.GITHUB_TOKEN }} # Docker イメージをビルドしてプッシュ - name: Build and push Docker image uses: docker/build-push-action@v6 with: context: . push: true tags: ghcr.io/${{ github.repository }}:latest トラブルシューティング GitHub Actions から ghcr.io にプッシュする際に、以下のようなエラーが出ました。 ...

Kubernetes上でPostgreSQLを運用するためのOperatorが複数存在します。以前どれを選ぶか検討する機会があったので、主要な4つのオペレーターを比較してみました。 比較表 PGO CloudNativePG Zalando StackGres 開発元 Crunchy Data EDB / CNCF Zalando OnGres GitHub Stars ~4,400 ~9,200 ~5,200 ~1,400 ライセンス (Operator) Apache 2.0 Apache 2.0 MIT AGPL-3.0 ライセンス (コンテナイメージ) 独自 (制限あり) Apache 2.0 MIT AGPL-3.0 Patroni 使用 不使用 (独自実装) 使用 (Patroni開発元) 使用 CNCF - Sandbox - - 各オペレーターの特徴 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数も最も多く、コミュニティの勢いがあります。 Zalando postgres-operator Zalando社が開発するオペレーターで、Patroniの開発元でもあります。MITライセンスで制限なく利用可能です。Spilo（PostgreSQL + Patroni をパッケージングしたDockerイメージ）をベースにしています。ただし、CloudNativePGと比較すると開発のペースは落ち着いてきている印象です。 ...

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として登録します。 ...