LoginSignup
3
3

More than 5 years have passed since last update.

@mochimoching

（僕にとって）はじめてのKubernetes

Last updated at Posted at 2018-09-18

まず、読み方

  • ギリシャ語で「航海長」の意味
  • クーべネティス（Wikipedia）
  • クーベルネテス ←これが一般的？
  • クーヴァネィテス ←自分はこっちで読む
  • k8sと略すこともある（kとsの間に8文字あるから）

おさらい（MSAとDevOps）

  • 目指すところは同じ
  • システムを改善し、迅速・安全にリリース「し続け」る（ビジネス価値の提供)
  • 市場のニーズ変化＞システムの更新頻度になりつつある
  • キャッチアップできないと、ビジネスチャンスをうしなう

いまのままだとなにがだめ？

  • システムが複雑化しすぎ（モノリシック）
    • 直しづらいし（直すのやめる？→営業困惑）
    • 直すの失敗したら全部壊れるし（開発困惑）
    • 直せてもビルドやテストに時間かかるし（開発困惑）
    • リリースのたびにシステム止めなきゃならないし（運用困惑）
    • 機能とか利用者増えたらキャパシティ見直さなきゃいけないし（運用困惑）
    • タイムリーにリリースできないからプロモーションしづらいし（営業困惑）
  • ...といった面倒なことがある。

じゃあどうするの？

  • システムを「シンプル」で「変更のしやすい」粒度に切り刻もう（MSA）
    • １サービスの中身の見通しが良くなった
    • 直すの失敗してもシステム全体が壊れることはなくなった
    • 小さくなったサービス単位でビルドでき、ビルドやテスト時間が短くなった
    • 変更を加えたサービスの部分だけ、インフラの設定見直しや増減がしやすくなった（※）
    • サービス単位でリリースでき、システム全体を停止しなくてよくなった（※）
  • 「xxxようになった（ソース修正以外）」を人間の手でやると、時間かかったりミスが増える
    • 機械にやらせる→ツール（CI/CD、構成管理、コンテナ等）を導入して自動化しよう（DevOps）
      • プロセスとか文化面も大事だがひとまず置く

じゃあどうするの？（続き。上の※のところ）

  • サービスの置き場所を考える（あくまで理想論。現状のしがらみもあるし）
  • 物理サーバ直接？、VM？コンテナ？
  • 今日び、物理サーバ直接は無いかな
  • 仮想化技術（VMかコンテナ）になる。どっちがいい？
  • VMでも良いけど重い（リソース食うし起動遅い）
  • コンテナのほうが軽い（リソース節約できるし起動早い）
    • MSA化するとホスト数増えるので軽いほうが有利
    • 技術的詳細は省略
  • Dockerがデファクト。
  • 1サービス1コンテナが基本

課題（サービスを切り出して終わり、ではない）

  • サービスをシンプルにした代わりに、複雑さをその周辺に追い出しているだけでは？
    • いやおう無く課題として複雑さに対峙しなくてはならなくなる
  • MSAでは一応いろんな解決策（カッコ内）が提示されてる（詳しくはMSA本読みましょう）
    • サービスってどう呼び出すの？名前で呼ぶの？（サービスディスカバリ）
    • サービスとサービスをどうつなぐ？（REST、オーケストレーション/コレオグラフィ）
    • サービス間のトランザクションどうするの？やるの？やらないの？（CQRS、結果整合性）
    • 認証認可の仕組みはどこがやるの？各サービスがやるの？（OAuth、SSO）
    • プロパティ値や環境差分が各サービスに分散してしまった？（Configサーバとか）
    • サービスごとにログがばらけてしまった？（分散トレーシング）
    • サービスを修正したら他のサービスが動かなくなった？（Consumer-Driven Contract）
    • あるサービスが落ちたら友連れで他のサービスも落ちた？（サーキットブレーカー）
    • サービスのAPIがたくさんあってわけわからんしクライアントからのリクエスト回数はんぱない！（APIゲートウェイ）
    • サービスの呼び出し順序とか依存関係がわけわからん！（サービスメッシュ）
    • サービスごとにリリースする人がいるけど、リリースの仕方って統一されている？（ブルーグリーンデプロイメント、カナリヤリリース）
    • サービスが増えたせいで管理すべきコンテナが増えすぎ？（コンテナ管理）

コンテナ管理ツールとしてのKubernetes

  • OSSのオーケストレーションツール。主要クラウドも対応
  • 下記に挙げたようなことをコマンドで自動化できる
    • コンテナの管理（デプロイとか）
    • ネットワーキング（コンテナ間通信とか外部との通信）←Docker単体だとやってくれない
    • オートスケール（コンテナの増減）
    • 通信の振り分け（負荷分散とか）
  • クラスタ構成になってる
    • オンプレなら物理マシン（master：1台、node：n台）にk8sをインストール
    • クラウドなら気にしない？
  • 用語
    • container：Dockerコンテナ。Dockerじゃなくてもよいらしいが基本はDocker
    • Pod：containerの集合体。1つ以上のcontainerを持つ
      • 「1Pod=1サーバ」とイメージしておけばよい
      • kubernetesではPod単位で操作（作成、起動、停止、削除）を行う
      • 各Podに1つの内部IPを持つ
    • Scheduler：Podをどのnodeに割り当てるかを決めてくれる
    • Deployment：Podをデプロイする。Schedulerとの違いは？？（要調査）
    • Service：クラスタの外からPodに接続するための口

MSAの基盤としてのKubernetes

  • 「コンテナ」→「サービス」に読み替えてみる
  • Kubernetesは「世界最大級のMSAをもつ」Googleが社内で使用していたものをOSS化したもの
    • Google以外の大手クラウドベンダも対応、今後のデファクトになるのは確実
    • Kubernetes単体で機能が増えるのか、外部ツールと連携の形かは分からないが、MSAの課題を解決するソリューションが今後も増えていく（のでは？）
  • 例）Istio/Envoy（サービスメッシュの機能を持つソフトウェア）
    • サービスメッシュでは、マイクロサービス間の通信を統一的な仕組みで制御。これにより、きめ細かなセキュリティの確保、流量制御、フェイルオーバー、ブルー／グリーンデプロイメント、カナリアリリースなどを容易にする
    • kubernetesのyamlに設定を書いて、PodにProxyを注入する

参考

3
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
3
3