Tech

Cephadm のアラート CEPHADM_FAILED_DAEMON を消す方法です。 ...

自宅ラボでは 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 今回はその他のパラメータはデフォルト値のまま使いました。 以下のコマンドでパラメータを確認します。 ...

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. www.redhat.com そうとなれば試してみたい欲求が抑えられませんよね？ というわけで要件を満たす機器を選定するところから SNO (Single Node OpenShift) を導入してみました。 ハードウェア要件 SNO をインストールするには以下のスペックが必要です。 プロファイル CPU メモリ ストレージ 最低限 8 vCPU コア 32 GB 120 GB 普通(?) の OpenShift だとコントロールプレーンで 4 コア/16 GB、コンピュートノードで 2 コア/8 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.k8s.nnstt1.work 192.168.2.29 80, 443 22h monitoring grafana <none> grafana.k8s.nnstt1.work 192.168.2.29 80 20h monitoring k8s <none> prometheus.k8s.nnstt1.work 192.168.2.29 80 20h sandbox sample-app <none> sample-app.k8s.nnstt1.work 192.168.2.29 80, 443 20h # 192.168.2.29 は Worker Node の IP アドレス Node Port のように Worker Node の IP アドレスでアクセスしても NGINX Ingress Controller のサービスには到達できないため、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 プライベート/ハイブリッドクラウドの標準オブジェクトストレージとなることを前提とした設計のようです。 そのためか、公式サイトではファイルシステムやブロックストレージには結構キツい物言いをしている感じがします（個人の感想です）。 ハイブリッドクラウドストレージは、パブリッククラウドで確立されたモデルに従い、パブリッククラウドプロバイダーは全会一致でクラウドネイティブオブジェクトストレージを採用しています。 パブリッククラウドの成功により、ファイルとブロックストレージは事実上時代遅れになりました。 すべての新しいアプリケーションは、POSIXではなくAWS S3API用に作成されています。 ...

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 が開発しているプロジェクトの一つです。 ...

自宅の検証用マシン (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 に対応していないからです。 ...

前回の投稿でAWXのProjects自動同期方法を調べたのですが、その中で一つ気になることが出てきました。 それは 「AWXではAnsible GalaxyのRoleはどのように参照されるのか」 という点です。 CLIで使うAnsibleでは ansible-galaxy install コマンドで外部Role（Galaxyに公開されているRoleや特定リポジトリのRole）をPlaybookから参照／実行できます。参照するRoleを指定する方法の1つに、参照情報を記載したYAMLファイルを読み込む方法があります。その際のコマンドは ansible-galaxy install -r [参照ファイルパス] です。AWXでも同じように参照されるのか、確認してみました。 マニュアルを読む Ansible TowerでAnsible Galaxyを使う方法はUser Guideに書かれています。AWXも同じ方法です。それによると、<project-top-level-directory>/roles/requirements.yml ファイルを見つけると自動的に ansible-galaxy installコマンドが実行されるようです。 [https://docs.ansible.com/ansible-tower/latest/html/userguide/projects.html#ansible-galaxy-support:embed:cite] なるほど、CLI版とほぼ同じでansible-galaxy installコマンドを使って、参照するファイルの名前や保存先は指定されていると。そして実行タイミングはProject Update（プロジェクトの同期）の最後。じゃあ特段気にすることはないな、と思っていたのですが…。 実際に確認 前回の調査で知ったのですが、Project Update自体もAWXの Internal Job となっています。（正式用語かわかりませんがプログラム内のコメントでは Internal Job と記載されていたのでここでもそう呼びます） そして、Internal JobもPlaybookを参照して実行されるようで、Project Updateは project_update.yml というPlaybookを参照しています。このPlaybookはawx_taskコンテナの/var/lib/awx/venv/awx/lib/python3.6/site-packages/awx/playbooks/project_update.ymlにあります。project_update.ymlの中身を見ると、 name: Update source tree if necessary name: Install content with ansible-galaxy command if necessary という2つのtasksで構成されていることが分かります。前者がAWX上で指定したSCMの更新で、後者がrequirements.ymlで指定した外部Roleの更新なんですね。実際に後者のタスクでcommand: ansible-galaxy installの記述があるので、マニュアルで書かれていた内容はこのPlaybookで実現しているようです。 外部Role更新タスクの実行条件として when: roles_enabled|bool と tags: install_roles がありました。変数roles_enabledは Settings -> Jobs -> Enable Role Download のON/OFFで決まるようです。tagsのほうはInternal Job実行時に install_roles が付いていれば実行されるタスクのようですが、ここは未確認です（理由は後述）。 ...