容器云平台定义

 从技术角度看，容器云平台是采用容器、容器编排、服务网格，无服务等技术构建的一种轻量化 PaaS 平台。容器云平台将传统云计算的 IaaS 层和 PaaS 层融合，为应用提供了开发、编排、发布、治理和运维等全生命周期管理（Application Lifecycle Management，ALM）的能力。对于应用运行依赖的数据库、中间件、微服务基础组件、大数据组件、人工智能组件以及其他第三方组件，容器云平台会负责这些组件的生命周期管理，并且以服务的方式以供应用使用。

容器云平台相比传统 PaaS 平台，容器技术和 Kubernetes 容器编排引擎为应用提供了 DevOps集成能力、持续发布策略、扩缩容、服务治理等能力，使得开发者更专注于业务逻辑的开发，充分利用容器云平台的能力，通过自动化缩短业务迭代上线周期、优化资源利用率、提高服务响应效率，从而可最大程度利用云服务和提升软件交付能力，进一步加速企业的数字化。

平台服务

平台即服务（Platform as a Service，PaaS ）给用户提供了特定的编程语言、库、服务以及开发工具来创建、开发应用程序并部署在相关的基础设施上。用户无需管理底层的基础设施，包括网络、服务器，操作系统或者存储。他们只需要，当然也只限于管理部署平台上的应用程序。PaaS 平台会提供服务给运行的应用程序，常见的服务有数据库、消息队列、缓存等。
总之，PaaS 提供软件部署平台，抽象掉了硬件和操作系统细节，可以无缝地扩展。开发者只需
要关注自己的应用（业务逻辑），而不需要关注底层。
 

Service Mesh
服务网格（Service Mesh）是一个致力于解决服务间通信的基础设施层，用于提供管理、观测、支持工作负载实例之间安全通信。服务网格通常以轻量级网络代理的形式实现，这些代理与应用程序代码部署在一起，但是对应用程序透明。服务网格通常由控制平面和数据平面两部分组成。数据平面运行在边车（Sidecar） 中，Sidecar 作为一个独立的容器和业务系统运行在同一个 Pod 里面，或者作为一个独立的进程和应用程序进程运行在同一个虚拟机上，其主要充当业务系统的网络流量的代理。传统 RPC 中的服务发现、限流、熔断、链路追踪等能力都会下沉到 Sidecar 中。Sidecar 为应用程序提供了一个透明的网络基础设施，让业务在低侵入或者零侵入的情况获得更健壮的网络通信能力。
具体来看，基础设施层是 Service Mesh 的定位，用于解决微服务基础设施标准化、配置化、服务化和产品化问题；服务间通信是 Service Mesh 技术面对的问题域，对微服务屏蔽通信的复杂度；请求的可靠传递是 Service Mesh 的目标；轻量级网络代理是 Service Mesh 的部署方式；对应用程序透明，对业务无侵入是 Service Mesh 的特色。
目前 Kubernetes 生态中主流的 Service Mesh 组件是 Istio。Istio 是 Google、IBM 和 Lyft 联合推出的开源微服务 Service Mesh 框架，以 Envoy 为基础，将 Envoy 作为默认的数据平面，提供强大的控制平面能力。
Envoy 内部可以分为数据平面、控制平面和管理平面 3 个部分，控制平面用于对流量路由和转发相关的策略与配置进行管理；控制平面通过标准 API 获取最新的流量配置信息；数据平面的流量转发就是基于控制平面下发的配置规则进行。
 

Serverless
Serverless（无服务器）是一种架构理念，其核心思想是将提供服务资源的基础设施抽象成各种服务，以 API 接口的方式供给用户按需调用。无服务器架构技术则将计算抽象得更加彻底，将应用架构堆栈中的各类资源的管理全部委托给平台，免去基础设施的运维，使用户能够聚焦高价值的业务领域。
Serverless 架构由两部分构成，分别是 FaaS （Funcation as s Service） 和 BaaS（Backend as a Service）。所谓的无服务器计算，并不是不需要服务器等资源的支持，而是开发者不再需要过多顾虑关于服务器底层资源的问题，可更专注于业务逻辑的开发。
目前 Kubernetes 生态中主流的 Serverless 组件是 Knative。knative 是谷歌开源的 Serverless架构方案，旨在提供一套简单易用的 Serverless 方案，把 Serverless 标准化。目前参与的公司主要是 Google、Pivotal、IBM、Red Hat，2018 年 7 月 24 日才刚刚对外发布，当前还处于快速发展的阶段。
Knative 是建立在 Kubernetes 和 Istio 平台之上的，使用 kubernetes 提供的容器管理能力（deployment、replicaset、和 pods 等），以及Istio提供的网络管理功能（ingress、LB、dynamic route 等）。
Knative 把整个系统分成了三个部分：
Build：构建系统，把用户定义的函数和应用 build 成容器镜像
Serving：服务系统，用来配置应用的路由、升级策略、自动扩缩容等功能
Eventing：事件系统，用来自动完成事件的绑定和触发
 

日志

在容器化时代，容器应用的日志管理和传统应用存在很大的区别，为了顺应容器化应用，Docker 和 Kubernetes 为例，均能提供较为完善的日志解决方案。在 Docker 中日志分为两大类：Docker 引擎日志和容器日志。其中，Docker 引擎日志就是Docker 运行时的日志，即 dockerd 守护进程的日志，在支持 Systemd 的系统中可以通过journal -u docker 查看日志。Docker 管理所有容器传到 stdout 和 stderr 的日志，通过 docker logs 命令查看容器日志都是读取容器传到 stdout 和 stderr 的日志。

在 Kubernetes 中日志也主要有两大类：应用 Pod 日志和 Kuberntes 集群组件日志。其中，应用 Pod 的日志管理是基于 Docker 引擎的，Kubernetes 并不管理日志的轮转策略，日志的存储都是基于Docker的日志管理策略。Kuberntes集群组件日志分为两类：运行在容器中的Kubernetes scheduler 和 kube-proxy；未运行在容器中的 kubelet 和容器 runtime。
Kubernetes 本身并未提供集群日志收集方案，K8s 官方文档给了三种日志收集的建议方案：
Docker 是目前使用最广泛的容器之一，但它并不总是像物理硬件一样可见，因此对容器、运行系统和应用的状态的监控就显得很重要。主要对应用层，平台层和引擎层各组件/系统进行性能目前在 Kubernetes 集群内部收集日志有以下几种方案
1.常见的ELK（Elasticsearch、Logstash、Kibana）+ Filebeat。引入了各类 LibBeats（Package Beat、Top Beat、File Beat 等）运行在 App 应用的 Pod 中收集日志，转发给Logstash。此方案将手机端的 Logstash 替换为 beats，更灵活，消耗资源更少，扩展性更强。同时可配置 Logstash 和 Elasticsearch 集群用于支持大集群系统的运维日志数据监控和查询。
2.Kubernetes官方推荐的 EFK（ELasticsearch、Fluentd、Kibana）方案，此方案通DaemonSet 的方式在集群内部每个节点上运行一个 Fluent Pod 统一收集上层应用层的日志并反馈到Elasticsearch。