yassy's note

なんかかきます

「Kubernetes Meetup Tokyo #42」に参加した

勉強会

6/24に開催された、「Kubernetes Meetup Tokyo #42」に参加したのでログを残す。

自分がKubernetesを触り始めということもあるだろうが、全体的にレベルが高い気がしたため、
理解できていないところも多々ある。

youtu.be

「KubeVirtによるIaaS基盤構築」

講師はヤフー株式会社の相良 幸範氏。

www.slideshare.net

  • KubeVirtとは？

    • Kubernetes上で動くクラスタアドオンであり、Podと同じWorkerノードで仮想マシンを起動できる仕組み。
      • コンテナ移行が困難なシステムであるが、Kubernetesで管理したいといった場合に利用できる。
      • 利用状況としては、Akamai/Apple/Cisco等の大企業で使用されているが、まだまだ数えるほどである。

  • VirtualMachineInstanceのマニフェスト(KubeVirtで仮想マシンを作成する際のマニフェスト)は、Podと比べると複雑になってしまう

  • KubernetesでIaaS基盤を設計する際、テナンシーの確保方法が課題となる。

    • テナント単位にKubernetesクラスタを払い出す

      • テナンシーの考慮が不要となり、障害時の影響範囲を最小化できる
      • 運用負荷が高い、サーバの利用率が低くなる

    • テナント単位でNamespaceを払い出す

      • 運用負荷を大幅に削減可能、サーバの利用率が高い
      • Kubernetes内のリソース隔離を検討する必要がある、コントロールプレーンへの負荷集中、仮想マシンの性能問題

  • CNIプラグインについて

    • KubernetesのNWはCNIとServiceリソース等で構成されるが、CNIによって機能が異なるため、要件を基に慎重に選定する

  • KubeVirtに対する印象

    • KubeVirtでもOpenStackのようにIaaS基盤は提供可能であるが、OpenStackのようにきめ細かな機能はない
    • 機能や実績も含め、まだまだ発展途上といった印象

感想

KubernetesでもOpenShiftのようにIaaS基盤が提供できると聞いて驚いた。
まだまだ発展途上ではあるものの、成熟すればKubernetesの他機能と連携することで用途がより広まるのではないかと思う。
今後の動向が楽しみだ。

「KubernetesとGatlingを使って、負荷試験に秒間10kユーザーをシミュレーションする方法」

講師はTenkan Inc.のZhaoqiang Wang氏。

  • Gatlingはオープンソースの負荷テストツールであり、レポート機能が存在

  • Gatlingは10kユーザ以上のアクセスのシミュレーションができない
    ※エラーメッセージを見た限りでは、ファイルディスクリプタとポート範囲が不足しているように見えたが、このクラスになるとチューニングでも対処できないのかな

  • OSS版のGatlingはJMeterのようにクラスタ機能をサポートしていないため、 複数のインスタンスで同じディレクトリにレポートを作成し、マージすることで解決させる

感想

Gatlingは使用したことはあるが、このクラスの高負荷試験の経験はないため、このような解決方法もあるだなと思った。
単一インスタンスからの使用しかなかったため、レポートをマージできることは知らなかった。

「How to setup Production Ready Istio?」

講師は株式会社ZOZOテクノロジーズのAkito Kobayashi氏。

speakerdeck.com

  • Istioとは？

    • サービスメッシュを実現するためのフレームワーク
      • DataPlaneにより、マイクロサービス間の通信を仲介・制御する
      • ControlPlaneにより、DataPlaneの制御を行う
    • Pod間のトラフィック制御を行える

  • Istioのリソース消費量見積もり

    • DataPlaneとControlPlaneに分けて考える
    • 負荷試験の結果ベースで見積もりを行う

  • ZOZOTOWNプラットフォーム基盤では、以下3つの負荷試験を実施

    • Istioベンチマーク試験
    • サービス単体負荷試験
      • 一気にすべてのサービスを通貫して試験を行うのではなく、モックを使用し、1つずつのサービスに対して試験を実施
        • リソース問題時に切り分けが難しくなるため
    • サービス結合負荷試験
      • このタイミングで初めて各サービスを連携して試験を行う

  • 監視

    • インフラメトリクスを監視するのではなく、Istioが上手く動作しているかのメトリクスを監視
    • 分散トレーシングを行うことで、複数サービスを跨いだ調査を行いやすくなる

  • 可観測性

    • DataDogのDashboardを使用し、問題の切り分けがしやすいグラフを作成

感想

Istioだけでなく、サービスメッシュを構築する上での試験方法や監視について参考になる講演だった。
試験については、過去案件にて一気にサービスを通貫して試験を行い、切り分けが難しくなった経験があるため、身につまされる話だった。

【LT枠】「Pod を force delete しないで」

講師は株式会社Preferred Networksの坂田氏。

  • ForceDeleteはkubernetes上で、Podの強制削除に使用されるコマンド

  • 実際のプロセスの終了を待たずにPodを削除する

  • ForceDeleteの仕様が問題になるケース

    • Pod内のプロセスが「D state」のままノードに残っていた場合
      • 「D state」は割り込み不可であるため、killでも消すことが不可能(SIGKILLも不可)
      • プロセスがリソースを掴みっぱなしで、リソースの確保が出来なくなる場合がある
      • 対処はOS再起動

  • Pod内のプロセス状態がよく分からない理由でForceDeleteはNG

感想

Pod削除時にForceDeleteを行いたくなる気持ちはあるが、改めて気軽にやるものではないなと認識した。