基于K8S的容器云平台如何部署微服务？

K8S是第一个将“一切以服务为中心，一切围绕服务运转”作为指导思想的创新型产品，它的功能和架构设计自始至终都遵循了这一指导思想，构建在K8S上的系统不仅可以独立运行在物理机、虚拟机集群或者企业私有云上，也可以被托管在公有云中。

微服务架构的核心是将一个巨大的单体应用拆分为很多小的互相连接的微服务，一个微服务背后可能有多个实例副本在支撑。单体应用微服务化以后，服务之间必然会有依赖关系，在发布时，若每个服务都单独启动会非常痛苦，简单地说包括一些登录服务、支付服务，若想一次全部启动，此时必不可少要用到编排的动作。

K8S完美地解决了调度，负载均衡，集群管理、有状态数据的管理等微服务面临的问题，成为企业微服务容器化的首选解决方案。使用K8S就是在全面拥抱微服务架构。

在社区不久前的线上活动交流中，围绕金融行业基于K8S的容器云的微服务解决方案、金融行业微服务架构设计、容器云整体设计架构等方面的问题进行了充分的讨论，得到了多位社区专家的支持。大家针对K8S容器云和微服务结合相关的问题，体现出了高度的参与热情。在此，对大家关注的问题以及针对这些问题各位专家的观点总结如下：

一、K8S容器云部署实践篇

Q1:现阶段容器云部署框架是什么？

A1:

• 在DMZ和内网分别部署彼此独立的2套Openshift，分别为内网和DMZ区两个网段，两套环境彼此隔离。

• DMZ区的Openshift部署对外发布的应用，负责处理外网的访问

• 内网的Openshift部署针对内网的应用，仅负责处理内网的访问

-权限管理

对于企业级的应用平台来说，会有来自企业内外不同角色的用户，所以灵活的、细粒度的、可扩展的权限管理是必不可少的。OCP从设计初期就考虑到企业级用户的需求，所以在平台内部集成了标准化的认证服务器，并且定义了详细的权限策略和角色。

1. 认证：

OCP平台的用户是基于对OCP API的调用权限来定义的，由于OCP所有的操作都是基于API的，也就说用户可以是一个开发人员或者管理员，可以和OCP进行交互。OCP内置了一个基于OAuth的通用身份认证规范的服务器。这个OAuth服务器可以通过多种不同类型的认证源对用户进行认证。

2. 鉴权：

权策略决定了一个用户是否具有对某个对象的操作权限。管理员可以设置不同规则和角色，可以对用户或者用户组赋予一定的角色，角色包含了一系列的操作规则。

除了传统的认证和鉴权功能，OCP还提供了针对pod的细粒度权限控SCC（security context constraints），可以限制pod具备何种类型的权限，比如容器是否可以运行在特权模式下、是否可以挂在宿主机的目录、是否可以使用宿主机的端口、是否可以以root用户运行等。

-多租户管理

租户是指多组不同的应用或者用户同时运行在一个基础资源池之上，实现软件、硬件资源的共享，为了安全需求，平台需要提供资源隔离的能力。

在OCP中，project是一个进行租户隔离的概念，它来源于kubernetes的namespace，并对其进行了功能的扩展。利用Project，OCP平台从多个层面提供了多租户的支持。

1. 权限控制。通过OCP平台细粒度的权限管理机制，管理员可以对不同的用户和组设置不同project的权限，不同用户登录以后只能操作和管理特定的project

2. 网络隔离。OCP平台使用openvswitch来管理内部的容器网络，提供两种类型的网络模式，一种是集群范围内互通的平面网络，另一种是project级别隔离的网络。每个project都有一个虚拟网络ID（VNID），不同VNID的流量被openvswitch自动隔离。所以不同项目之间的服务在网络层不能互通。

3. Router隔离。Router是OCP平台一个重要软件资源，它提供了外部请求导入OCP集群内部的能力。OCP提供了Router分组的功能，不同的project可以使用独立的Router，不互相干扰，这样就避免了由于某些应用流量过大时对其他应用造成干扰。

物理资源池隔离。在多租户的环境中，为了提高资源的利用率一般情况下物理资源池是共享的，但是有些用户也会提供独占资源池的需求。针对这种类型的需求，OCP平台利用nodeSelector的功能可以将基础设施资源池划分给特定的project独享，实现从物理层面的隔离。

-日志和监控

（1）传统应用日志

有别于当前流行的容器应用，的传统应用同时一个中间件会运行多个应用，且应用通过log4j等机制保存在文件中方便查看和排错。因为容器运行的特性，对于这部分的日志我们需要持久化到外置存储中。

日志的分类如下：

• 中间件日志

• dump文件

• 应用日志

日志保存在计算节点上挂载的NFS存储。为了规范和方便查找。日志将会按OCP平台中的namespace建立目录，进行划分。

（2）新应用日志

应对分布式环境下日志分散的解决办法是收集日志，将其集中到一个地方。收集到的海量日志需要经过结构化处理，进而交给需要的人员分析，挖掘日志的价值信息。同时不同的人员对日志的需求是不一样的，运营人员关注访问日志，运维人员关注系统日志，开发人员关注应用日志。这样就需要有一种足够开放、灵活的方法让所有关心日志的人在日志收集过程中对其定义、分割、过滤、索引、查询。

OpenShift使用EFK来实现日志管理平台。该管理平台具备以下能力：

¡ö 日志采集，将日志集中在一起

¡ö 索引日志内容，快速返回查询结果

¡ö 具有伸缩性，在各个环节都能够扩容

强大的图形查询工具、报表产出工具

EFK是Elasticsearch(以下简写为ES)+ Fluentd+Kibana的简称。ES负责数据的存储和索引，Fluentd负责数据的调整、过滤、传输，Kibana负责数据的展示。

Fluentd无论在性能上，还是在功能上都表现突出，尤其在收集容器日志领域更是独树一帜，成为众多PAAS平台日志收集的标准方案。

（3）监控

PaaS平台的监控包括系统监控、容器监控等。监控流程由信息收集、信息汇总和信息展示等几个部分组成。

在Openshift中默认使用kubenetes的监控信息收集机制，在每个节点上部署cadvisor的代理，负责收集容器级别的监控信息。然后将所有信息汇总到heapster，heapster后台的数据持久化平台是Cassandra。最后由hawkular从Cassandra获取信息进行统一的展示。

1. 组件说明

Openshift的监控组件，用于对pod运行状态的CPU、内存、网络进行实时监控，和Kubernetes使用的监控技术栈一样，包括三个部分：

HEAPSTER

用于监控数据的采集

https://github.com/kubernetes/heapster

HAWKULAR METRICS

属于开源监控解决方案Hawkular，基于JSON格式管理、展示监控数据

http://www.hawkular.org/

CASSANDRA

Apache Cassandra是一个开源的分布式数据库，专门用于处理大数据量业务

http://cassandra.apache.org/

-DMZ区计算节点

在DMZ区应用部署遵循以下策略：

• 已有应用迁移至容器云平台时的资源申请按现有配置设置，申请的服务器将仅供该使用

• 如果需要横向扩展，也仅在已分配的计算节点上，如果资源不足，应用项目组可再申请新的计算资源

• 本期项目中，XXX部署在DMZ区平台上，使用2个计算节点；XXX部署在内网平台上，使用2个计算节点

• 在实施时需要为相应的计算节点标记标签，使应用部署时部署到指定的计算节点上。

例如在DMZ网段对XXX应用所使用的2台计算节点打上标签

在部署XXX应用使，nodeSelector需要指明使用的节点的标签为XXX=XXX。

-传统应用访问策略

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!