kubernetes04-从容器到云原语

从容器到云原生的路由：

container-Kubernetes-微服务-云原生-服务网格-使用场景-开源。

为什么使用K8S

下图是K8s的架构图，展示了CNI、CRI、OCI等。在组件中，将Kubernetes与特定产品解耦，给用户最大程度的定制，让Kubernetes有机会成为真正的跨云云原生应用的操作系统。

云原生的核心目标

云已经可以为我们提供触手可及的稳定基础设施，但它已经成为业务中的一个难题。Kubernetes与其说是从原始容器中安排解决方案，不如说是解决应用云(即云原生应用)的问题。

包括微服务和FaaS/无服务器架构，都可以作为云原生应用的架构。

但截至2017年，Kubernetes的主要使用场景主要应用于应用开发测试环境、CI/CD、运行Web应用等领域。

此外，基于Kubernetes的PaaS平台和Serverless的搭建也处于疫情准备阶段，如下图Gartner的报告所示：

2017年，谷歌GKE、微软Azure ACS、亚马逊EKS(2018年推出)、VMware、Pivotal(后被VMware收购)、腾讯云、阿里巴巴云等主要公有云都提供了Kubernetes服务。

微服务

下图列出了微服务需要关注的主题。图片来自红帽开发者。

微服务在开发和部署上给我们带来了很大的灵活性和技术多样性，但也增加了服务调用、分布式系统管理、调试和服务治理的开销。

目前最成熟、最完整的微服务框架可以说属于Spring，而Spring也仅仅局限于Java语言开发，其架构本身与Kubernetes有很多重叠的部分。如何探索Kubernetes作为一个微服务架构平台，已经成为一个热门话题。

以微服务中最基本的Service注册发现功能为例，可分为客户端服务发现和服务器服务发现。Java应用中常见的方式是使用Eureka和Ribbon进行服务注册发现和负载均衡，属于客户端服务发现。但是在Kubernetes中，可以使用DNS、service和Ingress从网络层面直接实现，无需修改应用程序代码。

微服务中的2种服务发现方式

服务网格

Kubernetes中的应用会作为微服务运行，但是Kubernetes本身并没有提供微服务治理的解决方案，比如服务限流、保险丝、良好的灰度发布支持等等。

Service Mesh 可以用来做什么

流量管理：应用编程接口网关

可观察性：服务调用和性能分析

策略实施：控制服务访问策略

服务身份和安全：安全保护

Service Mesh 的特点

的专用基础设施层

轻量级高性能网络代理

在服务之间提供安全、快速和可靠的通信。

扩展kubernetes的应用负载均衡机制，实现灰度发布。

与应用程序完全分离，应用程序可以不敏感，加速应用程序的微服务和云原生转换。

都有哪些Service Mesh

使用服务网格可以有效地管理在Kubernetes中运行的服务。目前，开源和流行的服务网格是：

Linkerd:由最早提出服务网格的公司浮力开源。创始人来自推特。

特使：由Lyft开源，可以在Istio中使用Sidecar模式作为数据平面，也可以在此基础上构建自己的服务网格。

Istio:由谷歌、IBM和Lyft联合开发和开源。

Istio VS Linkerd

Linkerd和Istio是最早的开源Service Mesh，两者都支持Kubernetes。下面是它们之间的一些特性比较。

Feature

Istio

Linkerd

部署架构

特使/边车

daemmonsets

可用性

>复杂简单支持平台KubernetesKubernetes/Mesos/Istio/Local是否已有生产部署是是

Istio 的组件复杂，可以分别部署在 Kubernetes 集群中，但是作为核心路由组件 Envoy 是以 Sidecar 形式与应用运行在同一个 Pod 中的，所有进入该 Pod 中的流量都需要先经过 Envoy。

Linker 的部署十分简单，本身就是一个镜像，使用 Kubernetes 的 DaemonSet 方式在每个 node 节点上运行。

使用场景

GitOps

我们知道 Kubernetes 中的所有应用的部署都是基于YAML文件的，这实际上就是一种 Infrastructure as code，完全可以通过 Git 来管控基础设施和部署环境的变更。

大数据

Spark 现在已经非官方支持了基于 Kubernetes 的原生调度，其具有以下特点：

• Kubernetes 原生调度：与 yarn、mesos 同级
• 资源隔离，粒度更细：以 namespace 来划分用户
• 监控的变革：单次任务资源计量
• 日志的变革：pod 的日志收集

下图是在 Kubernetes 上运行三种调度方式的 spark 的单个节点的应用部分对比：

从上图中可以看到在 Kubernetes 上使用 YARN 调度、standalone 调度和 Kubernetes 原生调度的方式，每个 node 节点上的 Pod 内的 Spark Executor 分布，毫无疑问，使用 Kubernetes 原生调度的 Spark 任务才是最节省资源的。

开源

对于一个初次接触 Kubernetes 的人来说，看到这样一个庞大的架构选型时会望而生畏，但是 Kubernetes 的开源社区帮助了我们很多。