Clever Geek Handbook

小さなプロジェクトでのKubernetesでの経験（レビューおよびビデオレポート）

Dmitry Stolyarov（Flant）とRIT ++ 2017でのRootConfでのKubernetesについての講演



6月6日、ロシアのインターネットテクノロジーフェスティバル（RIT ++ 2017）の一環として開催されたRootConf 2017カンファレンスで、「継続的な展開と展開」セクションで「小規模プロジェクトでのKubernetesの経験」というレポートが作成されました。 デバイス、操作の原則、Kubernetesの主な機能、および小規模プロジェクトでのこのシステムの使用方法について説明しました。



伝統的に、私たちはレポート （約1時間、記事よりもはるかに有益）とテキスト形式での主な絞り込みのビデオを提示して喜んでいます。



背景



最新のインフラストラクチャ（Webアプリケーション用）は、1台のサーバーにDBMSを備えたバックエンドから、使用されるサービスの大幅な増加、仮想マシン/サーバーへの分離、負荷分散と水平スケーラビリティを備えたクラウドソリューションへの移行、そしてマイクロサービスへと長い道のりを歩んできました。



最新のマイクロサービスインフラストラクチャの運用では、アーキテクチャ自体とそのコンポーネントの数に起因する多くの困難があります。 以下とそれらを区別します。



  1. ログの収集。
  2. メトリックのコレクション。
  3. 監督（サービスの状態を確認し、問題が発生した場合にサービスを再起動します）;
  4. サービス発見（サービスの自動発見）;
  5. インフラストラクチャコンポーネントの構成の更新の自動化（新しいサービスエンティティを追加/削除する場合）;
  6. スケーリング
  7. CI / CD（継続的インテグレーションと継続的デリバリー）;
  8. ベンダーロックイン（選択した「ソリューションプロバイダー」への依存について話している：クラウドプロバイダー、ベアメタル...）。


レポートのタイトルから簡単に推測できるように、Kubernetesシステムはこれらのニーズに対する答えとして登場しました。



Kubernetesの基本



Kubernetesアーキテクチャは全体として、マスター（複数ある場合もあります）と多くのノード（最大5000）のように見え、それぞれにインストールされます：





マスターには：





これらすべてに加えて、kubectl管理ユーティリティとYAML（宣言型DSL）形式で記述された設定があります。







使用に関しては、Kubernetesはこれらすべてのマスターとノードを組み合わせたクラウドを提供し、インフラストラクチャの「ビルディングブロック」を実行できるようにします。 このようなプリミティブには次のものが含まれますが、これらに限定されません。





YAML形式の囲炉裏とReplicaSetの説明の例： 



apiVersion: v1 kind: Pod metadata: name: manual-bash spec: containers: - name: bash image: ubuntu:16.04 command: bash args: [-c, "while true; do sleep 1; date; done"]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     


 apiVersion: extensions/v1beta1 kind: ReplicaSet metadata: name: backend spec: replicas: 3 selector: matchLabels: tier: backend template: metadata: labels: tier: backend spec: containers: - name: fpm image: myregistry.local/backend:0.15.7 command: php-fpm


これらのプリミティブは、いくつかの例外を除いて上記のすべての呼び出しに応答します：構成の更新の自動化は、Dockerイメージのアセンブル、新しいサーバーの注文、それらへのノードのインストールの問題を解決しません。CI/ CDでは、準備作業（CIインストール、アセンブリルールの説明Dockerイメージ、KubernetesでのYAML設定の展開）。



私たちの経験：アーキテクチャとCI / CD



小規模プロジェクトとは、小規模（最大50ノット、最大1,500炉床）および中規模（最大500ノット、最大15,000炉床）を意味します。 次のような3つのハイパーバイザーで最小のベアメタルプロジェクトを作成します。







Ingressコントローラーは3つの仮想マシンにkube-front-X



ています（ kube-front-X



）：





（図に示されているPacemakerの代わりに、VRRP、ucarp、またはその他のテクノロジーが存在する可能性があります。特定のデータセンターに依存します。）



継続的デリバリーチェーンは次のようになります。







説明：









小規模プロジェクトの場合、インフラストラクチャは、構成されたストレージ（Ceph、AWS、GCE ...）とIngressコントローラーを備えたコンテナークラウド（実装はセカンダリ-利用可能なハードウェアとニーズに依存）のように見え、（このクラウドに加えて）追加の仮想マシンを起動して実行できますKubernetes内に配置しないサービス：







おわりに



私たちの観点からすると、Kubernetesはあらゆる規模のプロジェクトで使用するために成熟しています。 さらに、このシステムは、フォールトトレランスと水平スケーリングを備えたプロジェクトを非常にシンプルで信頼性の高いものにする非常に最初からの絶好の機会です。 主な落とし穴は人的要因です。小さなチームにとっては、必要なすべての問題を解決するスペシャリストを見つけることは困難です（広範な技術的知識が必要です）、または彼は高価すぎます（すぐに退屈します）。



ビデオとスライド



パフォーマンスのビデオ（約1時間）がYouTubeに公開されました 。



レポートのプレゼンテーション：







継続



このレポートに関する最初のフィードバックを受け取ったので、開発者向けに、このシステムのデバイスについて詳しく説明するKubernetesに関する特別な一連の紹介記事を準備することにしました。 今後数週間以内に開始します-ブログの更新をお楽しみに！



PS



以下のブログだけでなく、CI / CDについてもお読みください。





More articles:


All Articles