Kubernetes

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 に対応していないからです。...

OpenShift の構築に試行錯誤した記録を残すため「OpenShift構築奮闘記」というタイトルで連載を始めます。 手始めに OpenShift を構築することにした経緯と、インストールする構成を残しておきます。 どのような課題が発生している/していたかは #1 以降で記載します。 なお、執筆時点で構築完了していないため連載回数は未定です。 事の始まり 弊社（弊部署）には毎月hh時間は技術向上のために遊んでよい（業務外のことをしてよい）、という取り組みがあります。 その一環で、自分は Kubernetes や Ansible といった技術の検証（勉強）を進めていました。 検証のためのVMは用意してもらっていましたが、1台しかないため色々試したいことが試せず悶々とした日々を過ごしていました。 e.g. 1サーバに GitLab(omnibus) と Kubernetesクラスタ を同居させて、 GitLab から Kubernetes に連携しようとしても「同じサーバ上にあるからダメー」と怒られたり…。 そんな折の今年１月末に突如、「保守期限切れになったサーバ（正確にはワークステーションらしい）を廃棄する前に自由に使っていいよ」とボスから声を掛けていただきました。 ↓その日の定時後の様子 なんか知らんけど保守切れ物理サーバ5台を自由に使っていいことになった！なんのご褒美だ？何して遊ぼうかな、やっぱりKubernetesかなー — ののし (@nnstt1) January 31, 2020 5台も使えることになったのですが、前職を含めても物理サーバを直接触ったこともないド初心者です。 とりあえず1台分だけ VMware ESXi を導入してVMの作っては壊しをできるようにして、その VMware 上に当初から考えていた Kubernetes クラスタを構築を目指しました。 社内ネットワークということもありプロキシやら認証やらで手こずりながらも、なんとか kubeadm を使った Kubernetes クラスタを構築することができました。（この内容もいずれ記事に残したいです） そんなこんなして遊んでいたら、Red HatのウェビナーやSoftware Design 3月号で紹介されていた OpenShift の詳細を知る機会があり、興味が湧いてきました。 OpenShift、いいですよね（説明を見聞きしただけで触ったことはない）。 使うだけならARO（Azure Red Hat OpenShift）が楽だと思いますが、せっかくなので VMware 上に OpenShift を構築することを次の目標にしました。 構築にあたり以下の記事を参考にさせていただいてます、ありがとうございます。 failed to fetch remote resource: Forbidden OpenShift 4....