Upgrade to Pro — share decks privately, control downloads, hide ads and more …

ICTSCにおけるk8s運用の話

 ICTSCにおけるk8s運用の話

ICTSCにおいてのk8sクラスタはさくらのクラウドに全て載せているが、このスライドではどのように運用しどの様な構成のかを述べる

8e1e170fce92e2300b3bb1780326dc9a?s=128

Takeru Hayasaka

March 07, 2021
Tweet

Transcript

  1. ICTSCにおける k8s運用の話 Takeru Hayasaka(@takemioIO) 2021/03/07 ICTSC2020 LT会 https://unsplash.com/photos/SInhLTQouEk 1

  2. 自己紹介 1. 竹/TakeruHayasaka/@takemioIOと言います k8sの運用とかなんでもやってる人 2. パケット処理書きすぎてoptionなしL3までなら 目で読めるようになった.... 3. 最近の趣味はなろう小説を漁ること 4.

    来年から京都に行くんですが地元が宮城で 友達と彼女がいないので募集しています。 助けてください(メソメソ) 5. #ictsc_bar_night でトラコンBAR というトークショウをやってる 2
  3. アウトライン 1. Overview: 今年のk8sのトポロジー 2. ICTSCにおけるk8s運用とは? • プロビジョニング編 • ストレージ

    編 • ネットワーク編 • 監視編 • アプリケーション編 3. まとめと一年を振り返ってみて 3
  4. Overview https://unsplash.com/photos/ur7BDi9MpXg 4

  5. ICTSCにおいてのk8sクラスタ ICTSCにおいてのk8sクラスタはさくらのクラウドに全て乗ってる • スコアサーバーを載せたり • 監視基盤を載せたり • VMのプロビジョニングをするためのツールを載せたり... とかの所謂出来れば落としたくないものとかを載せて動かす 運用を行っています

    • 主に面倒を常に見てるのは大体4-5人ぐらい (@takemioIOが取りまとめや全体のアーキテクトをやってるが 運営がこれ欲しいとか言って雑にPRが飛んでくることもある) • 基本インフラ紹介をあまりちゃんとされないところの裏方さんです コンテスト直前によくSREみたいなことをやってると思ってもらうと イメージしやすいかも??? 5
  6. k8sクラスタの論理構成 6

  7. k8sクラスタを含めた全体像 7

  8. ICTSCにおいてのk8sクラスタ • prd: 皆さんがアクセスするものを載せるやつ • dev: 壊していいやつ • wsp: 監視系やCDなどを載せるところ

    • 1クラスタあたりのリソース • global v4addr /27 • master x 3 • 1node: 4vcpu, 8mem, disk 100 • worker x 3 • 1node: 8vcpu, 32mem, disk 250 • (LB + BGP Router) x 3 • 1node: 4vcpu, 8mem, disk 40 • こんなに大量のリソースのご提供はさくらインターネット様からの リソースで動いている。ありがとうございます🙇‍♀ 8
  9. ICTSCにおいての運用リポジトリ 9

  10. ICTSCにおいてのmanifestリポジトリ 10

  11. ICTSCにおいての運用リポジトリ 11

  12. ICTSCにおいての運用リポジトリ 12

  13. ICTSCにおいての運用リポジトリ 13

  14. ICTSCにおいての運用リポジトリ 14

  15. ICTSCにおいての運用リポジトリ 15

  16. ICTSCにおいての運用リポジトリ 😇 16

  17. ICTSCにおいての運用リポジトリ なんとかワイワイ検証をしつつ、 SREぽい裏方さんをやっています🙇‍♀🙇‍♀🙇‍♀ 17

  18. プロビジョニング編 https://unsplash.com/photos/ur7BDi9MpXg 18

  19. k8sクラスタの論理構成 19 再掲

  20. プロビジョニング: VMを作る • さくらのクラウドにVMを作る -> terraform 20 • sakura cloudの

    tfproviderを 使ってVMをプロビジョニング • S3のバックエンドを導入して tfstateをリモートに置いた (自分たちでminioを立てた)
  21. プロビジョニング: VMに流し込み • kubeletなどをインストール -> ansibleで流し込み 21 • dynamic inventryをやって

    pythonからminioにある tfstateをfetchし、そこに ある接続情報をまとめて ansibleが接続しにいく • 同時に管理用userなどを作る
  22. プロビジョニング: kubeapi serverのLB構築 • haproxyを構築 22 • haproxyを構築することで 複数のmaster nodeを置くこと

    が可能になる • ←実際のコンフィグ例
  23. プロビジョニング: k8sの構築 • kubeadmを利用して構築 23 • ←こんな感じのコンフィグを 用意しておいて sudo kubeadm

    init --config=kubeadm-config.yaml をする感じ
  24. ネットワーク編 https://unsplash.com/photos/ur7BDi9MpXg 24

  25. k8sクラスタの論理構成 25 再掲

  26. ネットワーク: アプリを外部に公開する • 外部にアプリケーションを公開 -> MetalLB 26 • ベアメタル環境で使用できる KubernetesのExternal

    Load Balancerの実装 • L2 モード:リーダーノードを選出 =>負荷に偏り BGPモード:外部ルーターが ECMPでロードバランス • 複数アドレスプール: 使用したいアドレス帯をService で指定可能 metallb-config.yaml ingress-service.yaml
  27. ネットワーク: Ingress • Ingress Controller -> Nginx Ingress Controller 27

    • SSLの終端 • サービス転送 • nginxなのでhostpathとして 利用やサーバーサイドの やりとりに対する処理など • 複数台にスケールするので L7 LBとしての意味も持つ
  28. ストレージ編 https://unsplash.com/photos/ur7BDi9MpXg 28

  29. k8sクラスタの論理構成 29 再掲

  30. ceph+rookについて rookというツールでceph を構築をして分散ストレージ を導入してる 我々の環境だと filestoreで per nodeごとに おいて運用している (bluestoreだとメモリをすごく

    必要にするなどの理由から このようにしている) 30
  31. cephについてのdashboard 31

  32. 監視編 https://unsplash.com/photos/ur7BDi9MpXg 32

  33. k8sクラスタの論理構成 33 再掲

  34. 監視基盤の構成 34 今年度利用しているものたち • Zabbix (新規) ◦ Router,IPMIのデータ取得 • Grafana

    ◦ Zabbix, prometheusの可視化 • prometheus • AlertManager ◦ prometheusのalert • elastiflow (k8sでは新規) ◦ sflow • ELK ◦ syslog...etc.. 本戦10日前から監視基盤を頑張って一人で建てました. これから先のスライドは10日間頑張ったものを見てください! by umeda
  35. Zabbix ZabbixでJuniper MX5のsnmpを取得し Grafanaで可視化しています。 本日15:30ごろまでのトラフィックグラフです。 35

  36. 問題VMの監視 36 問題VMの監視を行いました。 展開の際に正常にVMが立ち上がったかのチェックを行えました。

  37. Ceph Dashboard 37 Cephよくわからん!!!

  38. ElastiFlow 38 きれいだな~

  39. 1day 午前3時prometheusが死んでた! msg="append failed" err="write to WAL: log samples: write

    /etc/prometheus-data/wal/00001007: disk quota exceeded" 39 umedaは寝ていたので、えるとさんがトラコンしてくださいました。:pray: まさか、10日で20GB食うとは知らないじゃん..! ストレージの永続化した人←umeda prometheusが死んでもalertは飛ばない!!
  40. 監視は以上です。 ありがとうございました。 by umeda 40

  41. アプリケーション編 https://unsplash.com/photos/ur7BDi9MpXg 41

  42. k8sクラスタの論理構成 42 再掲

  43. ArgoCD 43

  44. ArgoCD 44

  45. ArgoCDの全体の構成 45

  46. pomerium 46 ◦ Pomerium: アプリの前段 にプロキシとして存在して外 部のIDプロバイダーを用いて ユーザを識別する ◦ githubなどのorgをictsc

    は使っている ◦ https://wiki.icttoracon.net/ictsc2020/infra/cluste r/Pomerium#Pomerium%E3%81%AB%E3%8 1%A4%E3%81%84%E3%81%A6
  47. pomerium: ビフォー 47

  48. pomerium: アフター 48

  49. まとめと見所(盛り沢山) 1. 複数台のクラスターを用意してカナリア を入れてより本番を壊さないようになった 2. 以前はワンオペSPOF野郎(@takemioIO)だったがインフラチーム としてちゃんとわかる人が増えた 3. スコアサーバーや監視等にはargoCDが生えてアプリケーションの デプロイにアプリケーションエンジニアがkubectl

    applyをしなくて も生きていけるようになった 4. 監視などの接続性についてはgithubのOrgを通じて認証することで より安全に使えるようになり、最高の監視です最高! 5. k8sでもrook+cephを導入してDisaster対策済み 6. MetalLB, nginx ingressを合わせてマルチティアLBに、vyosを入れること でBGPモードでなおかつVPNなども合わせたネットワーク を使えるようになった 49