引言
你是否曾经面对过应用程序部署和管理的挑战？是否曾经想象过将容器化的应用程序无缝部署、自动扩展和高度可靠地管理？飞梭平台之前采用为docker方式，在应用的部署和管理方面存在一定的挑战，所以飞梭平台实践了K8s方式的部署。
一个好的应用服务首先是应该是高可用的，如单点故障、不能自动扩缩容等情形不可能是高可用的，在目前容器化部署下K8s是一个通行的解决方案。今天分享的内容对往期谈到的“祖传屎山代码”也有帮助。
今日分享
K8s的一些核心概念
应用在K8s中如何跑起来
开发中需要注意和思考的问题
业务上线初期，通常访问量较小，且大多数情况下只有单个节点在运行业务。随着业务发展，为提高服务性能并避免单点故障，需要将单体服务转变为集群。传统运维可以通过重复执行业务上线流程来实现这一目标，部署一个反向代理软件实现负载均衡。在此过程中，集群机器应尽可能使用相同的操作系统和环境。
而在Kubernetes（K8s）运维中，初始部署时已经搭建了K8s集群。单节点发生故障时，K8s会自动检测到并将该节点上的Pod状态更改为unknown。同时，K8s还会自动在其他机器上启动指定数量的副本Pod。整个故障迁移过程中，无需运维人员参与，用户也不会察觉到服务异常，从而避免业务中断。此外，对于瞬时暴增的流量情况，K8s可以通过自动水平扩展，来自动调整副本数量，非常适合于流量波动大、机器资源紧张、服务数量多的业务场景。
让我们先来看一个K8s官方架构图，图中这个K8s集群是由一个master和两个node组成。
和大部分的布式系统有些类似，master负责管理和协调集群中的工作；node节点中运行我们的应用；用户管理K8s集群是通过kubectl命令进行交互，master控制node是通过kubelet进行的。
图中“凸”出来的地方是分布式存储块一个独立的模块，存储默认是用etcd实现的。因为是模块化的设计，如有其他存储实现可灵活扩展支持。
根据架构图可以学习借鉴：只有APIServer与存储通信，安全、隔离存储实现。实际业务场景中，比如常用的缓存服务，一般使用Redis，如果抽象独立为缓存服务，实现层变更不影响使用者，对于使用者是统一的接口隔离具体实现。
API的设计。在K8s中API的设计是声明式的，我们一般用的可能是命令式的API，这两种各有优缺点，可根据实际的场景运用合适的方式。API也是一个面向对象的设计，在K8s里它的资源有多种，设计上是一个高内聚和低耦合的。其实高内聚低耦合是一个软件开发领域非常重要的概念，如果我们写代码能真正地践行这个高内聚低耦合思想，那写出来的代码一定不会差。
状态机。K8s里常有一些状态机，比如服务状态等，这些状态都是各自在某一个条件下会进行切换。它的控制逻辑只依赖于当前的状态，不需要再知道历史状态。这样对容错的处理更友好，例如服务宕机，集群恢复的时候它的处理会更好。
总结两个关键词：容错性和可扩展性。
K8s中的资源对象Namespace：命名空间，同大多数分布式系统里面的类似，资源隔离的作用。
Pod：K8s创建和管理的、最小的可部署的计算单元。Pod所创建的是特定于应用的“逻辑主机”，其中包含一个或多个应用容器，一般情况为一个容器。
Deployment(StatefulSet）：Deployment适合无状态的应用（随机的ID，Pod可互换），StatefulSet适合于有状态应用（唯一的ID，Pod不可互换）。
Service：是将运行在一个或一组Pod上的网络应用公开为网络服务的方法，集群内访问为ClusterIP方式，集群外访问一般为NodePort方式。
Volume：挂载，在K8s里边有很多种的挂载方式，如常用的hostPath（简单但不建议使用）和PVC（一个可伸缩的块存储层）。
ConfigMap（Sect）：ConfigMap用来将非机密性（Sect适合加密性数据）的数据保存到键值对中。可以将其用作环境变量、命令行参数或者存储卷中的配置文件。
Ingss：是对集群中服务的外部访问进行管理的API对象，典型的访问方式是HTTP。
应用如何在K8s中跑起来？第一步：基建先行
以上几种方式，在对应场景下选择适合的方式即可。
第二步：Yaml登场
工具：如果服务较多且之前使用的docker方式，可komposeconvert一键生成，之后再次基础上稍作修改即可“出锅”。手写：怕写错可以看着模板样例（可见官方文档），一般需要配置的东西也不多。
主要的资源对象配置部分为Deployment、Service、Configmap等。建议一个服务一个文件方便管理，注意kompose工具转换结果每个资源。
另外可以使用helm工具管理，来看一个官方Yaml案例：
apiVersion:apps/v1kind:Deploymentmetadata:name:nginx-deploymentlabels:app:nginxspec:plicas:selector:matchLabels:app:nginxtemplate:metadata:labels:app:nginxspec:containers:-name:nginximage:nginx:1.14.2ports:-containerPort:80---apiVersion:v1kind:Servicemetadata:name:nginx-servicespec:selector:app:nginxports:-protocol:TCPport:80targetPort:80
部署实践中需要