[51CTO.com原稿] 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階を積み重ね、それが解決するという利点があり純粋な物語の問題の規模が、また、特にVPC VPCは、ノード間のレイヤ3フォワーディング機能を利用することができ、シーンの雲の下で、純粋な3-制限の問題を解決します。だから、今あなたが見ることができるKubernetesネットワークソリューションの実際の展開は、物語も3以上を追加します。
フォームを使用して：
これは、実際の導入環境に関連しています。下敷き、オーバーレイ：フォームを2つに分割されています。
下敷きは：制御良いのネットワークシナリオでは、一般的にアンダーレイを使用します。そのような理解があれば、ネットワーク全体（仮想+物理）制御として、それはベアメタルまたは仮想マシンを下回っているかどうか、人気ができる、ネットワーク全体がアンダーレイである容器に直接通すことができます。
オーバーレイ：シーンのクラウドでオーバーレイより一般的。管轄のIPまたはMAC VPCの範囲内に存在しないとき、ここでオーバーレイネットワークVPCは、制御され、VPCはこのIP / MACの横断を許可しません。これが起こるとき、私たちは、オーバーレイモードを使用して行うことができます。
オーバーレイネットワークの物理的なネットワーク仮想化、リソースプーリングは、クラウドネットワークの統合の鍵となります。オーバーレイネットワークとSDNと一緒に使用される技術は、このようにコントローラとしてSDNオーバレイネットワークの制御プレーン・コントローラ、ネットワーク・コンピューティング・コンポーネントの統合を行うことが容易では、クラウド・プラットフォーム・サービス・ネットワークへの移行のために理想的です。
絶縁方式：
分離は、通常、VLANの方法とVXLAN二つの方法に分けられます。
VLAN：VLANエンジンルーム内で使用されているものが、実際には問題があります。これは、テナントの総数が限られています。我々はすべて知っているように、VLANは多くの制限があります。
VXLAN：VXLANは今分離の主流の方法です。そのサイズのために大きいが優れている、それは良い方法を通じてIPに基づいています。
分離の形と方法を介して、プロトコルスタックレベルから、我々は、と、ネットワーククラウドVPCネットワークシナリオの伝統的な部屋で分析を行うためにいくつかの一般的なネットワークコンポーネント（カリコ、contiv、フランネル、Openshift SDN、カスタムルーティング）Kubernetes配線図は、前に彼らの関係を表現します。
首先无论是传统机房网络还是云化 VPC 网络，我们可以看到 Overlay 方案是通用的，它在云化场景里可能用的更多一些，因为它有很好的穿越性。
在上图中，红线实线指向传统机房网络，这里重点说明下。Underlay + 三层的方案，是传统机房网络非常流行的方案，同时它的性能非常可观，场景应用偏多。Underlay+二层+三层的方案，在云化 VPC 场景（特别是公有云）也是比较主流的一个方案，借助 VPC 的自定义路由完成转发。
绿色虚线指向云化VPC网络， Underlay+三层网络在云化 VPC 场景下，也是可以受限使用。受限使用顾名思义，可以使用但不是每个供应商都让你用，因为每一个云厂商对他自己网络保护的定义不一样。比如像 Calico 方案，它的 BGP 在 AWS 中就容易做，但在 Azure 中就不允许，因为 Azure 的 VPC 本身是不允许不受它管控范围的 IP 通过。
黄色实线指向云化VPC网络，Overlay+二层或三层在云化场景中比较常见。Overlay 下面是受控的 VPC 网络，管控会比较方便。
当然云化VPC场景下也存在一些问题，如下图所示。
多租户之间的网络隔离问题
K8s从1.3版引入网络策略机制，通过网络策略可实现POD之间的入站和出站访问策略。
网络策略可应用于通过常用标签标识的pod组，然后使用标签来模拟传统的分段网络，可以通过特定的“段”标签来标识前端和后端pod。策略控制这些段之间的流量，甚至控制来自外部源的流量。但并非所有的网络后端都支持策略，比如 flannel。现在很多厂商在这方面加强了研究，也有很多新的解决方案，就不一一列举了。
集群边界Ingress的管理
Ingress 是在Kubernetes 1.2版本才出现的，容器应用默认以Service的形式提供服务，但Service仅作用于集群内部，通过Ingress将Service暴露出去才能为集群外的客户端提供服务。
下面对常见的Ingress Controller做一个对比，见下表：
二、Kubernetes的存储
K8s最初用于管理无状态的服务，但随着越来越多的应用迁移到K8s平台，管理存储资源成为一个非常重要的功能。
Kubernetes中对于存储的使用主要集中在以下几个方面：
服务的基本配置文件读取、密码密钥管理等；服务的存储状态、数据存取等；不同服务或应用程序间共享数据。大致有以下几个场景：
Kubernete存储在设计的时候遵循着Kubernetes的一贯哲学，即声明式（Declarative）架构。同时为了尽可能多地兼容各种存储平台，Kubernetes以in-tree plugin的形式来对接不同的存储系统，满足用户可以根据自己业务的需要使用这些插件给容器提供存储服务。同时兼容用户使用FlexVolume和CSI定制化插件。相比较于Docker Volume，支持的存储功能更加丰富和多样。
Kubernete存储插件解析：
1、in-tree plugin：存储代码与K8s紧密集成，耦合性太强
2、FlexVolume：存储插件安装在宿主机上，需要宿主机的root权限
3、CSI规范：将存储代码与K8s完全解耦（1.10版本及以上，使用CSI attacher使用0.2.0版本）
csi规范极大地方便了插件的开发、维护和集成，具有很好的发展前景。
Kubernetes使用两种资源管理存储：
PersistentVolume（简称PV）：由管理员添加的一个存储的描述，是一个全局资源，包含存储的类型，存储的大小和访问模式等。它的生命周期独立于Pod，例如当使用它的Pod销毁时对PV没有影响。
PersistentVolumeClaim（简称PVC）：是Namespace里的资源，描述对PV的一个请求。请求信息包含存储大小，访问模式等。
PV可以看作可用的存储资源，PVC则是对存储资源的需求，PVC会根据Pod的要求去自动绑定合适的PV给Pod使用。PV和PVC的相互关系遵循下图所示的生命周期。
PV模式有静态和动态，静态PV模式管理NFS、FC、ISCSI，动态PV模式管理glusterfs、Cinder、Ceph RBD、Vsphere、ScaleIO、AWS、Azure等。静态的需要管理员创建和管理PV，而动态的则由系统自动生成PV并绑定PVC。
下面再简单补充下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的封装
- 配置文件的下发
运维的思考---开发与运维的一体化
运维的思考---高可用问题
- 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、对非关键链路微服务通过熔断限流进行降级处理甚至关闭非关键链路的微服务。
3、熔断机制：提升容器云高并发场景下的容错能力，防止故障级联以及微服务的雪崩效应，提升系统的可用性。
- 中间件:
図1は、クラスタに加えて、コールドスタンバイクラスタの事前の増加を使用しています。
切迫高同時実行シナリオは、緊急レベルを拡張することができる2、。
クラウドコンテナの概要に最後に、道
1、運用レベル：理由は、ビジネスの安定性と継続性の大企業は比較的高い需要を持っているので、容器の進化パスは、あなたができるすべての最初の、ビジネスに特有の複雑なアプリケーションへの単純なアプリケーションから、コアビジネスへのエッジからの操作でなければなりませんWebフロントエンドでのコンテナの移行を検討し、バックエンドのビジネス最後に移動。
2は、技術的なレベル：ネイティブドッカーは現在、サービス発見、ロードバランシング、コンテナのライフサイクル管理、インター血管ネットワーク、ストレージ、および他の態様では、まだ多くの欠陥、オープンソースソリューションと独特を提供するために、多くのサードパーティメーカーの商用バージョンがあります、競争するのは難しいです。かかわらず、ユーザーの製品選択、信頼性、二つの重要な要因は慎重に検討する必要があるの柔軟性。
3、アカウントの費用対効果を考慮：コンテナおよび将来の給付の費用を支払うのコストのバランスを考慮。
4、ほとんどではないかもしれない容器移送システムを最適化することによりパフォーマンスを向上させるために、コンテナの既存のハードウェア負荷容量は万能薬ではない、同時操作のためのいくつかのより高いスループット要件がベアメタルで直接実行検討良い選択。
図5は、継続的に更新され、常に自分自身継続的な学習、プラットフォームの欠如を確認するために、変化を受け入れる、継続的に反復より良い製品を思い出させます。
生産の練習では、唯一の千マイルの未来を制御するために、エコシステム・ベースの構築製品やコンテナのクラウドプラットフォームを改善し続けるための基盤を強化！
[51CTOオリジナルの写本、サイトが51CTO.comのためのオリジナルの著者とソースを明記してください再現しました]