この記事はKubernetes Advent Calendar 202319日目の記事です。
私は12月1日に株式会社スリーシェイクに入社した、小渕と申します。
kubernetesは初心者ですが、Sreake事業部のSREとしてしっかりキャッチアップして頑張ってまいります。
さて、12月18日に弊社の勉強会「3-shake SRE Tech Talk #8」が行われました。
半分以上はKubernetesの話だったので、この勉強会の話題を書きたいと思います。
↓開催中メモ代わりにX(旧Twitter)への自分の投稿はこちら（全部スレッドで連なっています）
19時から弊社スリーシェイクの勉強会を開催します！
— Shu Kobuchi(こぶシュー) (@shu_kob) 2023年12月18日
お時間のある方は是非ご参加ください！https://t.co/wu271V6Pbw#SRETT
↓セッション毎に分けて、書いてます。
スリーシェイク技術顧問 青山真也さん「KubeCon + CloudNativeCon NA 2023 Sessions for Site Reliability Engineers」
最初はメインセッション。スリーシェイク技術顧問で、サイバーエージェントの青山真也さん「KubeCon + CloudNativeCon NA 2023 Sessions for Site Reliability Engineers」
kubernetesユーザの方にはお馴染み、日本のkubernetesの第一人者の方です。
↓スライドはこちら
冒頭、ちらっとKubernetes完全ガイド第3版の話が進んでいるという「おお！」となるお話も！
↑こちらは第2版です。
k8sユーザのバイブルですよね。私も紙書籍版を持っています。
楽しみですね！
さて、セッションの内容としては、イベントのご紹介、参加者数の推移から、Keynoteで発表された2023年3月のDatadogの障害の話へ。
全てのデータセンターで60%のnodeが1時間ダウンした大規模な障害だったそう。
恐ろしいですね！！
DatadogのK8sクラスタのnodeは Ubuntu 22.04にVer. UP Rolloutをしていっているが、 20.04と22.04の間にあった必要のないルーティングポリシーを消す変更があり、障害に繋がったとのことです。
Auto Scalingが走って、救われた面もあるが、 50%強のスケールアウトを一気にしようとすると課題も多々ありました。
他人事ではなく、障害時に復旧するレベルでオートスケールを設計する必要がある、というのが教訓でした！
二つ目のお話「OpenTelemetry」
OpenTelemetryとは、Traceデータを収集するSDKで、YAMLで書くよりも、OTTLで書くと、コードの記述量が少なくて済むメリットも！
PrometheusからOpenTelemetry Collectorに置き換えると、約1/5にリソース消費を抑えられるなどのメリットもあるそうです。
ただし、Otelは多少バグがあるので使用上は注意とのことでした。
他に、Argoの話もしてくださいました。
Config Management Plugins(CMP)を使うと、HelmやKustomizeでない任意のツールでArgoCDと連携できるとのこと！
青山さんのメインセッションの後は、6名の方のLT！
社外の方3名、社内3名です。
スリーシェイク高村さん「障害対応のススメ」
新人SREはエキスパートSREとペアで障害対応しよう！というお話。
ペアで障害対応することにより、新人だけでなく、エキスパートSREも自分だけでは把握しきれない分も把握できます。
「ペアプログラミング」ならぬ「ペア障害対応」いいですね！
ポストモーテム作成も！私もスリーシェイクの一員として早くやってみたいですね！
ペア障害で属人化解消というメリットもあります！
incident-response.connpass.com
「Incident Response Meetup vol.1」という良さげな勉強会もあるのとのこと！でした！
mixi 清水さん「今年1年のEKS運用振り返り」
mixiさんのサービス「みてね」はEKSを使用しているそうで、運用の苦労話も聞けました。
OOMKilledが起こることもあり、CPU、メモリ等リソース調整しないといけないのは大変ですね。
Railsアプリはメモリを食い、再起動かからないとメモリ消費が増えてくるそうです。
定期的に再起動かけるようにして対応したそうです。
手動運用でアップデートが放置されがちだった箇所も、自動アップデートもできるようにしたのはすごいですね。
kubectlでPod作業するのを禁止したりだとか。その代わり踏み台からのアクセスできるようにしたり。
k8s運用の勉強になりました。
スリーシェイク bells17さん「KubernetesとCoreDNS」
自分もEKSでCoreDNSのステータス低下問題に悩まされたことがあったので、ありがたいお話でした。
bells17さんお得意のK8sのコードリーディングでCoreDNSのロジックに迫っていってました。
CoreDNSのデプロイからnameserverにIPアドレスを設定するまでの流れと、 CoreDNSによるService/Podの名前解決を解説してもらいました。
Kubernetes 側で定義されている DNS の仕様に従って、 CoreDNS 側で Kubernetes 用の plugin が実装されてるとのこと。
私もkubernetesの力をつけて、bells17さんの話を理解できるように頑張っていきます！
ZLab yosshi_さん「Grafana Agent を用いた Continuous Profiling」
Grafana Agentで eBPF が使われているそうです。
eBPF だと kernel level で情報がとれるので、より詳細な情報を取れるのではないか、という期待があるとのことでした。
Grafana Agentのgolang pullもあり、対象言語はGo言語のみで、取得対象はpprofの情報になるので、CPU以外にもメモリ等の情報も収集可能とのことでした。
スリーシェイク まさすずさん「Terraform使いがPulumiに入門する」
Terraform(HCL)の記述力に限界を感じていたので、Pulumiを使い始めた。とのことでした。
Pulumiとは任意のプログラミング言語でインフラ構築可能なプロビジョニングツールです。
TerraformやAnsibleなどインフラのツールって柔軟性に欠けるので、任意のプログラミング言語で柔軟にインフラ構築できるのはいいですよね！
Pulumi Cloudは個人で使う分には無料とのことでした！
FLUX cstokuさん「へーしゃで起こったGoogle Cloud課金事故事例」
Cloud Logging で Log Storage cost が爆増。
ログレベル Debug でメッセージが出力されるバッチが (バグで) 何回も呼ばれるようになっていた、とのことでした。
Cloud Loggingではログレベルに気をつけましょう！
また、Cloud Storageにて、Archive時に大量課金事故が発生したそうです。
これはArchiveで費用が嵩むのは仕方がないものの、想定できておらず、予算がつけれてなかったとのことでした。
それから、BigQueryをTerraformでLogical StorageからPhysical Storageに変更しようとしたら、 変更されておらず、Active Logical Strageでコスト増！
原因はドキュメントに乗っていたクエリが間違っており、 さらに、知らないうちに正しいものに更新されていた。という大変な思いも。
ドキュメントも鵜呑みにはできないですね。
課金事故勉強になりました！
アンケート
参加してくださった方ありがとうございました。
アンケートのご記入にもご協力くださいm(._.)m
アーカイブ動画
編集後、アーカイブ動画がアップロードされる予定です。
YouTubeの3-SHAKEチャンネルをご登録の上、お待ちください。
アドベントカレンダー次回へのバトンタッチ
Kubernetes Advent Calendar 202312月20日はHiroshi Hayakawaさんの記事です。
お楽しみに！
