K8S? 微服务？

自从入职了新公司以后，再加现在学习Python，时间不是太充裕，恰巧今天整好在家，外面下着小雨，嘀嗒嘀嗒的，视乎更适合写文章；今年还是非常有幸的参与了公司的整体架构变迁，从传统的tomcat环境成功迁移到了私有云，且从运行情况来看还是蛮稳定的！

今日看到了此篇文章，写的还是值得花时间听听业界大牛是如何看待“K8S”和“微服务”！我们目前运行的架构体系还是和作者微服务的思想蛮类似的1

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

微服务架构的核心是将一个巨大的单体应用拆分为很多小的互相连接的微服务，一个微服务背后可能有多个实例副本在支撑。

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

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

权限管理

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

1. 认证：

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

2. 鉴权：

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

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

多租户管理

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

日志和监控

（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

用于监控数据的采集

Q2: 容器平台建设过程中，如何利用好已有云平台，从技术、架构等层次，需要注意哪些事项？

容器跑在物理机上，还是跑在云平台虚机上，这是个值得讨论的话题。

对于公有云而言，毫无疑问，肯定是跑在云主机上的。那么，有的客户在上线容器微服务之前，已经有了自己的私有云平台，那么这个时候是购买一堆物理机来另起炉灶，还是基于已有云平台快速部署，这就值得斟酌了。

其实也没什么好纠结的，无非就是一个问题:性能！

跑在物理机上，性能肯定是最佳的，但是你真的需要所谓的性能吗？测过没有，是否真的只有物理机才能满足你的容器微服务应用，根据我的经验，以金融行业来说，大部分用户物理机资源常年处于低负荷状态！以性能为借口，恶意拉动GDP，就是耍流氓啊！

如果你决定跑在已有云平台上，那么，你要考虑的问题如下：

1、充分利用LaC（Infrastructure as Code）实现自动化编排部署，这是云平台最大的优势（比如openstack中的heat），也是裸机集群最大的劣势；

2、网络性能。在IaaS层上面跑容器，网络是个需要认真考虑的问题，calico最佳，但是基础设施改动大，不是所有客户都能接收，flannel+hostgw是个不做选择，原则就是尽量防止二次封装叠加，致使网络性能下降过多。

3、架构上具备后续扩展性，这里指的不仅仅是scale-out扩展，更是功能上的向后扩展，比如随着微服务不多扩大，网络负载不断增加，后续你可能会打算使用service mesh，那么前期就靠考虑清楚兼容性问题

4、最后，也是最朴素的一点，简单、好用、高可用原则，不要为了高大上而“高大上”，搞得自己完全hold不住，得不偿失，一个好的平台选型就是成功的80%

除此之外

1.需要看已有云平台提供了哪些功能或接口可以供 容器平台使用，比如CMDB、比如权限管理、比如应用或者中间件配置等

2.应用 以 容器方式和传统方式 的部署方式和流程 看是否可以抽象统一化，不管是升级回滚扩容等，在运维层面行为一致就能利用已有平台但是自己要实现底层与编排系统的对接

Q3: K8S集群如何实现集群安全？双向认证or简单认证？

Kubernets系统提供了三种认证方式：CA认证、Token认证和Base认证。安全功能是一把双刃剑，它保护系统不被攻击，但是也带来额外的性能损耗。集群内的各组件访问API Server时，由于它们与API Server同时处于同一局域网内，所以建议用非安全的方式访问API Server，效率更高。

-双向认证配置

双向认证方式是最为严格和安全的集群安全配置方式，主要配置流程如下：

1）生成根证书、API Server服务端证书、服务端私钥、各个组件所用的客户端证书和客户端私钥。

2）修改Kubernetts各个服务进程的启动参数，启用双向认证模式。

-简单认证配置

除了双向认证方式，Kubernets也提供了基于Token和HTTP Base的简单认证方式。通信方仍然采用HTTPS，但不使用数字证书。

采用基于Token和HTTP Base的简单认证方式时，API Server对外暴露HTTPS端口，客户端提供Token或用户名、密码来完成认证过程。

不仅仅是API层面，还有每个节点kubelet和应用运行时的安全，可以看下这里

https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/

K8S的认证相对来说还是个比较复杂的过程，如下这篇文章，详细介绍了K8S中的认证及其原理：

https://www.kubernetes.org.cn/4061.html

Q4: K8S在容器云上的负载均衡策略和总体思想是什么？

高可用主要分为如下几个：

• 外部镜像仓库高可用

外部镜像仓库独立于OCP平台之外，用于存储平台构建过程中所使用的系统组件镜像。因为外部无法直接访问OCP平台的内部镜像仓库，所以由QA环境CD推送到生产环境的镜像也是先复制到外部镜像仓库，再由平台导入至内部镜像仓库。

为了保证外部镜像仓库的高可用， 使用了2台服务器，前端使用F5进行负载均衡，所有的请求均发至F5的虚拟地址，由F5进行转发。后端镜像仓库通过挂载NFS共享存储。

• master主控节点高可用

Master主控节点承担了集群的管理工作

• 计算节点（容器应用）高可用

计算节点高可用指计算节点上运行的容器应用的高可用。一个计算节点异常停机后，其上的容器将会被逐步迁移到其他节点上，从而保证了高可用。

同时可以通过标签的方式来管理计算节点，在不同的计算节点划分为不同的可用区或组。在部署应用时，使用节点选择器将应用部署至带有指定标签的目标计算节点上。为了保证高可用，标签组合的目标计算节点数要大于1。这样可以避免一台目标节点宕机后，调度器还能找到满足条件的计算节点进行容器部署。

• 应用高可用

基于软件（HAproxy）负载均衡服务，容器服务弹性伸缩时无需人工对负载均衡设备进行配置干预，即可保证容器化应用的持续、正常访问；可通过图形界面自定义负载均衡会话保持策略。

由于平台内部通过软件定义网络为每个应用容器分配了IP地址，而此地址是内网地址，因此外部客户无法直接访问到该地址，所以平台使用路由器转发外部的流量到集群内部具体的应用容器上，如果应用有多个容器实例，路由器也可实现负载均衡的功能。路由器会动态的检测平台的元数据仓库，当有新的应用部署或者应用实例发生变化时，路由器会自动根据变化更新路由信息，从而实现动态负载均衡的能力。

简单一点来说，就是内部服务的动态发现、负载均衡、高可用和外部访问的路由；

通过service，解耦动态变化的IP地址，POD可以随意关停，IP可以任意变，只要DNS正常，服务访问不受影响，但是这里面你的随时保证有个可用的POD,这个时候你就得需要LB了，或者说LB干的就是这个事情。

内部服务之间访问通过service解决了，那么外部访问集群内服务，则通过router即是解决，外网访问要不要负载均衡，大规模高并发情况下是肯定的，当然，外部负载均衡通常需要用户自己搞定了，F5或者开源的HAproxy都行！

说到最后，我其实本想着分享下我们整个公司从基础到应用再到架构的整体方案呢，既然这篇给了大家这么多思绪，我暂且不慌透漏给大家，后期补上！或者私信我，最后你会发现一切都是那么的和谐~