自宅k8s構築日記 冬休み編 2024/1/23 社内勉強会 世良泰明

自己紹介 名前: 世良 泰明 (せら やすあき) 職業: ひよっこインフラエンジニア (3年目) 名古屋の某SIer所属 AWS上でインフラ構築・運用 趣味: 囲碁, 散歩, etc… twitter: @y_sera15 自宅K8sクラスター

今日の話 冬休みに自宅のk8sクラスターを再構築したという話 帰省しなかったので, 休み中の起きてる時間の半分くらいはこれに費やしてました. 注: - この資料は現時点(2024/1/23)の自宅構成を一通りまとめたもの - 10分じゃとても終わらないので抜粋して説明 目次 • これまでの構成 • 今回のコンセプト • 物理構成 • NW構成 • VM構成 • k8sクラスター • ネットワーク • ストレージ • デプロイしたアプリケーション • まとめ • 今後の展望

これまでの構成(~2024/12末頃) これまでのk8sクラスター - Control Plane3台, worker3台のHA構成 - kubesprayにて構築(Ansibleベースのk8sクラスター構築ツール) - 諸々の基盤用プラグインもkubesprayから追加 - NASとの連携はやっていた 問題点: - ただ建ってるだけ(L7ロードバランサ(ingresss), DNS等未整備. アプリ稼働ゼロ) - 使いたいCNIプラグインのバージョンが古い(kubesprayが追従していなかった) - kubesprayとHelmコードの管理の煩雑化 改めて再構築することに 構築ツールはkubeadmを使用

今回のコンセプト 1. 可能な限りk8sで完結する - DNS, HA Proxyは全部載せ - コンテナレジストリ, gitサーバも - 一部AWSと連携 2. 可能な限り自動化する - L7LB登録 → 証明書発行 → DNS登録 全部まるっとお任せ - ↑まだまだこれだけ 3. 可能な限りproduction likeに - 開発用構成で妥協しない - セキュア - (あくまでベストエフォート)

要件 - ストレージ基盤としてNASを活用する - パブリックドメインを取得し, クラスター上のアプリへはそれを用いてアクセスする. - webアプリのTLS化はLet's encryptにて取得した証明書を用いる. - 証明書取得はDNS認証にて行う.(インターネット公開をしないため.) - 外部クラウドサービス連携が必要な箇所はAWSを使用する. - クラスター向けドメインの名前解決は, NAS提供のDNSサーバーからForwardする. - OSSアプリケーションはHelmでの導入を最初に検討する. 無ければmanifestにて行う.

物理構成 Router(Yamaha RTX1220) - VPNルーター - LAN1: 8ポート - LAN2/LAN3: 各1ポート Router(Edge Router X) - 多機能ルーター - LAN1: 4ポート - MP-BGP対応 NAS( Synology DS923+) - 4TB HDD x4 - Memory 標準4GB + 拡張16GB - LANポート 2つ - RAID6構成 Compute ×3台(Intel NUC 11th) - core i5(4core 8thread) - Memory: 64GB - Storage: 1TB - VM基盤としてESXiを利用

NW構成 LAN1: 内部NW LAN1: 内部NW - Desktop/Laptop/mobile用

NW構成 LAN2: VM管理用NW LAN2: VM管理用NW - ESXiが稼働するNW - VLANにて制御

NW構成 LAN3: VM用NW LAN3: VM用NW - VMが稼働するNW - ここでk8sクラスター稼働

NW構成 ルーターにて LAN間NWを制御 ルーターにて LAN間NWを制御

NW構成 NAS NAS: LAN1 とLAN3向け にそれぞれ管理用 VMを構築 ホストゾーン internal.<取得ドメイン> ホストゾーン k8sapiserver.<取得ドメイン> NASの標準アプリとしてDNSを稼働

VM構成 ノード数は変更せず OS: ubuntu22.04 server(minimum) Control Plane: - CPU: 2core Mem: 8GB Storage: 50GB 構成変更なし NUC1 ESXi Control Plane1 Worker1 NUC2 ESXi Control Plane 2 Worker2 NUC3 ESXi Control Plane 3 Worker3 Worker: - CPU: 4core -> 6core Mem: 16GB -> 32GB Storage:50GB -> 100GB +300GB 諸々増強, 再構築 ※ESXiでは1thread = 1core扱い

k8sクラスター 入れたもの(2024/1/23時点) 1. Network - CNI: Cilium (+ Hubble) - L4: kube-vip - L7: Nginx-Ingress - External DNS - cert-manager 2. Storage - Synology-CSI driver - TopoLVM 3. Application - GitLab - Tekton operator/Pipeline - ArgoCD - Harbor - Hashicorp Vault - Prometheus/Grafana 方針: - OSSは基本的にhelmで管理 - 無い場合はmanifest

k8sクラスター Network Cilium(+ Hubble) - CNIとしてインストール - kube-proxyを置換 - eBPFによるルーティングで, スケーラビリティ向上 (iptablesベースのルーティングだとスケール限界が早い. が, この規模ならほぼロマン?) - HubbleでeBPFによる通信の可視化を行う Hubbleによるトレース 10.0.0.0/8 コンテナの世界のNW 192.168.xxx.0/24

k8sクラスター Network Kube-VIP - Haproxy+ keepalivedの代わりで, クラスター 内で完結できる - 仮想IPを払い出しする - Kube-VIPのCloud Controllerを導入することで, type LoadBalancerのServiceがベアメタルでも 払い出せる 管理用端末 (デスクトップPC) アプリ用 L4 LB 192.168.xxx.ZZZ (仮想IPで固定) aaa.<取得ドメイン> コントロールプレーンのエンドポイント 192.168.xxx.XXX (仮想IPで固定) 名前解決 (aaa.<取得ドメイン>) http://aaa.<取得ドメイン> kubectlコマンド DNS用 L4 LB 192.168.xxx.YYY (仮想IPで固定)

k8sクラスター Network Nginx-Ingress Controller - L7層の負荷分散をする, Ingressリソースの コントローラー - L4層のロードバランサーが少数で済むので嬉しい 管理用端末 (デスクトップPC) アプリ用 L4 LB 192.168.xxx.ZZZ (仮想IPで固定) aaa.<取得ドメイン> bbb.<取得ドメイン> http://bbb.<取得ドメイン> ccc.<取得ドメイン> アプリA アプリB アプリC Nginx-Ingress Controller

k8sクラスター Network External DNS - デプロイしたアプリを自動でDNSへ登録 - 非常に便利 管理用端末 (デスクトップPC) アプリ用 L4 LB 192.168.xxx.ZZZ (仮想IPで固定) aaa.<取得ドメイン> Forward (bbb.<取得ドメイン>) DNS用 L4 LB 192.168.xxx.YYY (仮想IPで固定) DNSのバックエンド DNS(on NAS) External-DNS bbb.<取得ドメイン> 名前解決 (bbb.<取得ドメイン>) 1. 検出 1. 検出 2. 自動登録 http://bbb.<取得ドメイン>

k8sクラスター Network Let's encrypt連携 - パブリックに使える証明書自動発行 - 証明書更新も自動 - インターネットへのリソース公開無し AWS Cloud 管理用端末 (デスクトップPC) パブリックホストゾーン <取得ドメイン> L4 LB(アプリ用) 192.168.xxx.ZZZ (仮想IPで固定) L7 LB aaa.<取得ドメイン> 3. 検証用レコード登録 aaa.<取得ドメイン> 5. DNS検証 aaa.<取得ドメイン> 4. 証明書発行依頼 6. 証明書発行 7. 証明書保存 cert-manager Route53 8. 参照 証明書発行用リソース - Issuer - Certificate 1. 証明書発行用 リソース作成 2. 検知 HTTPS HTTPS HTTPS HTTPS

k8sクラスター Storage Synology-CSI driver - NASのメーカーがk8s用にドライバーをOSSで公開 - iscsiとSMBで通信可能. 動的にストレージを確保. - LUNの上限10, 一部機能に対応してないなど, 多少懸念点あり. (LUNはNASの問題. 一部機能: fsGroupでのパーミッション変換.) TopoLVM - サイボウズが開発している, OSSストレージドライバー - 各ノードにてLVMを使用し動的にストレージを確保. - ストレージがノードに紐づくため, ノード障害に対して工夫が必要. - 各ノードに300GB確保 Worker Node Control Plane NAS iscsi SMB スケジューリング/ 監視

k8sクラスター Application 1. CICD周り - GitLab Gitホスティングサービス - Tekton Operator/Pipeline K8s上で稼働するCIツール - ArgoCD GitOps用のデプロイツール - Harbor コンテナレジストリ 2. 機密情報管理 - Hashicorp Vault シークレット管理用 3. 監視・可視化 - Prometheus/Grafana メトリクス監視用 まだインストールしただけ。 実用は今後

まとめ 冬休みの間に自宅のk8sクラスターを再構築した - ネットワーク: - 冗長構成に必要な要素をk8sへ押し込んだ - L7ロードバランサーに登録するとDNSのレコードが自動登録されるようにした - 有効な署名付きTLS証明書を自動発行可能になった - ストレージ: NASとローカルボリュームの両方で基盤を構築した - アプリケーション: - kubernertesでのCI/CDのスタートラインに立てた 構築したマニフェストファイル等はメモと一緒にGitで管理している 気力があれば公開するかも?

今後の展望 1. 自作アプリケーションの開発/デプロイ - GitOpsとしてCICDパイプライン作って開発 2. 基盤の拡充 - オブジェクトストレージ基盤 - ログ収集/分析基盤 - newSQLのDB基盤 3. よりproduction likeに - セキュリティ(通信制御/TLS化, 権限管理, アラート) - バックアップ - アプリの構成見直し(defaultから適切な設定に変更) Kubernetes CI/CDパイプラインの実装 北山慎吾 インプレス

以下、補足スライド

苦労点 1. CNIが稼働せず 再構築したノードのcontainerdのパラメータ設定 -> Kubesprayで構築していたときはインストール前の設定もよしなにやってくれていた 2. NASのLUN上限 iscsiでNASからストレージを動的に調達 -> LUN上限が10で意外と少ない => TopoLVMを導入し使い分け 3. NASのCSIドライバーの制約 コンテナ内の実行ユーザと, マウントしたディレクトリのパーミッションの統合ができな いっぽい(fsGroupパラメータ対応してなさそう) => パーミッション問題が絡むストレージは一旦TopoLVMベースで稼働.

セキュリティ対応 (やるかどうかは別として,)インターネット公開を念頭に対応箇所を洗い出し - ノード - FW設定 - sshログイン禁止 - クラスター - クラスターエンドポイント保護 - 権限アクセス制御 - NetworkPolicy設定 - ロギング - auditログ - コンテナ間通信TLS化 - リソースクォータ設定 - アプリ公開範囲選定(基盤管理系アプリはSSO化など) - 監視設定(falco)