基于Kubernetes的企业级容器云落地，为企业传递IT转型和业务上云提供助力。

使用容器技术支撑微服务化的应用。

云计算 -- 是IT信息技术发展和服务模式创建的集中体现，是信息化发展的必然趋势。

应用部署；应用配置；应用的灰度发布更新策略；弹性扩缩容；

以Kubernetes + Docker为基础，搭建企业级容器云PaaS平台，支撑基于微服务架构开发的应用程序，实现对大规模容器集群的有效管理。

容器云PaaS 平台的建设是企业基础设施平台云化建设的基石。

集群DNS域名服务管理

DNS 服务完成从服务名到ClusterIP 的解析工作。

（1）查看kubelet 启动参数上指定的 --cluster-dns

[root@centos-110 ~]# ps -ef | grep cluster-dns

root 1550 1 8 10:47 ? 00:01:12 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --pod-manifest-path=/etc/kubernetes/manifests --allow-privileged=true --network-plugin=cni --cni-conf-dir=/etc/cni/net.d --cni-bin-dir=/opt/cni/bin --cluster-dns=10.96.0.10 --cluster-domain=cluster.local --authorization-mode=Webhook --client-ca-file=/etc/kubernetes/pki/ca.crt --cadvisor-port=0 --cgroup-driver=cgroupfs --rotate-certificates=true --cert-dir=/var/lib/kubelet/pki --node-ip=192.168.56.110

root 9782 3026 0 11:01 pts/0 00:00:00 grep --color=auto cluster-dns

（2）查看每个 Pod 内部，为其设置了 DNS 服务器

kubectl get pods -o wide

#进入pod对应的容器内部

[root@centos-110 ~]# kubectl exec -it httpd-65f9bdfb75-q47dx bash

root@httpd-65f9bdfb75-q47dx:/usr/local/apache2# cat /etc/resolv.conf

nameserver 10.96.0.10

search default.svc.cluster.local svc.cluster.local cluster.local yiguo.com

options ndots:5

root@httpd-65f9bdfb75-q47dx:/usr/local/apache2#

这就为容器环境设置了集群范围内的DNS 服务器 10.96.0.10，由其完成服务名与服务 ClusterIP 的解析。

微服务体系架构

在微服务体系架构中，一个应用是由一组在逻辑上紧密关联而又可以独立部署的微服务（Service）组成的，而微服务（Service）是对多实例容器的逻辑抽象，它定义了一个服务的访问入口地址，通过这个地址访问其后端由一组Pod 副本组成的应用实例。

Pod 由一个或多个容器组成，同一个组内的容器共享存储卷和网络栈。容器Container 则包括应用程序及运行时所需的依赖库，将其打包在一个环境中运行。

在Kubernetes 集群内部，各个微服务通过都无须将端口号映射到宿主机上，仅需要对集群外部提供服务的应用进行设置。

单体应用 -- 所有模块都运行在一个 Tomcat 容器中，位于一个进程里。

好处：

技术门槛低、编程工作量少、开发简单快速、调试方便、环境容易搭建、容易发布部署及升级。

缺点：

（1）单体应用系统比较膨胀和臃肿；

（2）难以水平扩展、多机部署的方式来提升系统的吞吐量；

对于新开发的应用，建议直接基于微服务架构，进行容器化的应用开发。

Spring Cloud 的整体架构

Spring Cloud = Netflix OSS + Spring Boot

Spring Cloud中的服务网关（Zuul）：主要功能是服务路由，可以将其理解为中心化的Service Proxy，Client 在想要调用某个Service 时，会将请求发送给 Zuul，再由Zuul 代理转发请求到后端对应的Service 地址，在Service 响应后再原路返回，最终抵达客户端。

Kubernetes

在Spring Cloud 之后成功的微服务架构，基本都与容器技术挂钩了，其中最成功、影响最大的当属Kubernetes 平台了。与之相似的还有docker Swarm。

Kubernetes 里的服务路由与服务负载均衡是通过“代理”来实现的，既是由位于每个Node 节点上的 kube-proxy 来完成的，而非客户端的负载均衡机制。

Service Mesh 其实采用了代理模式的思想，来解决代码入侵及重复编码的问题。

Kubernetes 微服务架构

Kubernetes 平台提供了当前容器领域中最好的微服务架构解决方案。Kubernetes 微服务架构方案里最突出也最独特的一个设计是 Cluster IP。

Kubernetes 为每个微服务都定义了一个固定不变的IP 地址，这就是 Cluster IP，并进一步引入传统的DNS 机制，将每个服务的服务名作为DNS 域名与其Cluster IP捆绑。

Cluster IP 在Kubernetes 里是如何实现的呢？

答案是通过Linux 防火墙规则，它属于NAT 技术。

从服务的名字（DNS）查询对应的Cluster IP 的过程，就属于服务发现，这是通过Kubernetes 平台上的DNS 组件（服务）来实现的；而将Cluster IP 与服务对应的Pod地址的映射关系注册到平台上的过程，就属于服务注册，相关的服务注册信息就保存在etcd 数据库中，由API Server 提供访问接口。

Service Mesh & Istio

Istio 来自希腊语，英文意思是“ Sail”，中文是“启航”之意。Istio 的底层实现依赖Envoy，并且直接定位于Kubernetes 平台。

Istio 与希腊语为“舵手”的Kubernetes结合在一起，意思就是“掌舵启航”。

Service Mesh - 是一个用于处理服务与服务之间通信（调用）的复杂的基础架构设施。

Service Mesh 通常是一组轻量级的网络代理程序，这些网络代理程序就部署在用户的应用程序旁边（Sidecar），而应用代码感知不到它们的存在。

Istio 将会成为市场主流，因为Istio 开源、免费，而且还有巨头们的大力支持，小清新的Conduit 则会在中小企业中赢得一定的口碑和市场份额。

Service Mesh 原理

从ServiceA到ServiceB的访问流量，要先后经过ServiceA的Sidecar层、ServiceA 所在机器的TCP/IP网络栈，之后通过网络到达ServiceB所在机器的TCP/IP网络栈、ServiceB的Sidecar 层，之后才能抵达ServiceB 服务层。

Service Mesh产品更适合部署在容器环境中。

Sidecar 非常类似于传统网络中的“智能路由器”。

依托Sidecar，Service Mesh 提供了包括服务路由、负载均衡、流量控制、熔断机制、服务安全及服务监控等高级功能在内的、采用全新思路的无侵入的一整套微服务架构解决方案。

Pilot（Istio-Manager）

Pilot 提供给Envoy 的主要是配置相关的接口，如服务发现、负载均衡池、路由表动态更新。

Envoy API 负责和Envoy 通信，主要用来发送服务发现信息、服务路由表、流量控制规则给Envoy 实例。

Mixer

用来实现服务与周边基础设施的隔离问题；

Mixer 采用了插件机制，每个插件都被称为适配器，比如日志插件、监控插件、配额插件、ACL插件等；

策略（Policy） - （1）服务访问限速（Rate Limit）；（2）黑白名单（Blacklist、Whitelist）

Citadel（Istio-Auth）

负责解决微服务架构中的安全问题。

Citadel 首先会创建 Kubernetes Secret 来保存Service的私钥和证书，然后通过 Kubernetes Volume将Secret中的私钥和证书映射到容器里。

这样，两个Service 就可以在彼此对应的代理，即Envoy之间，建立一个加密的TLS通道来实现数据传输的安全了。

Envoy 与对应的Service 之间，还是普通的TCP 传输，因为它们是本地 Socket通信，并不通过网络。

Service Mesh 产品提供的基本功能：

服务发现、服务路由；负载均衡、服务熔断；安全的TLS服务间通信；DevOps 开发和运维的统一

DevOps = Development + Operations

强调对应用进行快速、小规模、可迭代的开发和部署，以更好地应对和满足客户的需求；

将开发和运维职能作为一个合作的整体来看待；

日志统一采集

日志管理主要包括采集、存储及展示分析功能部分，开源的日志汇总方案以ELK (Elasticsearch, Logstash, Kibana)的应用最为广泛。

Fluentd 因其更易用、资源消耗更少、性能更高、数据处理更可靠、高效，受到了更多企业的青睐，成为了Logstash 的可替代方案，Elasticsearch、Fluentd、Kibana软件栈也被简称为 EFK。

Fluentd -- 开源数据采集工具，提供统一的日志层；

可以在每个集群节点Node 部署一个Fluentd 容器应用实例，以采集该节点上的主机系统日志、容器日志、Kubernetes组件日志、容器应用的数据等，然后将其发送至 Elasticsearch 进行存储。

Elasticsearch -- 开源的全文本查询和分析引擎；

Kibana -- 提供基于Elasticsearch 存储数据的可视化界面和支持快速分析任务。

监控管理

目前，比较流行的开源方案有 Heapster + InfluxDB + Grafana 和 Prometheus 两种。

（1）Heapster 是Google 专门面向Kubernetes 开发的性能数据集中监控系统；

cAdvisor 是Google 开发的容器监控组件，部署在每一个Kubernetes Node节点上，负责收集所在主机上所有容器的性能数据；

Heapster 负责汇总各Node 节点上 cAdvisor 的数据，并可以保存多种后端存储系统，如InfluxDB，Kafka等；

InfluxDB 用Go 语言编写的分布式时序数据库；

Grafana 页面展示工具，提供多种分析插件；

（2）Prometheus 监控平台

etcd 分布式键值存储系统

高可靠的分布式键值存储系统，支持Leader 选举、分布式锁及键值改变监控等功能；

etcd 在Kubernetes 中作为重要的后端存储组件，用于 存储Kubernetes 集群自身的服务发现、集群状态与配置信息。

为了使 etcd 服务更可靠地运行，建议部署 N （N>= 3 的奇数）个节点的etcd 集群对外提供高可用服务。