自宅ラボでは Cephadm を使ってラズパイに Ceph クラスタを構築して遊んでます。 今回は Ceph の Zabbix モジュールを使って Zabbix からラズパイ Ceph クラスタを監視できるようにします。 ただモジュールを有効化するだけでは Zabbix から監視できなかったので、手順を残します。 ちなみにラズパイ Ceph クラスタは CentOS/RockyLinux/AlmaLinux 各種 OS を使った混合環境です。 本当はクラスタ構築の話から投稿したかったのですが、モチベの関係で先にこのネタから投稿します。 Zabbix モジュール有効化 Ceph Manager Daemon (MGR) は、モジュールという形でダッシュボード機能や他製品との連携機能を提供しています。 Cephadm 自体も「Orchestrator モジュール」を使って Ceph を管理しているようです。 公式のモジュール一覧は ここ （でいいんですかねぇ…？） MGR のモジュールの中に「Zabbix モジュール」があるので、このモジュールを有効化して使います。 ceph mgr module enable zabbix Zabbix モジュールのパラメータのうち、以下の 2 つを設定します。 zabbix_host: Zabbix サーバのホスト名 identifier: Zabbix に登録する Ceph クラスタ名 ceph zabbix config-set zabbix_host zabbix.example.com ceph zabbix config-set identifier raspi-ceph 今回はその他のパラメータはデフォルト値のまま使いました。 以下のコマンドでパラメータを確認します。...

2021 年も残すところ数日ということで、少し早いですが今年 1 年間の振り返りと来年の抱負を掲げます。 ...

Red Hat が提供するエンタープライズなコンテナ・プラットフォーム「OpenShift」がシングルノードに対応したようです。 Meet single node OpenShift: Our newest small OpenShift footprint for edge architectures The cloud native approach to developing and deploying applications is increasingly being adopted in the context of edge computing. However, edge workloads and use cases span a myriad of locations, technical requirements, and physical footprints. そうとなれば試してみたい欲求が抑えられませんよね？ というわけで要件を満たす機器を選定するところから SNO (Single Node OpenShift) を導入してみました。 ハードウェア要件 SNO をインストールするには以下のスペックが必要です。 プロファイル CPU メモリ ストレージ 最低限 8 vCPU コア 32 GB 120 GB 普通(?...

Ansible AWX バージョン 18.0 から AWX Operator を使うインストール方法に変更されました。 https://github.com/ansible/awx-operator AWX Operator を使うと Kubernetes クラスタへの AWX デプロイが簡単にできます。 標準的な設定では AWX 関連のコンテナをまとめた Pod と一緒に PostgreSQL Pod もデプロイされますが、今回は AWX Operator 管理外の PostgreSQL インスタンスと連携するように AWX をデプロイします。 環境情報 ソフトウェア バージョン Kubernetes 1.21.2 AWX 19.3.0 AWX Operator 0.13.0 Zalando Postgres Operator 1.6.3 AWX Operator AWX Operator は公式の マニュアル 手順通りにインストールしていきます。 特筆する点はないのでマニュアルを参照してください。 PostgreSQL AWX で利用する PostgreSQL インスタンスは Zalando Postgres Operator を使って用意します。 Operator のインストール方法は下記の投稿を参照してください。 Zalando Postgres Operator を試してみた - 勇往邁進 以下の postgresql リソースのマニフェストで、AWX 用の PostgreSQL インスタンスがデプロイされます。...

NGINX Ingress Controller と MetalLB を使った Ingress の構築に失敗していた話です。 背景 自宅ラボの Kubernetes クラスタでは、NGINX Ingress Controller と MetalLB をデプロイしています。 これらを使って、Ingress リソースに NGINX Ingress Controller 向け LoadBalancer Service の External-IP を割り当てて、各種サービスを Ingress 経由で公開しています。 一方、Kubernetes クラスタとは別に自宅ラボ用の DNS サーバを構築しており、夏季休暇中に CoreDNS から PowerDNS に入れ替える作業をしました（この話は別途投稿したいと思います）。 するとどうでしょう、DNS サーバの入れ替え作業後に Ingress で公開していたサービスに接続できなくなってしまいました。 状況 Ingress リソースを確認したところ、設定されている IP アドレスが想定していたアドレスと異なっていました。 想定アドレスは上述の通り「NGINX Ingress Controller 向け LoadBalancer Service の External-IP」です。 しかし、実際には「Kubernetes クラスタの Worker Node の IP アドレス」が設定されていました。 $ kubectl get ingress -A NAMESPACE NAME CLASS HOSTS ADDRESS PORTS AGE argocd argocd-server-ingress <none> argocd-ingress....

(2021/5/18 追記) Operator のインストールしかしてないじゃん、ってことでタイトル変更しました。 実際に Operator で構築した Minio を試して、続編として投稿したいと思います。 前回の投稿から 3 ヶ月ほど空いてしまいました。 その間に、誕生日に Japan Rook Meetup で登壇したり… 本日の登壇資料です。改めてありがとうございました！ #japanrookhttps://t.co/WZzoEYEnku — ののし (@nnstt1) April 2, 2021 CKA (Certified Kubernetes Administrator) の資格を取ったり… CKA 受かりました！俺たちの Kubernetes はこれからだ！完 pic.twitter.com/ivkWe9FxzG — ののし (@nnstt1) May 3, 2021 したのですが、まったくブログにアウトプットできてませんでした。 現在は CKAD (Certified Kubernetes Application Developer) に向けて勉強中なのですが、裏で MinIO Operator を触ってみたので気晴らしに久しぶりの投稿をします。 MinIO とは MinIO は、Amazon S3 互換のオープンソースオブジェクトストレージです。 MinIO | Enterprise Grade, High Performance Object Storage プライベート/ハイブリッドクラウドの標準オブジェクトストレージとなることを前提とした設計のようです。 そのためか、公式サイトではファイルシステムやブロックストレージには結構キツい物言いをしている感じがします（個人の感想です）。 ハイブリッドクラウドストレージは、パブリッククラウドで確立されたモデルに従い、パブリッククラウドプロバイダーは全会一致でクラウドネイティブオブジェクトストレージを採用しています。...

Kubenews #8 を視聴していたら Velero というツールの話題が出て、そういえば試そうと思って手付かずのままだったなぁと思い出し、試せるのはいつになるかなぁと Twitter で呟いたら「今でしょ！」とも言われたので、Velero を試してみました。 Velero とは Velero は、Kubernetes クラスタのリソースと永続データをバックアップ、リカバリ、移行するためのツールです。 VMware のプロジェクトとして管理されており、VMware Tanzu (VMware の Kubernetes 製品群) の一員です。 vmware-tanzu/velero: Backup and migrate Kubernetes applications and their persistent volumes Velero は Kubernetes クラスタに対して以下のような使い方ができます。 バックアップ・リストア 別クラスタへの移行 本番環境のクラスタを別環境に複製 Velero の特徴としては、Kubernetes API を使ってバックアップ・リストアをする API-driven な点があります。 他の Kubernetes 用バックアップツールはクラスタ内の etcd を直接参照してバックアップ・リストアするようで、その点が異なります。 API-driven なバックアップツールには以下のようなメリットがあります。 名前空間、リソースタイプ、ラベルによってバックアップ・リストア対象を柔軟に選択可能 マネージド K8s クラスタの場合、etcd を直接参照できずバックアップ・リストアできないことがあるが、API 経由なら可能 別の etcd にリソースが保存されていてもバックアップ・リストア可能 正直なところ、3点目はどのような場合を想定しているのか理解できていません…。 また、Velero は Kubernetes のリソースだけでなく、永続データもバックアップ・リストアの対象とすることができますが、今回はリソースを対象にしたバックアップ・リストアのみ試しています。 オブジェクトストレージの用意 Velero はバックアップデータをオブジェクトストレージに格納します。 Amazon S3 や Azure Blob Storage といったクラウドサービスとしてのオブジェクトストレージを使ってもよいのですが、今回はオンプレ環境の K8s クラスタ内に2種類のオブジェクトストレージを用意しました。...

ふとしたきっかけで、自宅ラボに PostgreSQL as a Service が欲しくなったので Zalando Postgres Operator を試してみました。 Zalando Postgres Operator とは Zalando Postgres Operator（以下、Postgres Operator）とは、Kubernetes クラスタに HA 構成の PostgreSQL クラスタを簡単に構築してくれる Operator です。 Postgres Operator を Kubernetes クラスタにデプロイすると、postgresql というカスタムリソースを宣言したマニフェストを使うだけで簡単に PostgreSQL クラスタを構築できます。 また、専用の Web UI を使って PostgreSQL クラスタを管理することもできます。 この Postgres Operator を自宅ラボの Kubernetes クラスタにデプロイして PostgreSQL as a Service として利用します。 Zalando SE Zalando SE とは、ヨーロッパを中心に展開するオンラインファッションプラットフォームを運営する企業です（日本で言うところの ZOZO でしょうか？）。 Zalando SE は GitHub で複数のオープンソースのプロジェクトを公開しています。 Zalando SE Zalando Postgres Operator も Zalando が開発しているプロジェクトの一つです。...

2020年も残すところ数時間なので、今年の振り返りをサクッとします。 第一子誕生 1月に長男が誕生しました。 2, 3ヶ月は夜に起こされることも多く心身ともに疲労がありましたが、 妻の実家に近いこともあり、かなり助けられました。 大変な時期も含めて、とてもとても可愛くて毎日の成長が楽しみです。 来週には1歳になりますが、まだ誕生日プレゼントを決めきれずにいます。 年始のセールで決めちゃいましょう。 自宅ラボ構築 5月に自宅ラボを構築しました。 今でも十分に大活躍していますが、仮想化基盤としてはメモリ不足を感じているのでスケールアウトかスケールアップしたいですね。 （沼の気配がする） 仮想化基盤のパーツ購入&構築 先月の投稿で自宅ラボの機器選定をしました。結論を言うと、DeskMini A300 を買いました。 仮想化基盤のハードウェア選定 つよつよエンジニアには「自宅ラボ」という検証環境をお持ちの方が多いようです。 「自宅ラボある⇒つよつよエンジニアになる」ではないですが、自宅ラボあれば勉強する機会が増えるのではということで、自宅ラボ構築を目指します。 「逸般の誤家庭」と呼ばれる常軌を逸した環境（褒め言葉）を構築されている方もいらっしゃるようですが、お財布のほうも常軌を逸してしまいそうなのでコスパ重視で自宅ラボを構築を検討します。 今回は、仮想化基盤用マシンのハードウェア選定をしていきます。ネットワークについては別途検討予定。 目的（なぜ仮想化基盤用のマシンを用意するのか） 自宅でも快適にKubernetesクラスタを検証するためです。 現在は自宅PC(Win10)にVMware Workstation Playerを入れ、その上にESXiを入れてしてネスト仮想化基盤を構築しています。 しかし、PCのスペックがそこまで高くうえにネスト構成にしたためESXiのVMは激重になってしまいました。 当初はOpenShift4を動かしてみるつもりでしたが、インストール作業が終わりませんでした。OpenShiftは要求スペックが高いですね…。 Chapter 1. Installing on bare metal | Red Hat Product Documentation Chapter 1. Installing on bare metal | Red Hat Documentation 代わりにkubeadmでK8sクラスタ（master3台, worker3台）を組んでみたのですが、クラスタできたもののPrometheus-Operatorを入れてみたら無事に死亡しました。 そのようなこともあり、快適にK8sクラスタを動かすことができる自宅ラボを構築することが目的となっています。 機器選定 マザーボードと電源が一体となった「ベアボーン」 or パーツをそれぞれ自分で選ぶ「自作PC」の2通りから考えます。 （ベアボーンも自作PCに含まれると思いますが、適切な表現が不明なので分けて記載します。） 本当はラックサーバが欲しかったのですが、自宅の要件（電力だったり騒音だったり）に合いそうにないため除外しています。また、タワーサーバは中古市場であれば比較的安価なものが出回っているようですが、十分に調べきれていないためこちらも除外しています。 ストレージ ストレージは各候補ともに共通の製品を選択予定です。 パーツ 型番 特徴 価格.comの最安値 ストレージ WD Blue SN550 NVMe WDS500G2B0C m....

自宅の検証用マシン (Deskmini A300) に ESXi を入れて検証環境として利用しています。 最近はそこへ k8s クラスタを構築して色々試しているのですが、クラスタ内に立ち上げたサービスへは IP アドレスでアクセスしていました。 IP アドレスでアクセスするのはとても面倒だったのですが、やっと k8s で動かしているサービスに FQDN で繋がるようになったので投稿します。 システム構成図 完成後のシステム構成図になります。 （構成図描くの下手で分かりにくいと思います…） [f🆔nnstt1:20201113012536p:plain] 見てもらって分かる通り、LAN 用の DNS サーバを VM で建てています (k8s クラスタの外です)。 これは、k8s クラスタを構築する前に DNS サーバ (dnsmasq) を構築していて、それを流用しているためです。 使用するプロダクト 今回利用しているプロダクトは以下になります。 名前 バージョン 用途 Kubernetes 1.19.0 コンテナオーケストレーション Docker 19.03.12 コンテナランタイム ExternalDNS 0.7.3 DNS プロバイダに DNS を登録 CoreDNS 1.8.0 DNS サーバ etcd 3.4.13 DNS レコード格納 MetalLB 0.9.3 ベアメタルロードバランサー 構築 以下の手順で環境を構築しました。 DNS サーバ (CoreDNS & etcd) 構築 MetalLB デプロイ ExternalDNS デプロイ DNS サーバ (CoreDNS & etcd) 構築 CoreDNS & etcd を使った DNS サーバを構築します。 この DNS サーバに k8s クラスタのサービス用の DNS レコードを格納していきます。 なぜ dnsmasq を流用しないかというと、後述する ExternalDNS が dnsmasq に対応していないからです。...