OSS ベースの自宅クラウドの構成

はじめに

クラウドといえば AWS, Azure, GC の 3 大クラウドプロバイダーが主流ですが、現在は様々な機能に特化したクラウドネイティブな OSS プロジェクトが盛んに開発されているため、それらを組み合わせることで自宅でも各ベンダーで提供されているようなサービスと同等の機能を持つクラウド環境を構築することが可能となっています。
今までいくつかのコンポーネント（主に CNCF のプロダクト）を記事にしてきましたが、個々の記事だけでは各コンポーネントが全体の内どのような機能を果たしているか見通しづらい部分もあります。
そこで、この記事では自宅で使用しているものや今まで記事にしたものについて、各コンポーネントを機能毎に分類してそれぞれの役割について俯瞰します。

機能別の分類図

早速ですが自宅で使っているものや記事にしたプロジェクトを機能毎に分類した図が以下になります（一部記事にしていないのも含む）。
各機能 (Provisioning や Monitoring 等) については独自の判断に基づいて設定していますが、CNCF Landscape の分類を参考にしている部分もあります。

機能別のコンポーネントの概要図。
今まで取り扱ったプロジェクトのロゴを並べるとそれっぽい感が出る。

Infrastructure

まず何をするにもコンポーネントを動作させたり作業を行ったりするサーバー(物理 PC や仮想マシンなど)やネットワーク、ストレージ等を備えた環境が必要になります。
自宅では openstack 上で物理 PC に仮想マシンを構成し、その上に kubernetes クラスタを構成し k8s 用の OSS を試す構成にしています。

Openstack

openstack はプライベートクラウド環境を構築するための仮想化プラットフォームです。openstack を利用することで物理 PC の上にスペックの許す限り複数台のハイパーバイザー型仮想マシンを構築することができます。

https://www.openstack.org/

自宅の環境では minis forum のミニ PC 上で All-in-One の openstack を構築し、検証用の仮想マシンを動かしたり消したりしています。
openstack にもいくつか構築手段がありますが、 docker コンテナ化された openstack コンポーネントを Ansible でインストールする kolla ansible を使うのが一番楽かと思います。

Kubernetes

言わずと知れたコンテナオーケストレーションのスタンダードです。有名なので説明は割愛。

https://kubernetes.io/

Provisioning

ここでの Provisioning は上記の openstack 上に VM やそれに付随するリソースを作成する作業を指します。様々な検証や運用を行う際には影響を最小限に抑えるため個々の環境を分離することが望ましいです (要らなくなったらすぐに削除して作り直せるし、既存の環境に影響が出ると復旧が面倒なため)。しかし、その度に VM の作成、削除や依存ツールのインストールを手作業で行うのは面倒なので処理を自動化する必要があります。
Provisioning や IaC の分野で広く使われている Ansible や Terraform には主に次のような特徴があります。

• 宣言的にリソースや処理を記述できる。
• 処理を何回やっても同じ結果が得られることが前提 (冪等性)。
• module が豊富に用意されているため処理を 1 から作る手間が少ない。大抵は標準の処理や community が管理しているモジュールやプラグインで対応可能。

自分で必要な処理を行うスクリプトみたいなものを書いてもいいのですが、上記の性質から処理の追加や管理が容易なので自宅の環境構築ではこれらを使っています。

Terraform

Terraform は IaC を実現するための有名なプロダクトです。Terraform Openstack provider を使うことで Openstack 上で仮想マシン等のリソースを作成できるので、予め決まったスペック、フレーバー、floating IP address 等のプロパティを指定した仮想マシンを作成したり、不要になった際にまとめて削除できます。

Ansible

検証用に作成した仮想マシンで検証用ツールのインストールやデバッグの効率化のための設定（シェル補完やホストの名前解決の設定など）を行うのに Ansible が有効です。

https://docs.ansible.com/

terraform でソフトウェアやミドルウェアの Provisioning を行うのは（できなくもないが）不便な点があるので、インフラの構築は terraform, ソフトウェア、ミドルウェアのセットアップやその他汎用的な自動化処理は Ansible というように使い分けています。

Repository

Repository はコードや資料、コンテナイメージの保管に使用します。

Gitlab

ソースコードなどを保存する git レポジトリ。有名なので説明は割愛。

Gitea

https://about.gitea.com/
https://github.com/go-gitea/gitea

ソースコードなどを保存する Go 製の git レポジトリ。gitlab と比較すると軽量、内部コンポーネントが少なくすっきりしているため管理が容易などのメリットがある。gitlab ほどの多機能が不要な場合は gitea を使用するのもおすすめ。

Distribution

コンテナイメージを保管するためのプライベートレジストリ。元々は docker registry という名前でしたが、管理団体が CNCF に変わった際に Distribution という名称に変更されたようです。
docker で構築できるので、手っ取り早くプライベートレジストリを構築、使用する場合はこちらを使っています。

https://distribution.github.io/distribution/

Harbor

harbor もコンテナイメージを保管するためのプライベートレジストリです。イメージ補完のコアな機能分は Distribution と同じですが、web UI やアクセスコントロール、イメージの脆弱性スキャンツールの統合など本番環境にも使える様々な機能がついています。docker や kubernetes で利用可能。

https://goharbor.io/

CI/CD

ここではビルド、テスト等の integration や対象環境へのデプロイを包括的に行えるツールやプラットフォームを CI/CD に分類しています。

Concourse

Concourse はクラウドネイティブな CI/CD プラットフォームであり、Github Action や CircleCI のようにコマンドベースで実行する処理を記述することで CI/CD を実現できます。

https://concourse-ci.org/

concourse について書いた記事は以下を参照。

• OSS ワークフローツール Concourse を使ってみる
• ローカル環境に簡易 CI/CD 環境を構築して試す

Tekton

Tekton もクラウドネイティブな CI/CD プラットフォームであり、コマンドベースで実行する処理を記述することで CI/CD を実現できます。

https://tekton.dev/

tekton について書いた記事は以下を参照。

• ローカル環境に簡易 CI/CD 環境を構築して試す tekton 編

Argocd

Argocd も k8s で GitOps の理念に基づいたデプロイを実現するのにおなじみのツールです。

https://argoproj.github.io/cd/

Flagger

k8s へのデプロイについて、少なくとも自宅環境ではマニフェストの手動デプロイや helm, Argocd 等を使ったデプロイで充分ですが、 Canary デプロイや Blue/Green デプロイ等のより高度なデプロイを試してみたい場合は Flagger が使用できます。

https://docs.flagger.app/

flagger について書いた記事は以下を参照。

• Flagger による k8s アプリケーションの Blue/Green デプロイ

Stackstorm

stackstorm はイベント駆動形で様々な処理や連携を行うワークフローエンジンです。CI/CD 専用というよりはもう少し汎用的な処理の自動化として利用できますが、イメージのビルドやテスト、デプロイ等も作り込むことによって可能なためここでは CI/CD に分類しています。

https://stackstorm.com/

stackstorm について書いた記事は以下を参照。

• イベント駆動ワークフローエンジン stackstorm を試す

Gitlab CI/CD

https://docs.gitlab.com/ee/ci/

Gitlab にも CI/CD がデフォルトで備わっており、リポジトリに ci/cd 用の yaml を配置することで実行可能。runner を用意すれば追加のセットアップなしで使用できるため、高度な CI/CD 機能が不要な場合は gitlab CI/CD で済ませてしまう方法も有効です。github と同様に secret や variable の保管、パイプラインで参照する変数をリポジトリと統合できるメリットがある一方、CD の部分は工夫する必要があります。

Gitea Actions

https://docs.gitea.com/usage/actions/overview

Gitea では github runner に似た gitea act runner が備え付けられており、yaml 形式で記述した CI/CD ジョブが実行できる他、パブリックな Github Actions をダウンロードして利用できます。yaml は github workflow と同様の形式で記述できるため、既に workflow に慣れている場合や gitea をメインに使用している場合は有力な選択肢になります。

Observability

クラウドの環境では多数の VM やコンテナといったワークロードが動作するため、それらが正常に動作することを保証するためにモニタリングが不可欠となります。

Logging

言うまでもないですがエラー発生時の原因分析、トラブルシュートやイベントの監視など様々な面でログ収集が重要です。基本的には VM や k8s に Logging エージェントを入れて別のログ監視基盤で一元管理する構成が基本になるかと思います。
Logging エージェントもいろいろ選択肢はありますが、以前の記事では Elastic stack の一部である Filebeat を使った方法について紹介しました。

• Filebeat による k8s クラスタ Logging

Metrics

メトリクスも CPU, メモリ、ストレージ使用率やネットワークの IN/Out などワークロードの使用状況や状態変化を監視するのに重要です。
メトリクス収集エージェントもこれまた色々選択肢がありますが、現在は各種 exporter で公開されたメトリクスを prometheus を使って収集する方式が広く使われている印象があります。
以前の記事では prometheus と thanos で k8s のクラスタを収集する方式について記載しました。

• Prometheus, Thanos による k8s クラスタ Metrics

Tracing

Tracing では opentelemetry を使って tracing データの収集を行い、jaeger で可視化する構成が広く使われている印象があります。記事は以下。

• Opentelemetry, Jaeger による k8s クラスタ Tracing

Profile

Observability の分野における Profile は継続的プロファイリング (Continuous Profiling) とも呼ばれ、アプリケーションのメモリや CPU 使用量、その他の情報を継続的に監視、分析する際に活用されます。アプリケーション全体のメモリや CPU などのリソース使用量はメトリクスで収集可能ですが、profile ではアプリケーション内の関数やパッケージ単位で使用されるリソースまで収集することができ、ボトルネックとなっている処理の特定や時間的にリソース消費が悪化する事象への対応など、特にアプリケーションを継続的に改善していく際に有用となります。
継続的プロファイリングが可能なものも様々な選択肢がありますが、Grafana が管理する OSS の Pyroscope について使用した際の記事を以下にまとめました。

• Pyroscope による継続的プロファイリングを試す

Other

従来は Logging や Metrics などの Observability の基本要素ごとに特化したソフトウェアを組み合わせて運用する構成が一般的でしたが、近年ではこれらの要素を包括的に収集・監視できるソリューションも増えてきています。例えば前述の OpenTelemetry では、Logging、Metrics、Tracing、Profiling といった要素を OpenTelemetry だけで収集・管理できるよう開発が進められています。

https://opentelemetry.io/docs/specs/status/

要素ごとに異なるソフトウェアを使う代わりに一元的なプラットフォームを活用することで、以下のようなメリットが期待できます。

• ソフトウェアごとの学習・導入・管理コストを削減できる
• データの収集、加工、管理、分析を 1 つのプラットフォームで統合的に運用できる
• 別ソフトウェアを横断しなくて良いため、情報検索やトラブルシュートが用意になる可能性がある

もちろん Logging における Filebeat のように各分野に特化した従来のソフトウェアは長年使用されているため、機能の豊富さや安定性がある、ノウハウが蓄積されているといった優位性があります。そのため、一元管理型のソリューションがすべてのケースにおいて最も良い選択肢になるわけではありませんが、それでもユーザー数の多さやコミュニティの大きさ、活発に開発されているか等の要素も考慮して利用を検討する価値はあると思います。

Vector

Observability の基本はデータの収集、構造化やタグ付け、ノイズ除去などの加工、可視化プラットフォームへ出力して監視・分析が基本的な処理の流れになりますが、Vector はこの一連の処理を Observability data pipeline として一元的に管理できるアプリケーションです。

https://vector.dev/

中間のデータ加工・変換部分が vector の主な担当範囲となっていますが、Prometheus や Opentelemetry などの 43 種類の Source からの入力、Datadog や AWS CloudWatch など 59 種類の出力に対応しているため、他のシステムとの統合性にも優れ、end-to-end の Observability 基盤を構築することができるようになっています。
現時点では Log, Metric に対応、Tracing は未対応とのこと。

Filebeat で収集したログを Vector で加工し、Elasticsearch, OpenObserve に出力する構成については以下で検証した記事を書きました。

https://zenn.dev/zenogawa/articles/k8s_vector_logging

Data Storage

Observability 内の各要素はデフォルトではデータを長期間保存するようになっていないものが多いため、収集したデータを長期間保存したり、一元管理・参照するためにはデータを保管するデータストレージが必要となります。
とはいっても、例えば filebeat の場合は elasticsearch でデータ保存する等、保存先としてよく用いられるデータストレージには定番のものが決まっているため、特に理由がない限りはそちらを使うのが良いと思われます（情報検索が容易なため）。

Elasticsearch

Logging の filebeat と tracing の jaeger に関してはデフォルトで Elasticsearch への送信をサポートしているため、データ保存先には Elasticsearch がおすすめです。
Elasticsearch 自身も強力な検索や分析、aggregation 機能を持ち、後述の kibana との連携で参照や可視化が可能です（機能が豊富すぎて使うのが大変ですが）。

https://www.elastic.co/jp/elasticsearch

Minio

prometheus 自体は 多種の Remote storage への書き込みに対応しており、この中に elasticsearch も含まれています。
一方、thanos はオブジェクトストレージにデータを長期保存する形式であるため、OSS のオブジェクトストレージである minio が使用できます。
また、minio 自体は S3 互換のオブジェクトストレージなのでメトリクス専門というわけではなく一般的なデータ保存先としても使用できます。

https://min.io/

Rook

本番環境で稼働するような数千 ~ 台の大規模なストレージクラスタを構築・管理するための OSS 分散ストレージシステムで Ceph というものがあります。

https://ceph.io/en/

Rook はこれのクラウドネイティブ版とも言えるようなシステムとなっていて、ceph をストレージプロバイダーとして k8s 上で分散ストレージシステムを構築できます。

https://rook.io/

Ceph Storage Provider
Rook orchestrates the Ceph storage solution, with a specialized Kubernetes Operator to automate management. Rook ensures that Ceph will run well on Kubernetes and simplify the deployment and management experience.

Rook を使うことで以下の主要なストレージを利用できるようになります。

• ブロックストレージ
• オブジェクトストレージ
• 共有ファイルシステム

Rook は CNCF の Graduated project になっていることからその成熟度具合も高いことが伺えます。

Visualization

Observability を考える上での重要な点として、蓄積したデータを必要な時に適切な形式で参照できるということも大切です。
データストレージの種類に応じてよく使用される分析・可視化ツールというのもだいたい決まっているので、こちらも特に理由がない限りはそちらを使うのが良いです。

Kibana

Kibana は elasticsearch とよく組み合わせて使用されます。kibana 自体が Elastic stack のプロダクトの一部であるので elasticsearch との親和性が良く、蓄えられたデータを様々条件で参照・分析できます（こちらも機能が豊富すぎて使うのが大変）。

https://www.elastic.co/jp/kibana

Grafana

Grafana は prometheus (thanos) とよく組み合わされて使用されます。prometheus のメトリクスを検索する PromQL を使用して必要なメトリクスをフィルタしたり独自のダッシュボードを作成して必要な情報のみを柔軟に可視化することが可能です。prometheus の他、Relational DB や Time Series DB など 多種のデータソースにも対応しています。

https://grafana.com/

OpenObserve

OpenObserve は軽量版 Elasticsearch + kibana とも言える位置づけで、log, Metrics, trace データの保存・可視化が可能なプラットフォームになっています。目的を上記に絞ることによって本家 Elasticsearch と比べて学習・運用コストで利用することが可能です。

• k8s 上に OpenObserve を構築してクラスタのログを可視化する

Network

Traefik

Traefik proxy はモダンで多機能な OSS の proxy サーバーです。nginx のように別サーバーへの proxy や負荷分散、ユーザー認証を行うことができ、k8s で使用する場合は ingress controller としても使用できます。nginx から web サーバーの機能を抜いた代わりに構成を yaml で設定することで管理しやすくしたような使用感となっています（あくまで個人の感想）。その他に TCP, UDP, gRPC のプロキシや LoadBalancing の機能の備わっています。

Traefik について書いた記事は以下を参照。

• Kubernetes で Traefik proxy を使う

CoreDNS

CoreDNS は DNS と Service Discovery の機能を持ちます。

https://coredns.io/

kubeadm 等で k8s クラスタを作成するとデフォルトでクラスタ内の DNS に使用されますが、別途構築して DNS サーバーとしても使用することができます。

Linkerd

Linkerd は k8s クラスタ内の Service mesh を実現するための proxy です。

https://linkerd.io/

Service mesh の分野では Istio が有名ですが、linkerd も CNCF Graduated project となっているためプロジェクトの成熟度は高く、利用者が多いことが伺えます。

Security

近年では DevSecOps のような用語もあるように言わずもがな Security は重要ですが、自宅の環境をネットワークに公開しない場合には正直そこまで気にしなくてもいい感はあります。
とはいえ重要であることは変わりないので、本番での運用を意識するような場合は Security 面にも意識を配る必要があります。

Trivy

Trivy はコンテナイメージの脆弱性検出や IaC、マニフェストファイルの不備をスキャンするための OSS ツールです。

https://trivy.dev/

Trivy について書いた記事は以下を参照。

• Trivy を使って kubernetes のセキュリティについて見てみる

Tetragon

Tetragon は eBPF を使用して対象環境のセキュリティや可観測性を高めるための OSS プロジェクトです。eBPF を利用することでコンテナランタイムのセキュリティ保護、独自ポリシーの適用などを実行し、3 代用ではカバーしきれない領域のセキュリティを貯めることが可能です。記事は以下。

• Tetragon を使って k8s の Observability を強化する

Notary Project

コンテナワークロードが主流になるにつれて、コンテナイメージが信頼できる発行元によって作成されてものであるか、第三者によってイメージが改竄されていないかなどのイメージに関するセキュリティが重要性を増してきました。Notary Project ではコンテナイメージを含む OCI アーティファクトのセキュリティを確保するため、アーティファクトの署名の仕様やツールを管理するためのプロジェクトとなっています。

https://notaryproject.dev/

Ratify

Ratify は OCI アーティファクトの署名を検証するツールです。主に k8s クラスタ上で OPA Gatekeeper と合わせて使用し、pod 作成時にイメージの署名やイメージに対する脆弱性検出結果、SBOM などの OCI アーティファクトを検証することができます。これにより信頼できるイメージのみを k8s クラスタにデプロイすることでセキュリティを強化することができるようになります。

Ratify について検証した記事は以下を参照。

https://zenn.dev/zenogawa/articles/k8s-ratify-signature

Development

Backstage

Backstage はソフトウェアの依存関係やコード、インフラなどを一元に管理するための開発者ポータルを構築する OSS フレームワークです。

https://backstage.io/

管理するツールが増えてくるとそれぞれの依存関係を把握するのが大変になり、開発を進めるために多数の UI やドキュメントを横断する必要があります。Backstage ではそうした情報をポータルと呼ばれる webUI に集約し、開発作業をより効率的に進められるような経験を提供します。
分野としては Platform Engineering に分類され、組織内で複数のチームが複数のソフトウェアを開発しているような場合に各ソフトウェアの依存関係や周辺ツールの情報、管理チームなどを明確にできるといったメリットがあります。また開発者ポータルを構築できる OSS はそれほど多くないため、ベンダーに依存せず無料で使用できる、plugin を自分で開発して機能を拡張できるといった点も強みとなっています。

Backstage について書いた記事は以下を参照。

• 開発における CI/CD 関連の情報を Backstage ポータルに集約する

Other

上記のカテゴリに当てはまらないものは other に分類しています。

Litmus

Litmus は k8s クラスタ上に意図的に障害を注入し、現構成の可用性や回復力を評価するためのカオスエンジニアリングフレームワークとなっています。

https://litmuschaos.io/

カオスエンジニアリングが自宅環境で必要になることはほぼないと思いますが、対象の pod に負荷をかけたり node を落としたりとなかなか面白い動作を試すことができます。
また、大規模な環境で実際にカオスエンジニアリングを取り入れている企業もあるため、それらの雰囲気を掴むためにやってみるのもあり。

Litmus について書いた記事は以下を参照。

• kubernetes 用のカオスエンジニアリングフレームワーク Litmus を試す

k8sGPT

k8sGPT はパプリックサービスやローカルの LLM を利用して k8s クラスタ内のトラブルシュートやセキュリティ強化を補助するサービスです。

https://k8sgpt.ai/

まだ CNCF Sandbox project ではありますが、AI を使って k8s をより効率的に管理していくサービスは目新しいので今後の発展が期待されます。

Identity Management

サービスが増えるにつれてユーザーやグループ、認証情報などの管理はより大変になっていきます。例えば、概要図の中では gitlab, harbor, stackstorm, elasticsearch, minio, grafana が内部てユーザー情報を管理するサービスとなってますが、新しいユーザーを追加したくなった時にそれぞれのアプリケーションに個別にユーザを追加したり、ユーザの役割に応じたロールやパーミッションを設定する、ユーザーのパスワードを更新する際に新しいパスワードを反映させる、不要となったユーザーを各サービスの登録情報から削除するといった作業はかなり面倒な工程になってきます。
そのため、サービスや組織の規模の拡大に合わせて、このようなユーザーやそれに付随するグループ等の情報、アクセス制限といった Identity を効率的に管理するためのアプリケーションの重要性が増してきます。

LDAP

LDAP はサーバー内で管理されるユーザーを効率よくクエリするためのプロトコルであり、これを利用してユーザーや組織を一元管理する機能を持つアプリケーションやソフトウェアは LDAP サーバーと呼ばれます。Active Directory のようにユーザーを一元管理し、ユーザーの固有情報 (~ identity) に基づいて関連サービスと統合することで効率的な運用を実現するのに役立ちます。
LDAP サーバーにはいくつか種類があり、それぞれ機能や特徴が異なります。

• OpenLDAP
• FreeIPA
• 389 Directory Server
• LLDAP

上記のうち LLDAP について書いた記事は以下を参照。

• 軽量 LDAP サーバー LLDAP を試す

Authelia

Authelia は認証・認可サーバー、アクセスコントロール、OpenID Connect によるシングルサインオンなどの機能を有するアプリケーションです。LDAP と組み合わせてユーザーを効率的に管理し、OpenID Connect で各アプリケーションと連携することで管理の手間を軽減することができます。
https://www.authelia.com/

Authelia について書いた記事は以下を参照。

• 認証・認可サーバの OSS Authelia を試すGitHubで開く

Hashicorp Vault

Hashicorp Vault はユーザーのパスワードを始めとした各種機密情報を保管する Secret Manager です。サービスが増えるに連れて管理者ユーザーのパスワードやサービス間認証に使用する情報、証明書、トークンなど厳密に扱うべき情報も増えますが、それらを一元的に管理・保護することができます。

https://developer.hashicorp.com/vault

Vault について書いた記事は以下を参照。

• kubernetes 上に HashiCorp vault を構築して機能を試す

Multi-cluster Management

シンプルな構成や運用の場合は単一のクラスタで充分なケースも多いですが、より大きなワークロードを運用していく場合、複数の k8s クラスタを合わせて運用するマルチクラスタや複数のクラウド上のクラスタを利用するマルチクラウド、ハイブリッドクラウドなど、複数のクラスタを扱うような需要も増えています。複数のクラスタを利用することでスケジューリングの最適化、災害対策、可用性の向上など多くのメリットがありますが、その一方で同時に管理対象が増えることによる管理の複雑さも増してきます。そのため、複数のクラスタを効率的に管理するツールが重要になってきます。
主要クラウドではそのクラウドのマネージド k8s サービスを利用することが想定されているため複数クラスタを管理できる機能は少ないですが、一方で OSS ではベンダーロックインを避けるためか様々な環境上のクラスタに対応しているプロダクトが多いです（といっても EKS, GKE, AKS, オンプレクラスタ(ベアメタルクラスタ)が多いですが）。

Rancher

Rancher は複数クラスタの管理やクラスタの作成、リソースの監視などを行うための統合的なプラットフォームです。

https://www.rancher.com/

主要パブリッククラウドのマネージドクラスタサービスやベアメタルクラスタなどにサポートしており、クラスタ全体のリソース使用量の監視、ワークロードやネットワーク関連のリソースの一覧表示など各クラスタの使用状況を単一のプラットフォームで一元的に把握・管理できるようになっています。また、kube-metrics-stack や Istio 等の他ツールとも統合されており、メトリクス監視やサービスメッシュ構築など複数のクラスタを運用していく上で必要不可欠な要素も簡単に組み合わせることができます。

Rancher について書いた記事は以下を参照。

• Rancher で複数の k8s クラスタを可視化する

Karmada

Karmada は k8s マルチクラウドおよびマルチクラスタ管理システムです。クラウドプロバイダーに依存せず複数の k8s クラスタを管理でき、複数クラスタへのアプリケーションのデプロイ、クラスタ間 Failover などを実現できます。

https://karmada.io/

Karmada について書いた記事は以下を参照。

• Karmada による k8s マルチクラスタ管理を試す

おまけ

AWS サービスとの対応

紹介した OSS の機能と AWS のサービスを対応付けると表のようになります。
機能的にやや微妙なものは ? にしてます。

OSS	AWS Service	機能
Tekton Concourse	CodeBuild	CI
ArgoCD Flagger	CodeDeploy	CD
GitLab Gitea	CodeCommit, etc	Code Repository
Harbor Distribution	ECR	Container Registry
StackStorm	EventBridge, Step Functions, etc	Event-driven workflow
Kubernetes	EKS	Container orchestration
Rook	EBS S3 EFS	Storage
Minio	S3	Object Storage
Elasticsearch, Kibana OpenObserve	OpenSearch	Distributed search and analytics engine
OpenTelemetry	AWS Distro for OpenTelemetry	Trace
Tetragon	?	eBPF
Pyroscope	CodeGuru Profiler?	Profiler
Ansible	System Manager?	Provisioning
Terraform	CloudFormation, etc	IaC
Trivy	ECR Image Scan, etc	Vulnerability Scanner
Litmus	Fault Injection Service	Chaos Engineering
LDAP	?	Authentication and Authorization
Authelia	Cognito?, IAM?	Authentication and Authorization
Hashicorp Vault	Secrets Manager	Secrets Management
CoreDNS	Route 53	DNS
Linkerd	App Mesh?	Service Mesh
Traefik	ELB?	Proxy, LoadBalancer
Vector	CloudWatch	Logging, Metrics

おわりに

自宅の環境や記事にしてきたコンポーネントを機能別に分類し、それぞれの役割や立ち位置について整理しました。俯瞰的に見ることで各コンポーネントがどの領域の機能をカバーしているのか、どの機能が不足しているのかが視覚的に認識することができます。
クラウドベンダーのサービスは基本的に使う分だけ課金される一方、自宅クラウドはいくら使っても無料です（PC の電気代はかかりますが）。CI/CD や Observability を試してみたいけど費用が気になるという人や自分で手を動かしてサービスの仕組みを理解したい人は自宅クラウドの構成を検討してみるのもいいかもしれません。