Kubernetes監視練習

、Kubernetesはじめに

Kubernetes（K8S）は、ユーザーがクラウド管理アプリケーションをデプロイの柔軟性を可能にする、アプリケーション管理、アプリケーションの展開と手動プロセスの拡張部分のアプリケーションを簡素化するオープンソース・プラットフォームです。

スケーラブル、フォールトトレラントプラットフォームとして、K8SはGoogleクラウド、MSのAzureと完全に互換性があり、そうAWSパブリッククラウド、プライベートクラウド、ハイブリッドクラウド、サーバクラスタリング、データセンターに、ほとんどすべてのインフラストラクチャに展開することができます。Kubernetes最大の明るいスポットは、自動展開と支援船が自動的にコピーされています。これも理由のK8S展開上のマイクロクラウドインフラストラクチャサービスの数が多いです。

二、K8S起源

もともと現在マイクロソフト、レッドハット、IBMおよびその他のソフトウェアの巨人ドッカーのメンテナンスアップグレードからのコミュニティの貢献によって、ラインおよびオープンソースに2014年に開発されたGoogleのエンジニアが開発しK8S。

容器の中に、同社のインフラストラクチャ全体の動作モードを開いてGoogleがだけでなく、コンテナにも積極的にすべてのGoogleクラウドサービスをサポートする、Linuxの技術を開発しています。K8Sロード操作は、コンテナの数千人を処理するために設計された生産クラウドプラットフォームで15年の経験に基づいています。Googleの週刊以上の200億コンテナを展開します。ライン上のK8S、Googleの社内開発プラットフォームボルグを通じて主にコンテナを展開する前に。ボルグは、大きな内部クラスタ管理システムであり、多くのアプリケーションやクラスタタスク、開発における長年の経験を実行していると基礎K8S技術を築きました。

三、K8S作品

それは高いを通じて、K8S予測可能性、スケーラビリティおよびサービスのライフサイクルを通じた高可用性アプリケーションおよびコンテナ管理による開発者を支援することを目的とK8S性質に異なるマシン上のアプリケーションコンテナ部門の協調システムであり、抽象化のレベルは、マシンに複数のマシンを統一します。これは、大規模環境での動作があるために不可欠です。

K8S画像とドッカーコンテナ管理機能を実行する能力だけでなく、互換性がRKT及び他の容器CoreOSエンジンを最適化するだけでなく。

アーキテクチャ上の図は、K8S作品を示しています。図マスターは、多くのポッドを含む一連のコンポーネントが含まれています。特定のアプリケーションのための「論理ホスト」のためのポッドモデル。各ポッドのアプリケーションは、1つの以上の容器、ストレージリソース、および独自のIPネットワーク操作の詳細コンテナが含まれています。ポッド原子は容器の最小単位です。理論的には、ポッドのアプリケーションは、高度に結合された1つまたは複数が含まれています。理想的には、各コンテナには、ポッドが含まれています。

每个进程包含一个API server、一个scheduler和多个controller。

API server负责暴露K8s API、处理REST操作及后续更新。Scheduler负责将未部署的Pod匹配到合适虚拟机或物理机上。如果没有合适的机器，则Pod将处于未分配状态，直至出现合适的节点。Master运行集群级别的其他功能，通过嵌入式controller完成创建端点、发现节点、复制控制等操作。由于controller设计灵活且可扩展，Kube管理员可自行创建controller。Kube通过API server监控K8s集群的共享状态，并对集群状态进行调整，确保当前状态与理想状态一致。

K8s提供支持容器化应用统一自动化、控制和升级的各项功能，包括企业级容器部署、内置服务发现、自动扩展、持久化存储、高可用、集群互通和资源装箱等。

依赖这些功能，K8s实现了对单体应用、批处理应用及高度分布式微服务应用等不同应用架构的支持。

四、K8s监控实践中的挑战

2014年上线以来，K8s一直在变革容器技术，已经成为快速批量启动应用的关键工具。与此同时，挑战也随之而来，容器编排极其复杂。

K8s虽然已经极大地简化了容器实现和管理过程中从调度、配置到状态自动维护等一系列任务的操作难度，但监控方面依然存在挑战：

• 相互通信的应用分布在不同的云服务平台上。K8s本质上是一个通用平台，用户可在平台上自由部署应用。企业一般会采用多云端解决方案，不仅能够减少对单一云服务平台的依赖，还能缩短故障停机时间，避免数据丢失。但这种部署方式也给实时数据抓取和应用状态监控带来了挑战。
• 在动态基础设施上不断迁移应用。由于应用处于频繁迁移状态，因此很难做到所有平台和协议之间的完全可见，这就会隐藏系统的瓶颈问题。很多公司的基础设施上都运行着多个应用，因此这种问题是不可避免的。如果没有稳健的监控系统，用户便无法发现应用的潜在问题。

• 监控对象数量繁多且极为复杂：K8s由很多组件构成，非常复杂，因此要监控K8s，就必须监控下列所有对象：

  • 集群容量和资源利用情况：（a）Node：确保K8s所有节点的状态，监控CPU、内存和硬盘的使用情况；（b）Pod：确保所有已实现Pod状态正常；（c）Container：根据配置的消耗上限监控CPU和内存的消耗情况。
    应用：根据请求率、吞吐量、错误率监控集群中应用的性能和可用性。
  • 终端用户体验：监控移动应用和浏览器性能，优化加载时间和可用性，提高客户满意度。
  • 配套基础设施：前文提到，K8s的运行平台也非常重要。
• 操作细节：K8s的所有核心组件（即kubelet、Kube controller manager和Kube scheduler）都有很多标记。这些标记决定了集群的操作和运行方式，其初始默认值一般较小，适用于规模较小的集群。随着集群规模的扩大，用户需要及时对集群进行调整，并监控K8s的标签和注释等细节。

但监控工具从K8s抓取大量数据时会影响集群性能甚至导致集群故障，因此需要确定监控基线。需要诊断故障时，可适当调高基线值。

调高基线值的同时要部署更多master和node，提高可用性。涉及大规模部署时，可单独部署专门存储K8s数据的集群，这样能够保证在创建监控事件、检索监控数据时，主要实例的性能不受影响。

五、从源头上监控K8s

和很多容器编排平台一样，K8s具备基本的服务器监控工具。用户可对这些工具进行适当调整，以便更好地监控K8s的运行情况。主要工具如下：

• K8s仪表盘：插件工具，展示每个K8s集群上的资源利用情况，也是实现资源和环境管理与交互的主要工具。
• 容器探针：容器健康状态诊断工具。
• Kubelet：每个Node上都运行着Kubelet，监控容器的运行情况。Kubelet也是Master与各个Node通信的渠道。Kubelet能够直接暴露cAdvisor中与容器使用相关的个性化指标数据。
• cAdvisor：开源的单节点agent，负责监控容器资源使用情况与性能，采集机器上所有容器的内存、网络使用情况、文件系统和CPU等数据。
• 使いやすいcAdvisorが、欠点があります：まず、アプリケーションの実際のパフォーマンスを分析するために、リソースの使用率を監視するための唯一の根拠は、第二には、長期保存や傾向を分析する能力を持っていません。
• KUBE-状態メトリック：メトリックにポーリングKubernetesのAPI、およびKubernetes構造化された情報。
• メトリックサーバ：Kubeletの概要APIからのデータのメトリクス・サーバインデックスタイミング取得、およびフォームは、メトリック-APIにさらされています。

次のように監視し、全体のプロセスは、次のとおりです。

• すべてのクラスタノード上のcAdvisorのデフォルトのインストール、データの収集コンテナと索引ノード。
• インデックスデータにさらさkubelet APIによってKubelet。
• 利用可能なすべてのノードを分析するメトリックは、容器及び使用データkubelet用API、及びインデックスデータを送信する要求ノードはKubernetes APIによって重合にさらされます。

上記の基本的なツールは、詳細なアプリケーション監視データを提供していませんが、ユーザーが状況や基礎となるホストK8Sノードを理解するのに役立つことができますが。

一般的には、K8Sクラスタ管理者は、グローバルな監視に焦点を当て、およびアプリケーション開発者は、アプリケーションレベルでの状況を監視することに焦点を当てています。入力を制御するデータを収集するために、総合的なシステムを可能な限りコストながら、しかし、両方の共通の願望が監視されています。プロメテウスと扇子：来週の記事、我々は2つの実行可能な監視プログラムをご紹介します。二つのプログラムは、開発者がパフォーマンスを追跡するのに役立ち、障害K8S主要なコンポーネントを見つけ、アラートを受信するための包括的なシステムレベルの監視データを提供することができます。

著者：STEFAN THORPE

翻訳監視Kubernetes

UAVStackインテリジェントな運用・保守に開始