Kubernetesは、自動化、展開、大規模なスケーラブルなアプリケーションコンテナ管理をサポートGoogleのオープンソースのコンテナオーケストレーションエンジン、です。迅速なクラウドネイティブ技術の台頭、そして実際にKubernetesは、標準のアプリケーションコンテナプラットフォームとなっている今、すべての年齢層のより多くの企業は、ますます生産に使用されているとも適用されます。
2016年の初めから私たちのコンテナプラットフォームは、探検する事前調査、システム構築やプラットフォームの床三つの段階を経ています。
ここでは、ネットワーク、ストレージ、クラスタ管理および監視・運用・保守の面から、私たちの次の散歩を構築するための容器のクラウドプラットフォームの歴史を共有するためにKubernetes、我々はあなたにいくつかの考えやインスピレーションを与えることを願っています。
、ネットワークkubernetes
今までのコンテナネットワークの開発を、平面のパターンになるとなっています。ハッチが実際にドッカーのCNMとGoogle、CoreOSを指します、Kuberenetesは、CNIを導きました。まず、明確CNMなくCNIのネットワークで、彼らは彼らの研究開発の観点から、ネットワークの仕様およびネットワークシステム、あるあなたがイェジンハオ、キャリコとイェジンハオの基礎となるフランネルを使用しているインタフェースの束である、彼らは、CNMを気にしないとCNIの懸念は、ネットワーク管理の問題です。
1、ネットワークと物理ネットワーク開放容器2、できるだけ小さく速く、より良い3、4変更、最小限のリスクポイント：ネットワークは、調査がビジネスユニットは、以下の点に焦点を当てたことがわかっ必要があります。
ネットワーク溶液容器は、形状、形成する3つの単離された方法を介して、プロトコルスタックのレベルに分けることができます
スタックレベル：二階が良く、伝統的なまたは仮想化シナリオの前にエンジンルーム内のより一般的な、理解されているが、ARP + MACブリッジングの学習に基づいており、その最大の欠陥が放送されています。放送の二階は、ノードの大きさを制限するため、3（純粋なルーティングおよび転送）、プロトコルスタックの三層は、一般にBGP、部屋全体の自律学習経路の状態に基づいています。その最大の利点は、限り、IPベースのネットワークなどと言うことであり、このネットワークが通過できることを、そのIPの浸透です。明らかに、そのサイズが非常に有利であり、かつ秩序の優れた拡張性を備えています。しかし、実際の展開プロセスでは、ほとんどの企業ネットワークを制御しているため。例えば、いくつかのBGP企業ネットワークは、開発者を使用するために、セキュリティ上の考慮事項に基づいていないか、企業ネットワーク自体は、この場合には、あなたがによって制限されていることを、BGPではありません。床プラス3階を積み重ね、それが解決するという利点があり問題のレイヤ2の規模を拡大するだけでなく、純粋な3-制限の問題を解決するため、特にシーンVPCの雲の下で、VPCは、ノード間のレイヤ3転送機能を利用することができます。
フォームを使用して：
これは、実際の導入環境に関連しています。下敷き、オーバーレイ：フォームを2つに分割されています。
下敷き：より良い制御可能なネットワークシナリオでは、我々は一般的にアンダーレイを使用しています。そのような理解があれば、ネットワーク全体の制御として、ネットワークコンテナを直接に通過させることができる、これはアンダーレイである、それはベアメタルまたは仮想マシンを下回っているかどうか、人気ができます。
オーバーレイ：シーンのクラウドでオーバーレイより一般的。管轄のIPまたはMAC VPCの範囲内に存在しないとき、ここでオーバーレイネットワークVPCは、制御され、VPCはこのIP / MACの横断を許可しません。これが起こるとき、私たちは、オーバーレイモードを使用して行うことができます。
オーバーレイネットワークの物理的なネットワーク仮想化、リソースプーリングは、クラウドネットワークの統合の鍵となります。ネットワークコンピューティングコンポーネントを統合するための簡単このように、オーバーレイネットワークとSDN、コントローラとしてSDNオーバレイネットワーク制御プレーンコントローラと一緒に使用される技術は、クラウド・プラットフォーム・サービス・ネットワークへの移行のために理想的です。
絶縁方式：
：分離は、通常、VLANの方法とVXLAN 2種類に分かれている
VLAN：エンジンルーム内で使用さVLANものが、実際に問題があります。これは、テナントの総数が限られています。我々はすべて知っているように、VLANは多くの制限があります。
VXLAN：VXLANは今分離の主流の方法です。そのサイズのために大きいが優れている、それは良い方法を通じてIPに基づいています。
分離の形と方法を介して、プロトコルレベルから、我々は、いくつかの一般的なネットワークコンポーネント（キャラコ、contiv、フランネル、Openshift kubernetes SDN、 カスタムルーティング）も用いて、ネットワーククラウドVPCネットワークシナリオの伝統的な部屋で分析を行うこと前にそれらの間の関係を表現する図ライン。
まず、伝統的なまたはクラウドベースのネットワークコンピュータルームVPCのネットワークかどうか、私たちは、オーバーレイプログラムは一般的なもので見ることができ、それはセックスを通じて良いを持っているので、雲のシーンでそれのいくつかの詳細は、使用することができます。
図では、赤の伝統的な部屋のネットワークへの実線は、焦点がここで説明します。下敷き+ 3層プログラムは、伝統的な部屋のネットワーク非常に人気のプログラムであり、そしてそれは非常に印象的なパフォーマンス、アプリケーションのシナリオは比較的高い方です。
緑の破線ネットワークのVPC点群は、アンダーレイを使用することができる3層ネットワークVPCシーンの雲、制限されます+。使用制限の名前は、意味を使用することができなく、すべてのベンダーがそれぞれ異なるクラウドベンダーが自分自身を守るためにネットワークを定義するので、あなたが、使用できるようになります。VPCのAzure自体がIPの範囲で、それを制御することが許可されていないので、例えば、キャリコ、行うのは簡単AWSでのBGPが、Azureの中のようなプログラムは、許可されていません。
VPCネットワークの黄色実線ポイントクラウド、クラウド・シーンの二、三の層における共通のオーバーレイ+。ここでオーバーレイがVPCのネットワークを制御し、制御がより便利になります。
以下に示すように当然のことながら、雲のいくつかの問題は、VPCのシナリオです。
次いで、約マルチテナントの問題との間のネットワークの分離が言いました
メカニズムからバージョン1.3ネットワークポリシーを導入K8Sは、PODを介してネットワークポリシーとのインバウンドおよびアウトバウンドのアクセスポリシーを実装することができます。
ポッドは、ネットワークポリシーは、従来の識別タグによって塗布し、伝統的なネットワークセグメントをシミュレートするためにタグを使用してもよいし、特定のフロントポッド「セグメント」タブの後端部により同定することができます。ポリシー制御これらのセグメント間のトラフィック、さらには外部ソースからのトラフィックを制御します。しかし、すべてではない、そのようなフランネルなどのバックエンドネットワークのサポート戦略、の。今では多くのメーカーがそれらを表示しない、多くの新しいソリューションがありますが、この分野の研究を強化します。
国境管理イングレスのクラスタがある
イングレスのみkubernetesバージョン1.2、サービスの形でサービスを提供するために、コンテナアプリケーションのデフォルトに見えたが、唯一のクラスタ内のサービスに作用され、イングレスはサービスにさらされることにより、クラスタ外のクライアントに提供することができますサービス。
比較を行うには、次の一般的な進入コントローラー、次の表
我々はnginxのを見るが、性能や機能面のためだけでなく、コミュニティ活動の面で優れている、また、より実用的です。
二つは、ストレージkubernetes
最初はステートレスのサービスを管理するために使用K8Sを、しかしより多くのアプリケーションとして非常に重要な機能となっているストレージ・リソースを管理するためにK8Sプラットフォームに移行しました。
：Kubernetesは、主に次の側面で使用するために保存されている
基本的な読み取り、暗号鍵管理のサービスプロファイルを、保存状態やサービス、データアクセスなど、さまざまなサービスやアプリケーション間でデータを共有します。示すように、一般的に、いくつかのシナリオは、あります。
KuberneteはKubernetesに一貫した哲学に従うことを宣言（宣言）アーキテクチャの設計に格納されています。一方、ストレージプラットフォームの様々な互換性を可能な限りために、Kubernetesは、インツリーのプラグインの形でユーザを満たすために、異なるストレージシステムをドッキングするために彼らのビジネスに基づいて、これらのプラグインを使用することができるコンテナストレージサービスを提供する必要があります。互換性のあるユーザーFlexVolumeとCSIのカスタムプラグイン。ドッカーボリュームと比較すると、ストレージより機能豊富なと多様なサポート。
：メモリカードKubernete解決
。1、木のプラグインで：あまりにもカップリング、緊密に統合されたコードK8Sを格納
FlexVolume、2：メモリカードは、ホスト、ホスト必要性のroot権限に搭載されている
3、CSI仕様：保存するコードを完全に（バージョン1.10以上、0.2.0バージョンを使用してアタッチCSIを使用して）デカップリングK8S 
CSI仕様を大幅に開発のための良好な見通しと、プラグイン、メンテナンスおよび統合の開発を容易にします。
Kubernetes二つのストレージリソース管理：
PersistentVolume（PVと記す）：管理者によって追加の説明を格納するには、ストレージタイプ、メモリサイズとアクセスモードを含むグローバルリソースです。ポッドがPVには影響を与えません破壊するために使用されている場合、そのライフサイクルは、例えば、ポッドとは無関係です。
PersistentVolumeClaim（略称PVC）：名前空間は、PVの説明のためのリソース要求です。要求情報を格納することはサイズ、アクセスモードを含んでいます。
PVが使用可能なストレージリソースとみなすことができ、PVCは、ストレージリソースの必要性である、PVCは、自動的にポッドの使用を特徴とする、適切なPVポッドにバインドします。PVとPVCとの関係を図に示したライフサイクルに従います。
PVモード静的および動的、静的PVモード管理NFS、FC、ISCSI、動的PVモード管理glusterfs、燃えがら、セファロRBDは、vSphere 、ScaleIO、AWS、アズールなど。静的およびPVを作成および管理するには、管理者を必要とし、自動的にPVCを生成し、結合するためにPVシステムによる動的。
次は、ミラーの生産にkubernetes下の画像管理を追加する簡単なことではありませんミラーに異なるアプリケーションの多くの異なるバージョンを持っています管理がより重要な側面です。
マルチテナント著作権管理ミラーリング：
1を、別のテナントが互いにミラーから隔離されなければならない
ミラー異なるテナントは読み取りと書き込み、読み取り専用、アップロードなど、ダウンロードの権限に異なるアクセス許可を持っている、2
ミラーイメージライブラリーがクエリを提供し、3、更新、および削除など
对于跨地域多数据中心的镜像管理，镜像库的远程复制管理需要注意：
1、在多数据中心或跨地域多站点的环境下，为了提高多地区镜像的下载效率，至少需要两级镜像库的设置：总镜像库和子镜像库
2、镜像库之间的准实时增量同步
三、 Kubernetes集群管理
在生产系统中，kubernetes多集群的管理主要涉及：
1、服务运维
2、集中配置
3、扩容升级
4、资源配额
首先说说多集群的调度管理
1、Kubernetes中的调度策略可以大致分为两种，一种是全局的调度策略，另一种是运行时调度策略
2、NODE的隔离与恢复；NODE的扩容；Pod动态扩容和缩放
3、亲和性可以实现就近部署，增强网络能力实现通信上的就近路由，减少网络的损耗。反亲和性主要是出于高可靠性考虑，尽量分散实例。
4、 微服务依赖，定义启动顺序
5、跨部门应用不混部
6、api网关以及GPU节点应用独占
多集群管理中的应用弹性伸缩管理：
1、手工扩缩容：预先知道业务量的变化情况
2、基于CPU使用率的自动扩缩容：v1.1版引入控制器HPA，POD必须设置CPU资源使用率请求
3、基于自定义业务指标的自动扩缩容：v1.7版对HPA重新设计，增加了组件，被称为HPA v2
在实际应用中，HPA还有很多不完善的地方，很多厂商都用自己的监控体系来实现对业务指标的监控并实现自动扩容
Kubernetes多集群的调优：
主要有三个难点：
第一是如何分配资源，当用户选择多集群部署后，系统根据每个集群的资源用量，决定每个集群分配的容器数量，并且保证每个集群至少有一个容器。集群自动伸缩时，也会按照此比例创建和回收容器。
第二是故障迁移，集群控制器主要是为了解决多集群的自动伸缩和集群故障时的容器迁移，控制器定时检测集群的多个节点，如果多次失败后将触发集群容器迁移的操作，保障服务可靠运行。
第三是网络和存储的互连，由于跨机房的网络需要互连，我们采用vxlan的网络方案实现，存储也是通过专线互连。容器的镜像仓库采用Harbor，多集群之间设置同步策略，并且在每个集群都设置各自的域名解析，分别解析到不同的镜像仓库。
接下来说说K8S集群的Master节点高可用实现，我们知道Kubernetes集群的核心是其master node，但目前默认情况下master node只有一个，一旦master node出现问题，Kubernetes集群将陷入“瘫痪”，对集群的管理、Pod的调度等均将无法实施。所以后面出现了一主多从的架构，包括master node、etcd等都可设计高可用的架构。
还有了解下Federation 集群联邦架构
在云计算环境中，服务的作用距离范围从近到远一般可以有：同主机（Host，Node）、跨主机同可用区（Available Zone）、跨可用区同地区（Region）、跨地区同服务商（Cloud Service Provider）、跨云平台。K8s的设计定位是单一集群在同一个地域内，因为同一个地区的网络性能才能满足K8s的调度和计算存储连接要求。而集群联邦（Federation）就是为提供跨Region跨服务商K8s集群服务而设计的，实现业务高可用。
Federation 在1.3版引入，集群联邦federation/v1beta1 API扩展基于DNS服务发现的功能。利用DNS，让POD可以跨集群、透明的解析服务。
1.6版支持级联删除联邦资源,1.8版宣称支持5000节点集群，集群联邦V2
目前存在的问题：
1、网络带宽和成本的增加
2、削弱了多集群之间的隔离性
3、成熟度不足，在生产中还没有正式的应用
四、kubernetes的监控与运维
对于一个监控系统而言，常见的监控维度包括：资源监控和应用监控。资源监控是指节点、应用的资源使用情况，在容器场景中就延伸为节点的资源利用率、集群的资源利用率、Pod的资源利用率等。应用监控指的是应用内部指标的监控，例如我们会将应用在线人数进行实时统计，并通过端口进行暴露来实现应用业务级别的监控与告警。那么在Kubernetes中，监控对象会细化为哪些实体呢？
系统组件
kubernetes集群中内置的组件，包括apiserver、controller-manager、etcd等等。
静态资源实体
主要指节点的资源状态、内核事件等等
动态资源实体
主要指Kubernetes中抽象工作负载的实体，例如Deployment、DaemonSet、Pod等等。
自定义应用
主要指需要应用内部需要定制化的监控数据以及监控指标。
不同容器云监控方案的对比：
关于Prometheus监控：
主要注意两点：
查询api的封装
配置文件的下发
有了prometheus这个强大的监控开源系统之后，我们所需要投入的工作就是查询api的封装和配置文件的下发。查询api的封装没什么好说的，无非就是前端调用我们自己的server，我们的server呢通过http协议去调用prometheus的api接口查询到原始数据，然后进行组装，最后返回给前端。 配置文件的话包含三部分吧，警报的定义，alertmanager的配置，以及prometheus的配置，这里也不好展开讲，有兴趣的可以去官网看看。当然也可以使用Prometheus+Grafana来搭建监控系统，这样可视化会更丰富些，展现也比较快。
运维的思考---开发与运维的一体化
运维的思考---高可用问题
• Ocp平台:
1、负载均衡Router高可用集群: 2个节点
2、EFK高可用集群: 3个ES节点+n个F节点
3、镜像仓库高可用集群: 2个镜像仓库
• 微服务架构:
1、注册中心高可用集群(Eureka): 3个
2、配置中心高可用集群: 3个
3、网关高可用集群: 2个
4、关键微服务均是高可用集群
运维的思考---高并发问题
• Ocp平台:
1、对后端微服务(Pod)配置弹性扩容, K8的弹性伸缩扩容以及Docker容器的秒级启动可以支撑用户量的持续增长;
2、提前预留20%的资源, 当高并发情况发生时, 可以紧急扩充资源。
• 微服务架构:
- 调大关键链路微服务的熔断线程数: 提升主要业务的并发响应能力。
- 对非关键链路微服务通过熔断限流进行降级处理甚至关闭非关键链路的微服务。
- ヒューズメカニズム：並行性の高いシナリオの場合の耐障害性を高めるためのカスケード障害を防止するために、コンテナをクラウド、およびアバランシェ効果マイクロサービス、システムの可用性を向上させます。
•ミドルウェア：
1、クラスタのほかには、コールドスタンバイクラスタの事前の増加を使用されています。
切迫高同時実行シナリオは、緊急レベルを拡張することができる2、。
圧力測定とパフォーマンスの最適化は時間が限られている、があり、それについて話をするためにここに起動しません。
最後に、道はクラウドコンテナ要約する
大企業が事業の安定性と継続性の比較的高い要求を持っているので、その容器の進化パスは、複雑なアプリケーションに簡単なアプリケーションから、コアビジネスへの端から操作可能でなければなりません。1.運用レベルを、ビジネスに特有の、最初のWebフロントエンドでのコンテナの移行を検討し、バックエンドのビジネス最後に移動。L
2.技術的なレベル：ネイティブドッカーは、現在サービス検出、ロードバランシング、コンテナのライフサイクル管理、インター血管ネットワーク、ストレージ、および他の側面に提供するために、多くの欠陥、オープンソースソリューションおよび多くのサードパーティメーカーの商用バージョンが残っている、それぞれにハードの機能は、競合します。かかわらず、ユーザーの製品選択、信頼性、二つの重要な要因は慎重に検討する必要があるの柔軟性。
3.アカウントに費用対効果を取っ：コンテナおよび将来の給付の費用を支払うのコストのバランスを考慮します。
4.コンテナのパフォーマンスを向上させるためにシステムをチューニングすることで、ほとんどではないかもしれない、コンテナの既存のハードウェアの負荷容量は万能薬ではない、同時操作のためのいくつかのより高いスループット要件がベアメタル上で直接実行を検討良い選択。
図5は、継続的に更新され、常に自分自身継続的な学習、プラットフォームの欠如を確認するために、変化を受け入れる、継続的に反復より良い製品を思い出させます。
生産の練習では、唯一の千マイルの未来を制御するために、エコシステム・ベースの構築製品やコンテナのクラウドプラットフォームを改善し続けるための基盤を強化！