アリクラウドK8Sクラスターの重要な特徴は、クラスタノードが動的に増減することができます。この機能により、リソースの不足した場合の新しいコンピューティングノードに、クラスター展開するだけでなく、コストを節約するためにノードを解放するときに、リソースの使用率を減らすことができます。
この記事では、我々は能力の原則アリクラウドK8Sクラスタ膨張と収縮の実現を議論します。、その原理を理解し、問題に直面して、我々は効率的にトラブルシューティングを行い、原因を突き止めることができます。私たちの議論は、現在のバージョン1.12.6に基づいています。
ノードの増加原理
アリ雲K8Sクラスタノードが既存のノード、クラスター展開、および自動スケーリングを追加したクラスタのアプローチに追加することができます。ここで、ノードは、手動と自動にノードを追加しなければならない分けることができ、既存のノードを追加するために追加されています。ノードに関連するアセンブリを増加させる、ノード準備、弾性伸縮（ESS）、制御、クラスタAutoscalerスケジューラ。
手動で既存のノードを追加します
ノードは、通常のECSインスタンスに、実際には、準備ができている、インストールプロセスK8S構成されたクラスタノード。このプロセスは、コマンドのみで完了することができます。このコマンドは、ECS上で動作パラメータとして、その後OpenAPIのトークンを、attach_node.shスクリプトをダウンロードするカール使用しています。
カールのhttp：///public/pkg/run/attach//attach_node.sh | bashの-s - --openapiトークン
ここでトークン右キーで、値は、現在のクラスタに関する基本的な情報です。アリクラウドK8S制御クラスタ、手動でこの権利、およびバックユーザーにトークンとして鍵を生成します既存のノードを追加する要求を受信したとき。
このトークンの存在の（キー）の値は、それがattach_node.shスクリプトを作ることができるということです、ECSの基本的な情報（値）、およびノード上の基本的な情報への匿名のクラスタインデックスは準備ができている必要不可欠です。
全体的に、ノードは2つのこと、読み書きを行う準備ができています。そのデータ収集は、書き込み、ノード構成を読み取ります。
ここでは読み取りと書き込み処理、大多数は、スクリプトを読んで内容を理解するために来ることができる、非常に基本的なものです。唯一の特別なノートでは、マスタの登録プロセスにノードを参加kubeadm、です。このプロセスは、クラスタノード間の相互信頼の確立を必要とし、新しいマスターを追加します。
一边，新加节点从管控处获取的bootstrap token（与openapi token不同，此token是value的一部分内容），实际上是管控通过可信的途径从集群Master上获取的。新加节点使用这个bootstrap token连接Master，Master则可通过验证这个bootstrap token来建立对新加节点的信任。
另一边，新加节点以匿名身份从Master kube-public命名空间中获取集群cluster-info，cluster-info包括集群CA证书，和使用集群bootstrap token对这个CA做的签名。新加节点使用从管控处获取的bootstrap token，对CA生成b新的签名，然后将此签名与cluster-info内签名做对比，如果两个签名一致，则说明cluster-info和bootstrap token来自同一集群。新加节点因为信任管控，所以建立对Master的信任。
自动添加已有节点
自动添加已有节点，不需要人为拷贝黏贴脚本到ECS命令行来完成节点准备的过程。管控使用了ECS userdata的特性，把类似以上节点准备的脚本，写入ECS userdata，然后重启ECS并更换系统盘。当ECS重启之后，会自动执行Userdata里边的脚本，来完成节点添加的过程。这部分内容，大家其实可以通过查看节点userdata来确认。
!/bin/bash
mkdir -p /var/log/acs
curl http:///public/pkg/run/attach/1.12.6-aliyun.1/attach_node.sh | bash -s -- --docker-version --token --endpoint --cluster-dns > /var/log/acs/init.log
这里我们看到，attach_node.sh的参数，与前一节的参数有很大的不同。其实这里的参数，都是前一节value的内容，即管控创建并维护的集群基本信息。自动添加已有节点省略了通过key获取value的过程。
集群扩容
集群扩容与以上添加已有节点不同，此功能针对需要新购节点的情形。集群扩容的实现，在添加已有节点的基础上，引入了弹性伸缩ESS组件。ESS组件负责从无到有的过程，而剩下的过程与添加已有节点类似，即依靠ECS userdata脚本来完成节点准备。下图是管控通过ESS从无到有创建ECS的过程。
自动伸缩
前边三种方式是需要人为干预的伸缩方式，而自动伸缩的本质不同，是它可以在业务需求量增加的时候，自动创建ECS实例并加入集群。为了实现自动化，这里引入了另外一个组件Cluster Autoscaler。集群自动伸缩包括两个独立的过程。
其中第一个过程，主要用来配置节点的规格属性，包括设置节点的用户数据。这个用户数据和手动添加已有节点的脚本类似，不同的地方在于，其针对自动伸缩这种场景，增加了一些专门的标记。attach_node.sh脚本会根据这些标记，来设置节点的属性。
!/bin/sh
curl http:///public/pkg/run/attach/1.12.6-aliyun.1/attach_node.sh | bash -s -- --openapi-token --ess true --labels k8s.io/cluster-autoscaler=true,workload_type=cpu,k8s.aliyun.com=true
而第二个过程，是实现自动增加节点的关键。这里引入了一个新的组件Autoscaler，它以Pod的形式运行在K8S集群中。理论上来说，我们可以把这个组件当做一个控制器。因为它的作用与控制器类似，基本上还是监听Pod状态，以便在Pod因为节点资源不足而不能被调度的时，去修改ESS的伸缩规则来增加新的节点。
这里有一个知识点，集群调度器衡量资源是否充足的标准，是“预订率”，而不是“使用率”。这两者的差别，类似酒店房价预订率和实际入住率：完全有可能有人预订了酒店，但是并没有实际入住。在开启自动伸缩功能的时候，我们需要设置缩容阈值，就是“预订率”的下线。之所以不需要设置扩容阈值。是因为Autoscaler扩容集群，依靠的是Pod的调度状态：当Pod因为节点资源“预订率”太高无法被调度的时候，Autoscaler就会扩容集群。
节点减少原理
与增加节点不同，集群减少节点的操作只有一个移除节点的入口。但对于用不同方法加入的节点，其各自移除方式略有不同。
首先，通过添加已有节点加入的节点，需要三步去移除：管控通过ECS API清楚ECS userdata；管控通过K8S API从集群中删除节点；管控通过ECS InvokeCommand在ECS上执行kubeadm reset命令清理节点。
其次，通过集群扩容加入的节点，则在上边的基础上，增加了断开ESS和ECS关系的操作。此操作由管控调用ESS API完成。
最后，经过Cluster Autoscaler动态增加的节点，则在集群CPU资源“预订率”降低的时候，由Cluster Autoscaler自动移除释放。其触发点是CPU“预订率”，即上图写Metrics的原因。
总结
全体として、K8Sクラスタが増加するノードと減少、主に四つの成分、すなわちクラスタAutoscaler、ESS、および制御ノード自体（調製またはクリーンアップ）を含みます。シーンに応じて、我々は、さまざまなコンポーネントのトラブルシューティングをする必要があります。前記クラスタAutoscaler通常ポッド、および他のポッドと変わらないログ取得; ESSコンソールは、専用の独自を有する弾性的に伸長は、我々は、コンソールでその伸縮のインスタンスログ相関設定およびステータス、伸縮ルールのトラブルシューティングを行うことができ;そして、実際には、準備とクリーンアップノードのために、最終的には対応するスクリプトの実行中に調査をして、制御のログは、ログ機能を調べることで見ることができます。
その理由上記の大半は、あなたがトラブルシューティングに役立てたいです。