自宅ラボ

普段プライベートでは Terraform Cloud は Azure のリソース（このブログの Static Apps や自宅ラボと連携しているサービス）を管理するために使ってます。 最近 Terraform Cloud を触る、というかドキュメントを読み漁る機会があって、この機会に Terraform Cloud Operator for Kubernetes を自宅ラボに入れてみるかぁ、となったのでやってみました。 ちなみに最近アップデートされた v2 のほうです。 Terraform Cloud Operator for Kubernetes | Terraform | HashiCorp Developer The Terraform Cloud operator for Kubernetes allows you to provision infrastructure directly from the Kubernetes control plane. Terraform Cloud Operator for Kubernetes は長すぎるので、以降 TFC Operator と記載します。 TFC Operator は何ができるの？ TFC Operator はカスタムリソースを使って Terarform Cloud のワークスペースやモジュール、そしてエージェントプールを Kubernetes のリソースとして管理することができます。 特にエージェントプールの管理では Terraform Cloud エージェント自体も Pod として起動してくれます。...

この記事は エーピーコミュニケーションズ Advent Calendar 2023 の1日目の投稿です。 今年の 4 月に株式会社エーピーコミュニケーションズ (以降、APC) に入社して半年経ちました。 今はがっつり Azure をやっている感じですが、前職では Azure だけでなく色々なことにチャレンジさせてもらいました。 その中でも一番最初にチャレンジ（通常業務とは別で取り組んだ業務改善）したのは Ansible の導入でした。 そもそも Ansible とはなんぞや？って状態だったので Ansible を実際に触ってみようと、まずは Ansible もくもく会に参加しました。 当時はまだコロナ禍前の世界ということもあり Ansible コミュニティが開催していたもくもく会は数少ないオンライン参加が可能な勉強会で、これが自分にとって初めての技術コミュニティへの接触でした。 それから度々 Ansible コミュニティのイベントに参加していき、その中で某金魚の方を始めとした APC 所属の方をよくお見かけして APC という会社を知りました。 自分の興味が Ansible に加えて Kubernetes や Azure に広がっていった際も APC の名前を見ることが多く、Ansible に限らずアウトプット活動が盛んでとても楽しそうな会社という印象を持っていました。 アドベントカレンダーもその楽しそうな活動一つで、APC のアドカレ（組織のアドカレと言ったほうが正しいかも）に参加することは一種の憧れでもありました。 そんな APC に入社できたのも、自宅で自由に検証ができる環境「自宅ラボ」を導入してスキルアップできたのが大きいです。 というわけで、アドカレの初日にポエムっぽい投稿になってしまいますが「自宅ラボ ジャーニー 2023」と銘打って自分の過去ツイートを引用しながら自宅ラボの遍歴を紹介します。 ちなみに見出しは有名どころのサブタイトルを引用していますが特に意味はないです。 【序章】自宅ラボは出ているか? はじめに自宅ラボを導入するに至った動機ですが、理由は単純で「自由に使える環境が欲しい」と思ったからです。 冒頭で話したとおり、前職で自動化やサーバ管理を推進するために Ansible を触り始めたのですが、検証環境を用意するのもなかなか難しいものがありました。 特にプロキシに阻まれまくった。 最初の頃は Ansible もくもく会で使える環境で十分満足していたのですが、そのうちもっと色々な検証をしたくなって自由に使える プロキシに阻まれない 自宅ラボを導入することにしました。 おそらく自宅ラボを構築している方の多くが同じ動機なんではないでしょうか。 あと、ロマンとか探究心みたいな気持ちも少しはありましたね。 クラウドサービスを利用するのもよかったんですが、インフラの勉強をするにあたってやっぱり物理で触れるものが欲しいという理由でクラウドは除外しました。 とは言っても一部のサービスは自宅ラボと連携する形で利用しています。...

はじめに 今年の夏も酷暑続きでしたねー。 仕事が忙しくて自宅ラボに触る時間もなかったり、マシンの熱が心配なのもあって夏の間は自宅ラボの電源を落としてたり、ということもあり前回の投稿から 4 ヶ月も空いてしまいました。 忙しさのピークも一段落して季節も秋に変わってきたので、また自宅ラボという名の盆栽いじりを再開してます。 前回の投稿では、cert-manager を使って Ingress 用の証明書を発行するようにしました。 Let’s Encrypt の ACME DNS-01 チャレンジ用に cert-manager が Azure DNS に TXT レコードを作成してくれます。 このとき、cert-manager は Microsoft Entra ID のサービスプリンシパルを使います。 サービスプリンシパルのクライアントシークレットは有効期限が最大でも 2 年間 (24 ヶ月) なので、HashiCorp Vault と Vault Secrets Operator を使ってクライアントシークレットを動的に生成して、クライアントシークレットの有効期限を意識せずにサービスプリンシパルを使えるようにします。 自宅ラボ用途なので 2 年間でもいいっちゃいいんですがね。 全体像 今回は色々なサービスが連携していて流れが分かりづらいため、最初に全体像を把握します。 シーケンス図のほうが分かりやすかったかも？ サービスプリンシバルを含め、Secret リソース以外は事前に作成しておきます。 今回の投稿でメインになってくるのは Vault と Vault Secrets Operator (VSO) です。 サービスプリンシバル あらかじめ Vault 用と cert-manager 用のサービスプリンシバルを作成しておきます。 cert-manager サービスプリンシバルは前回作成したものを使います。 Vault サービスプリンシバルも同様に作成したあと、他のサービスプリンシバルを操作するためのアクセス許可を設定します。 必要なものは以下の 2 つです。...

はじめに 久しぶりの個人ブログへの投稿です。 4月に転職してから会社ブログのほうに投稿する機会ができた結果、個人ブログのほうが疎かになってしまいました。 仕事でもプライベートでもやってること大体同じなんで投稿ネタがなくなるよね……。 というわけで、しばらく個人ブログのほうは自宅ラボという盆栽のお手入れ内容をメインに扱っていきます。 身の上話はここらへんにしておいて、今回は kube-vip というツールを使って、盆栽（おうち K8s クラスタ）用に構築していたロードバランサを削除した話です。 どうしてロードバランサを無くしたいの？ 我が家の K8s クラスタは、Proxmox VE を使った仮想基盤上の VM で動いていました。 物理は NUC と DeskMini の2台構成です。 かつてラズパイを使った Ceph クラスタを Rook から使っていましたが、不安定極まりないためラズパイをコントロールプレーンとして転生させました。 この時点で以下のような構成でしたが、VM を使わずに K8s クラスタを作りたいという思いを捨てきれず、現在は3台目のマシンをお迎えして絶賛移行中です。 用途 種別 台数 コントロールプレーン ラズパイ 3 ワーカー VM 3 ロードバランサ VM 2 ロードバランサは kube-apiserver 用に作成したものです。 kubeadm の高可用性クラスタを作る際のドキュメントにも記載があります。 DNS に Keepalived 用の VIP を A レコードとして登録して、クラスタ外からアクセスするのに使っています。 K8s クラスタを物理だけで動かそうとしたとき、このロードバランサがネックになりました。 手持ちのラズパイ3台はすでにコントロールプレーンとして使ってますし、ワーカー用の筐体もやっと3台揃えたところです。 ロードバランサとして使える余剰筐体は我が家にはありません。 高可用性である必要があるの？と思われるかもしれませんが、それはアレですよ、“ロマン” ですよ。 というわけで、今の手持ちで物理 K8s クラスタを作るためにも、以下の要件を満たす方法を検討しました。 ロードバランサ用のマシンは使わない 高可用性は維持する kube-vip を使ってみる 元々ロードバランサ@VM は RHEL に Keepalived と HAProxy を入れてアクティブ/スタンバイの構成としていました。 ロードバランサを無くすに当たって、最初はコントロールプレーンに直接 Keepalived を入れようとしましたが、うまくサービスが上がってこず原因調査で時間を溶かしていました。...

2022/10/12 に開催された K8s@home #1 で LT したので振り返ります。 K8s@home とは 最近できたコミュニティです。 運営は @superbrothers さんと @yuanying さんです。 以下はコミュニティページの説明文。 K8s@home # 本グループについて 自宅でラズパイや NUC、VM、そのほか VPS 等を使って個人の趣味として Kubernetes クラスタを構築、運用する人たちが情報交換、懇親する場所です。クラスタ構成や利用するアドオン、デプロイするアプリケーションなどなど、自宅、趣味のクラスタならではのおもしろ情報、こだわりポイントを共有します。 自宅でのクラスタ運用を楽しんでいる人、パブリッククラウドで格安での運用を目指している人、これから個人のクラスタを飼ってみたい人はぜひご参加ください。 # ミートアップの開催について 不定期の開催を予定しています。 # そのほか 業務における真面目な K... 自宅でラズパイや NUC、VM、そのほか VPS 等を使って個人の趣味として Kubernetes クラスタを構築、運用する人たちが情報交換、懇親する場所です。クラスタ構成や利用するアドオン、デプロイするアプリケーションなどなど、自宅、趣味のクラスタならではのおもしろ情報、こだわりポイントを共有します。 自宅でのクラスタ運用を楽しんでいる人、パブリッククラウドで格安での運用を目指している人、これから個人のクラスタを飼ってみたい人はぜひご参加ください。 このように、Kubernetes Meetup Tokyo と同じ Kubernetes 関連ではあるけど方向性が違ったコミュニティになります。 個人的な印象としては、Kubernetes Meetup Tokyo は「仕事でもバリバリ Kubernetes 使っている人たちが最新事例を共有したい」コミュニティで、K8s@home は「肩の力を抜いて Kubernetes を触ってみたよ」なコミュニティかなと思いました（その割に登壇内容は全員レベル高かったですが！！！）。 動機 前回の LT が一年前の Kubernetes Novice Tokyo #11 でした。 その間も仕事で Kubernetes に触る機会はまったく増えないし、新しく登壇するネタもなく自宅で K8s クラスタとチマチマ戯れる日々。 途中で下の子達も産まれて時間的余裕もなくなってました。...

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

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