는 Kubernetes는 자동화 된 배포, 대규모 확장 성 응용 프로그램 컨테이너 관리를 지원하는 구글의 오픈 소스 컨테이너 오케스트레이션 엔진이다. 지금 빠른 클라우드 네이티브 기술의 상승과 함께는 Kubernetes 사실 표준 응용 프로그램 컨테이너 플랫폼, 점점 생산에 사용되는 모든 연령층의 점점 더 많은 기업도 적용되고있다.
2016의 시작 부분에서 우리의 컨테이너 플랫폼은 탐험 사전 연구, 시스템 구축 및 플랫폼 바닥 세 단계를 거쳐왔다. 
여기에 네트워크, 스토리지, 클러스터 관리 및 모니터링과 운영 및 유지 보수 측면의는 Kubernetes에서 우리의 다음 도보를 구축하기위한 컨테이너 클라우드 플랫폼의 역사를 공유하기 위해, 우리는 당신에게 약간의 생각과 영감을 줄 수 있도록 노력하겠습니다.
A는, 네트워크는 Kubernetes
지금까지 컨테이너 네트워크 개발을, 평면의 패턴 것이었다. 실제로 부두 노동자의 CNM과 구글, CoreOS을 말한다 것이다 허치, Kuberenetes는 CNI을 이끌었다. 먼저 그들은 당신이 옥양목과 예 하오, 하오을 기본 플란넬을 사용하는 인터페이스의 무리가 그들의 연구 개발의 관점에서, 네트워크 사양 및 네트워크 시스템입니다, CNM하지 CNI 네트워크 명확하게, 그들은 CNM을 걱정하지 않는다 CNI의 관심사는 네트워크 관리의 문제이다.
1, 네트워크와 물리적 네트워크 개방 용기 2, 가능한 한 적게는 더 빨리 더 나은 3, 4 변화, 최소한의 위험 포인트 : 네트워크 조사 사업 단위는 다음과 같은 점에 초점을 맞추고 있음을 발견해야합니다.
네트워크 솔루션 용기 형상, 형태 3 개 격리 된 방식을 통해, 상기 프로토콜 스택 레벨로 분할 될 수있다
스택 레벨 : 2 층을 더 잘 이해하고, 전통 또는 가상 시나리오 전에 엔진 룸에서 일반적 학습 브리징 ARP + MAC 기반으로, 그것의 가장 큰 결함은 방송입니다. 방송의 2 층 노드의 크기 제한 때문에 3 개의 (순수 라우팅 및 전달), 프로토콜 스택의 세 가지 층은 일반적으로 BGP, 전체 공간의 자율적 인 학습 경로 상태를 기반으로합니다. 그것의 가장 큰 장점은 그만큼이 네트워크를 통해 갈 수있는 IP 기반 네트워크로, 그 말을하는 것입니다, 자사의 IP 침투입니다. 분명히, 그 크기는 매우 유리하고, 순서의 좋은 확장 성을 가지고있다. 그러나 실제 배포 과정에서 대부분의 기업 네트워크 제어하기 때문이다. 스택 바닥 플러스 3 층, 그것은 장점을 가지고하는 것이 해결하기 위해, 예를 들어, 일부 BGP 기업 네트워크는 BGP가이 경우에 당신은에 의해 제한됩니다되지 개발자 또는 기업 네트워크 자체를 사용하는 보안 고려 사항에 기반으로하지 않습니다 문제 2 계층의 규모를 확장뿐만 아니라 노드에서 레이어 3 포워딩 기능의 순수한 세 제한, 특히 장면 VPC의 구름 아래, VPC가 취할 수있는 장점이 문제를 해결한다.
양식을 통해 :
이 실제 전개 환경에 관한 것이다. 언더 레이, 오버레이 : 양식을 통해 두 가지로 나누어진다.
언더 : 더 나은 제어 네트워크 시나리오에서, 우리는 일반적으로 언더를 사용합니다. 이러한 이해는 한 전체 네트워크 제어로 네트워크 용기가 직접적으로 통과 할 수있는 베어 메탈 (bare metal) 또는 가상 머신, 이하인지, 인기가 있고,이 언더이다.
오버레이 : 현장의 클라우드 오버레이보다 일반적인. 소관 IP 또는 MAC VPC의 범위 내에 없을 때 여기서 오버레이 네트워크 VPC가 제어되고, VPC이 IP / MAC 교차를 허용하지 않을 것이다. 이 경우, 우리는 오버레이 모드를 사용 할 수 있습니다.
오버레이 네트워크를 물리적 네트워크 가상화, 자원 풀링, 클라우드 네트워크 통합의 열쇠입니다. 네트워크 컴퓨팅 구성 요소를 통합하기 쉽게 이러한 방식으로 오버레이 네트워크와 SDN, 제어기와 SDN 오버레이 네트워크 제어 플레인 제어 장치와 함께 사용하는 기술은 클라우드 플랫폼 서비스 네트워크로의 전환에 적합하다.
절연 방식 :
: 분리는 일반적으로 VLAN 방법 및 VXLAN 이가지으로 나누어 져
VLAN : 엔진 룸에 사용되는 VLAN 것들 있지만, 사실 문제가있는 것입니다. 그것은 세입자의 총 수에 제한이 있습니다. 우리 모두가 알다시피, VLAN은 제한을 가지고 있습니다.
VXLAN : VXLAN은 이제 분리의 주류 방법입니다. 그 크기 때문에 더 큰 더 나은이며, 그것은 더 나은 방법을 통해 IP를 기반으로합니다.
형태 및 격리의 방식을 통해 프로토콜 수준에서 우리는 몇 가지 일반적인 네트워크 구성 요소 (옥양목, contiv, 플란넬, Openshift는 Kubernetes SDN, 심지어으로, 네트워크 및 클라우드 VPC 네트워크 시나리오의 전통적인 방에서 분석을 수행하는 사용자 정의 라우팅) 도 라인은 이전에 그들 사이의 관계를 표현한다. 
첫째, 기존 또는 클라우드 기반 네트워크 컴퓨터 실 VPC 네트워크 여부, 우리는 섹스를 통해 좋은 때문에 오버레이 프로그램이 사용할 수있는 클라우드 장면에서, 그것의 좀 더 일반적인 수 있습니다 볼 수 있습니다.
그림에서 빨간색 전통적인 방 네트워크에 실선은, 초점은 여기에 설명. 언더 + 3 계층 프로그램은 기존의 방 네트워크 매우 인기있는 프로그램이며, 그것은 매우 인상적인 성능, 애플리케이션 시나리오 상대적으로 높은 편이다.
녹색 점선 네트워크의 VPC 포인트 구름, 언더 사용할 수있는 세 가지 계층 네트워크 VPC 현장의 구름에 제한됩니다 +. 제한된 사용하는 이름은 의미 사용할 수 있지만 모든 업체는 각각의 서로 다른 클라우드 공급 업체가 자신을 보호하기 위해 네트워크를 정의하기 때문에, 사용하게됩니다. VPC 푸른 자체가 IP 범위에 의해 그것을 제어 할 수 없습니다 때문에 예를 들어, 옥양목, 할 쉽게 AWS에서의 BGP하지만, 하늘빛처럼 프로그램은 허용되지 않습니다.
클라우드 장면의 두 개 또는 세 개의 층에서 VPC 네트워크 오버레이 + 공통의 노란색 실선 포인트 클라우드. 여기에 오버레이 VPC 네트워크를 제어하는 제어가 더 편리 할 것입니다.
아래 그림과 같이 물론, VPC 시나리오에서 구름의 몇 가지 문제점이있다. 
대한 멀티 테넌트 (multi-tenant) 문제 사이 그러자 네트워크 격리
K8S는 메커니즘에서 버전 1.3 네트워크 정책을 도입 POD를 통해 네트워크 정책 사이의 인바운드 및 아웃 바운드 액세스 정책을 구현 될 수있다.
포드 설정된 네트워크 정책은 종래의 ID 태그에 의해 도포 한 후 기존의 네트워크 세그먼트를 시뮬레이션 태그를 사용할 수 있고, 특정의 전면 및 포드 "세그먼트"탭의 후방 단부에 의해 식별 될 수있다. 심지어 정책 제어 이러한 세그먼트 사이의 트래픽 및 외부 소스로부터의 트래픽을 제어 할 수 있습니다. 하지만 같은 플란넬 같은 백 엔드 네트워크 지원 전략의 모든. 이제 많은 제조 업체를 나열하지, 많은 새로운 솔루션이있다,이 분야의 연구를 강화한다.
국경 관리 침투의 클러스터가됩니다 
침투 단지는 Kubernetes 버전 1.2, 서비스의 형태로 서비스를 제공하기 위해 컨테이너 응용 프로그램의 기본에 출연 있지만 클러스터 내의 서비스에 작용되어, 침투는 서비스에 노출하여 클러스터 외부의 클라이언트에게 제공 할 수있는 서비스를 제공합니다.
다음과 같은 일반적인 침투 컨트롤러 비교하려면 다음 표 
우리는 Nginx에 볼이 성능과 기능면에 대한뿐만 아니라, 커뮤니티 활동의 측면에서 더 나은, 또한 더 실용적입니다.
두 스토리지는 Kubernetes
초기 상태 비 저장 서비스를 관리하는 데 사용 K8S을하지만, 점점 더 많은 애플리케이션과 같은 매우 중요한 특징이있다 스토리지 자원을 관리 할 수 K8S 플랫폼으로 마이그레이션.
는 Kubernetes는 주로 다음과 같은 측면에 사용하기 위해 저장됩니다
기본적인 읽기, 암호 키 관리 서비스 프로필, 보관 상태 및 서비스, 데이터 액세스 등, 다른 서비스 또는 응용 프로그램 간의 데이터를 공유 할 수 있습니다. 그림과 같이 일반적으로 몇 가지 시나리오가있다 :
Kubernete이는 Kubernetes 일관된 철학을 따를 것을 선언 (선언) 아키텍처의 설계에 저장됩니다. 한편, 스토리지 플랫폼의 다양한 호환 가능한 한 많은 순서에서 트리 플러그인의 형태로는 Kubernetes 그들의 사업은 컨테이너 스토리지 서비스를 제공하기 위해 필요에 따라 이러한 플러그인을 사용할 수있는 사용자를 충족하기 위해 다른 스토리지 시스템을 고정합니다. 지원되는 사용자 FlexVolume 및 CSI 사용자 정의 플러그인. 부두 노동자의 볼륨에 비해, 저장 더 풍부한 기능 및 다양한 지원.
: 메모리 카드 Kubernete 해결
트리 - 플러그인에서 1 :.도 긴밀하게 통합 된 코드 K8S를 저장하는 커플 링
(2), FlexVolume가 : 메모리 카드가 호스트에 장착, 호스트 필요 루트 권한
3, CSI 사양 : 저장 코드 K8S 완전히합니다 (0.2.0 버전을 이용하여 부가 부 CSI를 사용하여, 버전 1.10 이상) 분리 
개발을위한 좋은 전망과 크게 플러그인, 유지 보수 및 통합의 개발을 촉진 CSI 사양.
는 Kubernetes 개의 스토리지 자원 관리 :
PersistentVolume (PV 라 함)의 관리자에 의해 추가의 설명을 저장하는, 저장 타입, 메모리 크기 및 액세스 모드를 포함하는 글로벌 자원이다. 포드는 PV에 영향을주지 않습니다 파괴하는 데 사용하면 그 수명주기는 예를 들어, 포드의 독립적이다.
PersistentVolumeClaim (약어 PVC) : 네임 스페이스는 PV에 대한 설명은 자원 요청에 있습니다. 요청 정보를 저장하면 크기, 액세스 모드가 포함되어 있습니다.
태양 광 발전이 가능한 스토리지 자원으로 간주 될 수있다, PVC는 스토리지 자원에 대한 요구는, PVC가 자동으로 포드 사용 항에있어서 적절한 PV 포드에 바인딩됩니다. PV와 PVC의 관계는도 라이프 사이클을 따른다.
PV 모드 정적 및 동적, 정적 PV 모드 관리 NFS, FC, iSCSI는, 동적 PV 모드 관리 글루 스터 FS (GlusterFS), 쇠 찌끼, Ceph RBD,은 vSphere , ScaleIO, AWS, 푸른 등등. 자동으로 생성하고 PVC를 바인딩 할 정적 작성하고 PV를 관리 할 수있는 관리자를 필요로하며, 태양 광 발전 시스템에 의해 동적.
다음은 거울에 서로 다른 응용 프로그램의 여러 버전이있을 것이다 거울의 생산에는 Kubernetes에서 이미지 관리를 추가하는 것이 더 쉬울 수 없습니다 관리가 더 중요한 측면이다. 
미러링 멀티 테넌트 (multi-tenant) 권한 관리 :
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. 운영 수준을 비즈니스에 고유 한, 최초의 백엔드 비즈니스를 마지막으로 이동, 웹 프런트 엔드에서 컨테이너 마이그레이션을 고려한다. L
2. 기술적 인 수준 : 기본 도커는 현재 서비스 검색,로드 밸런싱, 컨테이너 라이프 사이클 관리, 간 혈관 네트워크, 스토리지 등의 측면에서 제공하는 많은 결함, 오픈 소스 솔루션 많은 타사 제조업체의 상용 버전은 각과, 거기에 여전히 하드 기능, 경쟁한다. 에 관계없이 사용자가 제품 선택, 신뢰성, 유연성이 개 중요한 요소가 필요의주의 깊게 고려되어야합니다.
3. 계정에 비용 효율성을 복용 : 용기와 미래의 혜택의 비용을 지불하는 비용 사이의 균형을 고려.
4. 대부분을하지 않을 수 있습니다 컨테이너의 성능을 향상시키기 위해 시스템을 조정하여, 동시 작업에 대한 몇 가지 더 높은 처리량 요구 사항, 베어 메탈에서 직접 실행 컨테이너의 기존 하드웨어 부하 용량은 만병 통치약이 아니다 고려 좋은 선택.
5, 지속적으로 업데이트, 항상 플랫폼의 부족, 지속적으로 반복 더 나은 제품을 볼 수 있도록, 변화를 수용, 자신에게 지속적인 학습을 생각 나게.
생산 실제로, 만 천 마일의 미래를 제어하기 위해, 에코 시스템 기반 건축 자재 및 컨테이너 클라우드 플랫폼을 지속적으로 개선 할 수있는 기반을 강화!