部署Dotnet Core应用到Kubernetes（一）

最近闲了点，写个大活：部署Dotnet应用到K8s。

 

写在前边的话

一直想完成这个主题。但这个主题实在太大了，各类拖延症的小宇宙不时爆发一下，结果就拖到了如今。

 

这个主题，会是一个系列。在这个系列中，我会讨论将应用部署到K8s时须要的各个内容和知识，以及各类刨过的坑。

为了不这个系列被扩得过大，我不深刻讨论K8s的技术，也不去解释如何创建K8s集群之类的问题。这个主题会侧重在开发人员方面，侧重于如何开发适合K8s的应用，以及在K8s上部署。

另外，这个主题也不会关注Docker。在我看来，Docker是一个附加技术，而不是必要内容。

 

在项目中，是否须要使用K8s，算是一个问题。从各个方面来看，不少中大型的项目都倾向于往这个方面去作，但咱们必须清楚，使用K8s增长了项目的复杂度。若是构建的是一个独立的应用程序，那用K8s实在没有必要。而即使是一个大的系统，其实也没有必要从开头就加入K8s。

本主题中的内容大多来自我本身部署Dotnet Core到K8s集群的经验。若是有任何问题，能够在评论中告诉我。

    为防止非受权转发，这儿给出本文的原文连接：http://www.javashuo.com/article/p-dtchseay-nu.html

K8s（Kubernetes）面向开发的组件

前边说了，这个主题咱们仅关注部署应用程序相关的部分，而不讨论K8s的所有。

面向开发，面向部署，咱们须要了解下面几个概念：

• 节点（Node）
• Pod
• 部署（Deployment）
• 服务（Service）
• 入口（Ingress）

这几个概念，是整个内容的基础。

1. 节点（Node）

在K8s中，Node对应的是虚拟机或物理硬件，是K8s实际运行容器的地方。

通常来讲，有两类节点:

• 主节点（Master），用来运行全部的控制级（Control-plane）服务。主节点也能够运行应用程序，但通常来讲，主节点只处理控制管理服务，不运行工做负载。
• 其它节点，用来运行真正的应用程序。一个节点能够运行多个应用程序或应用程序容器。

一个典型的K8s集群会像下面图中的样子：

固然，在实际应用中，看K8s的规模。必要时，也能够作成单机，主节点运行控制服务的同时，也运行应用程序。

在集群中，节点越多，能够运行的应用或容器就越多，节点宕机时的容错能力也就越大。

2. Pod

K8s中最小的管理单元，不是一个个独立的容器，而是Pod。

要在K8s中运行应用程序，须要将其打包到一个容器（一般是Docker容器）中，并让K8s运行它。Pod是可让K8s运行的最小单元。它包含一个或多个容器。当一个Pod被建立或销毁时，它里面的全部容器也会被建立或销毁。

 

在网上，不少的文章都介绍说：若是有一个依赖于数据库的应用，那应该把应用容器和数据库容器部署在同一个Pod中，以便同步建立或销毁。

以个人经验来讲，这个说法很不许确，并且容易形成对K8s应用的误解。在K8s的实际应用中，只包含单个容器的Pod会更经常使用，也更好用。就好像“支付API”或“订单API”这样的，每一个API都有不一样的扩展需求、部署要求和迭代速度，所以单独设置Pod给它们是很是合理的。一样，数据库容器也应该部署在独立的Pod中，由于它与应用/服务/API会有不一样的生命周期。

还有一个比较经常使用的是SideCar模式，就是在一个Pod下的主容器旁边部署“SIdeCar“容器，用来充当代理，为主应用程序进行身份证认处理，或服务发现，以及服务通信，甚至能充当应用性能监控的接收器来用。

一个典型的节点下的Pod是下面的样子：

再重申一下：一个节点下面能够有多个Pod。一个Pod在K8s中会做为一个总体单元进行调度。一个Pod可能包含一个容器，也可能包含多个容器。容器用于部署应用或API。

3. 部署

在个人概念中，K8s主要作了两件事：

• 管理容器的生存期
• 管理容器之间的通信

K8s的部署，主要完成的是第一件事，即管理容器的生存周期。因此，部署能够看作是定义K8s如何部署Pod以及若是管理Pod的一组规则。

比方，咱们可能这样定义一个部署：

1. Pod包含支付API应用Docker映像的一个实例；
2. 咱们要运行这个Pod的三个副本
3. 保证每一个容器至少有200Mb的可用内存，并限制它最多不超过400Mb；
4. 当咱们部署Pod新版本时，采用滚动更新策略

定义完后，K8s就会严格执行这个规则。若是应用崩溃了，K8s会删除Pod并安排一个新的Pod，以保证规则规定的副本数量。若是Pod须要更多内存，K8s会选择一个运行容器较少的节点上运行它，或者结束并从新部署它。当应用更新一个新版本时，K8s会建立一个新的部署，来替换旧版本，并将运行转到新的版本。

固然，上面这个例子作了必定的简化。不过，基本上K8s的基本工做就是这么作的。

这里的关键就是：部署定义了规则，K8s在这个部署的整个生命周期中维护并保持这个规则。

4. 服务

前面说过，部署能够用来建立跨多个节点（Node）的Pod的多个副本。这其实就是K8s提升性能及提升可用性的主要原理。

服务是应用对外的部分，供其它API去调用。而在K8s内部，服务能够看做是Pod在集群内的负载均衡器。当咱们建立部署时，一般还会建立一个与该应用的Pod关联的服务。

在上面的例子中，当咱们建立部署时，也会建立一个“Payment API”的服务，供其它API调用。

而当其它Pod须要与这个支付API的Pod通信时，实际不会与支付API的一个Pod直接联系，而是将请求发给服务，而后由服务将请求传递给某一个Pod的实例。

这个过程参见下面的图：

服务与网络相关。所以，服务有多种不一样的网络模式。这里不详细说了，只拿一个经常使用的模式举个例子：

K8s将服务分配到一个DNS记录，并经过这个记录将请求从一个Pod转发到另外一个Pod。

假设咱们有一个支付服务，而咱们的购买服务须要调用这个服务。K8s不须要知道Pod的真实IP，咱们只须要分配一个DNS记录给服务：

payment-api.xxx.local

经过这个域名，购买服务能够调用支付服务，而不须要知道支付服务对应的Pod的真正IP。

这个工做方式与Dotnet体系彻底同样。经过这种方式，能够实现对资源的逻辑分组，这是题外话。

5. 入口

入口与服务很像，但有本质的不一样。

服务本质上是K8s集群内部的东西，用来实现Pod之间的内部调用。而入口将HTTP/HTTPS从集群外部路由到内部的服务，这样，外部应用，例如前端、APP或小程序就能够经过这个入口，调用内部服务来处理请求。

同时，入口也能够当成提供外部负载均衡，即跨多个节点平衡对给定服务的请求。

除此以外，入口也能够提供其它一些特性，例如主机名或基于路径的路由。一般，咱们能够为每一个应用或API配置一个入口。

还有，入口设置也能够用来作应用的反向代理。例如经过一个Nginx实例来配置入口。这都是能够的，并且这样的方式，可让API隐藏在反向代理以后，而不用直接暴露在外网。这个部分，在后面的文章，我会专门写。

总结一下

这篇文章是这个系列的一个引子。

当咱们在K8s中部署一个Dotnet Core的应用时，咱们须要配置Pod部署，添加服务来在K8s内部公开这些Pod，并添加一个入口来公开服务。

本系列的后续文章中，我会从开发的各个环节来解释如何使用这些组件来部署Dotnet Core应用到K8s。

敬请关注！！！

（未完待续）

 

---

 

微信公众号：老王Plus 扫描二维码，关注我的公众号，能够第一时间获得最新的我的文章和内容推送 本文版权归做者全部，转载请保留此声明和原文连接