Terraform と Kubernetes の共存による IaC の実践

Terraform と Kubernetes はどちらも宣言的に構成を定義し実際のインフラに反映させる IaC (Infrastructure as Code) が実現できるツールですが、反映タイミングやワークフローの構築コストは大きく異なります。本セッションでは Wantedly での Terraform と Kubernetes による構成を例に、状況に合わせてツールを使い分けて IaC を実現する方法について紹介します。
https://events.hashicorp.com/hashitalksjapan

Transcript

1. © 2022 Wantedly, Inc.
   Terraform と Kubernetes の
   共存による IaC の実践
   HashiTalks: Japan 2022
   Aug. 25 2022 - Atsushi Tanaka
   

   View Slide

2. 自己紹介
   © 2022 Wantedly, Inc.
   https://www.wantedly.com/id/bgpat
   

   View Slide

3. 今日話すこと
   © 2022 Wantedly, Inc.
   Kubernetes の機能拡張をするときは
   Kubernetes のエコシステムのみで実装するケースが多い
   かゆいところに手が届かないことがある
   ⇓
   Terraform で実装することで改善できる
   

   View Slide

4. Kubernetes について
   © 2022 Wantedly, Inc.
   ● Cloud Native 技術の中心的プロジェクト
   ● 管理対象を「リソース」として抽象化
   ● 拡張性が高く様々なプラットフォーム基盤としても利用される
   https://kubernetes.io/ja/docs/concepts/overview/what-is-kubernetes/
   

   View Slide

5. 今日話すこと
   © 2022 Wantedly, Inc.
   Kubernetes の機能拡張をするときは
   Kubernetes のエコシステムのみで実装するケースが多い
   かゆいところに手が届かないことがある
   ⇓
   Terraform で実装することで改善できる
   

   View Slide

6. Terraform で k8s の機能拡張をする
   © 2022 Wantedly, Inc.
   

   View Slide

7. Terraform と Kubernetes の共通点
   © 2022 Wantedly, Inc.
   Infrastructure as Code が実現できる
   ○ インフラリソースをコードとして宣言的に管理
   ○ インフラとコードに差分あったときは自動で修正
   

   View Slide

8. IaC 観点での比較
   Terraform Kubernetes
   同期タイミング apply 実行時のみ 依存リソースの変更時
   レビュータイミング API 実行時 コードの apply 時
   管理対象リソース インフラ全体
   基本的にクラスタ内
   外部リソースは専有前提
   実装コスト Provider が対応していれば
   比較的容易
   既存実装が利用できれば楽
   なければ自前実装が必要で大変
   © 2022 Wantedly, Inc.
   

   View Slide

9. IaC 観点での比較
   © 2022 Wantedly, Inc.
   Terraform: apply 実行時のみ
   ● 同期は terraform apply の実行
   時にしか行わない
   ● terraform apply は頻繁には実
   行できない
   ➡ コードとインフラの間に差分（ドリフ
   ト）が生じる可能性
   同期タイミング
   Kubernetes: 依存リソースの変更時
   ● Reconciliation Loop によって
   自動で同期された状態が保たれる
   ➡ 理論上ドリフトは発生しない
   

   View Slide

10. IaC 観点での比較
    © 2022 Wantedly, Inc.
    レビュータイミング
    Terraform: API 実行時
    ● terraform apply を実行すると
    差分が表示されて 続行 or 中断
    の判断を求められる
    ● API の実行は手動ともみなせる
    ➡ 人間がレビューすることで
    より安全に処理を実行できる
    Kubernetes: コードの apply 時
    ● コードをクラスタに apply するタイミ
    ングで差分の確認ができる
    ● Reconciliation Loop によって
    自動で API が実行される
    ➡ 人間は処理内容を確認できない
    不要であれば手間が省ける
    レビュータイミング = 変更内容の確認と 続行 or 中断 の判断ができる最後のタイミング
    

    View Slide

11. IaC 観点での比較
    © 2022 Wantedly, Inc.
    管理対象リソース
    Terraform: インフラ全体
    ● 特定の k8s クラスタに依らない
    ● 複数 k8s クラスタを管理できる
    ● k8s クラスタ以外の外部リソースも
    問題なく管理できる
    Kubernetes: 基本的にクラスタ内
    ● 管理対象のリソースは特定の k8s
    クラスタ内に閉じている
    ● 外部リソースはクラスタが専有して
    いる前提で扱わないと競合してしま
    う
    

    View Slide

12. IaC 観点での比較
    © 2022 Wantedly, Inc.
    実装コスト
    実装コストが低い順に
    1. 既存実装を利用
    ○ Kubernetes のエコシステムに沿ったものが多い
    ○ 設定を書くだけなので一番楽
    2. Terraform で実装
    ○ API 実行等の手続き処理を考える必要がなく宣言的なコードだけで実装できる
    ○ できることは Provider が対応しているリソースに縛られる
    3. Kubernetes のエコシステムを利用して自前実装
    ○ 宣言されたコードを手続き処理に変換する必要がある
    ○ Go 言語で実装して k8s クラスタにデプロイする必要がある
    

    View Slide

13. Terraform による Kubernetes 拡張
    © 2022 Wantedly, Inc.
    制約
    ● ドリフトが許容できる
    Terraform による機能拡張が有効なケース
    ● 切り戻しが難しい作業等で API 実行前にレビューしたい
    ● クラスタで専有できないリソースを扱いたい
    ● 新しい自動化の仕組みを簡単に実装したい
    

    View Slide

14. Wantedly での実践例
    © 2022 Wantedly, Inc.
    

    View Slide

15. Wantedly での実践例
    1. 外部公開エンドポイントの DNS 設定
    2. プレビュー用 wildcard domain の発行
    © 2022 Wantedly, Inc.
    

    View Slide

16. Wantedly での実践例
    1. 外部公開エンドポイントの DNS 設定
    ○ モチベーション
    ■ クラスタの引っ越しをするときに DNS で切り替えをしたい
    ■ DNS 設定を反映するタイミングをコントロールしたい
    ○ 管理するリソース
    ■ DNS レコード
    ■ 監視設定
    2. プレビュー用 wildcard domain の発行
    © 2022 Wantedly, Inc.
    

    View Slide

17. Wantedly での実践例
    © 2022 Wantedly, Inc.
    外部公開エンドポイントの DNS 設定
    Cluster
    Pod
    Ingress
    (LB)
    Pod
    Cluster
    Pod
    Ingress
    (LB)
    Pod
    DNS
    旧クラスタから新クラスタに切り替え
    example.com
    エンドポイントを監視
    

    View Slide

18. Wantedly での実践例
    © 2022 Wantedly, Inc.
    外部公開エンドポイントの DNS 設定
    制約
    ⭕ ドリフトが許容できる
    Terraform が有利なケース
    ⭕ 切り戻しが難しい作業等で API 実行前にレビューしたい
    ⭕ クラスタで専有できないリソースを扱いたい
    ❌ 新しい自動化の仕組みを簡単に実装したい
    外部公開エンドポイントが追加・削除される頻度は多くない
    向き先になるロードバランサのエンドポイントは基本的に変更されない
    同じ DNS レコードは2つのクラスタの両方から専有することができない
    DNS レコード変更時の切り戻しには時間がかかるため慎重に実行したい
    external-dns という OSS の Custom Controller が利用できる
    

    View Slide

19. Wantedly での実践例
    1. 外部公開エンドポイントの DNS 設定
    2. プレビュー用 wildcard domain の発行
    ○ モチベーション
    ■ 開発用に推測しやすいプレビュー用ドメインを発行したい
    例: service.example.com → *.service.example.com
    ○ 管理するリソース
    ■ ロードバランサー
    ■ TLS 証明書
    ■ DNS レコード
    © 2022 Wantedly, Inc.
    

    View Slide

20. Wantedly での実践例
    © 2022 Wantedly, Inc.
    プレビュー用 wildcard domain の発行
    https://speakerdeck.com/potsbo/copy-kubernetes-clusters-really-fast?slide=37
    

    View Slide

21. 制約
    ⭕ ドリフトが許容できる
    Terraform が有利なケース
    ❌ 切り戻しが難しい作業等で API 実行前にレビューしたい
    ❌ クラスタで専有できないリソースを扱いたい
    ⭕ 新しい自動化の仕組みを簡単に実装したい
    Wantedly での実践例
    © 2022 Wantedly, Inc.
    プレビュー用 wildcard domain の発行
    開発用なので多少壊れても問題ない
    対象クラスタ専用のリソースなので専有できる
    API 実行時のレビューは不要
    Terraform の Official Provider だけで実現可能
    利用できそうな Kubernetes Custom Controller がない
    

    View Slide

22. まとめ
    ● Kubernetes の機能拡張に Terraform が活用できる
    ● ドリフトが許容できれば
    Terraform が適用できる箇所は多い
    ● 適材適所の技術選択でよりよいアーキテクチャに
    © 2022 Wantedly, Inc.
    

    View Slide

23. エンジニア組織拡大中！
    Wantedly はエンジニア絶賛採用中です。
    ● 興味を持ってくれた方はぜひ話を聞きにきてください
    ● Wantedly Engineering Handbook も公開中
    © 2022 Wantedly, Inc.
    🎁 物理本も届きます！
    https://docs.wantedly.dev
    

    View Slide