今天写完了任务的API，之后对于后端的要求是学习一下K8s，本篇文章的意义是对于自己学习过程的某些记录。正文开始。
文章地址：https://www.toocruel.net/kubernetes-ru-men-jian-ming-jiao-cheng/
Kubernetes 概述
K8s是一个底层资源和容器之间的一个抽象层。我自己的理解，这里指的是一个统一管理，统一布置的中间管控层。
K8s是Google开源的容器集群管理系统，在Docker技术的基础上，为容器化应用提供部署运行，资源调度，服务发现和动态伸缩等一系列完整功能。此处的资源调度和服务发现我不是很清楚什么意思，在下文的学习之中希望可以得到解答。
Kubernetes 特点有：
- 可移植：支持公有云，私有云，混合云
- 可扩展：模块化，热插拔，可组合
- 自愈：自动替换，自动重启，自动复制，自动扩展
Kubernetes 总览
下面是博客上面的简图：
我们之前的定义：Kubernetes是一个管理系统。从上面这张图可以看出，其本身的架构为主从分离架构。这个也很正常，Master节点负责对整个系统的调整和监控，而Node节点负责执行具体的任务。
K8s在整体架构的设计是非常优雅的，文章列举了三点作为具体介绍：
- 逻辑控制只依赖当前状态。
对于分布式系统而言，出现局部错误的频率非常高。只依赖当前状态的控制逻辑会很容易将一个暂时出现故障的系统恢复到正常状态。
- 组件的容错管理。
在一个分布式系统之中，出现局部和临时错误是大概率事件，错误可能来自于物理系统故障，外部系统故障或者是自身的代码错误。因此要对任何可能的错误进行容错处理。
- 自动恢复和鲁棒性。
K8s的设计之中，各个模块之间的耦合性都比较松散，比如ApiServer异常之后，也不会影响到集群业务的正常运转。
K8s将集群之中的所有任务抽象成资源，比如一个Deployment资源，一个Pod资源等等。用户面向的是一个一个资源，客户端只能通过操作这些资源来控制整个集群。这样的设计，将模块和模块之间做了很好的隔离，很容易的做到各个模块之间的对接和独立升级维护。
Kubernetes的基本概念
下面简单过一下Kubernetes的基本概念：
- Pod：K8s的基本运行单元
- ReplicaSet：Pod的集合
- Deployment：提供更新支持
- StatefulSets： 提供有状态支持
- Volume：数据卷
- Labels：标签，资源之间的关联一般通过这个实现
相关组件
Master相关组件
Master，主控节点，相当于整个集群的大脑。
Master 提供集群的管理控制中心，通常情况下，Master 会独立部署。
Master 主要组件有：
-
Kube-apiserver
kube-apiserver 用于暴露 Kubernetes API。任何的资源请求/调用都是通过Kube-apiserver 提供的接口进行。
-
Kube-controller-manager
运行管理控制器，是集群之中用于处理常规任务的后台线程。
-
Etcd
Etcd 是 Kubernetes 提供默认的存储系统，保存所有集群数据。 一般推荐，使用时要使为Etcd 数据提供备份计划。
-
scheduler
是kubernetes 的调度器，主要的任务是把定义的pod分配到集群的节点上。需要考虑资源与效率之间平衡优化的问题。
Node相关组件
Node，工作节点，用来从Master 接受任务并执行，并且适当的调整自己的状态或者删除过期的负载。
Node 的主要组件包括：
-
Kubelet
Kubelet 是工作节点主要的程序，其会监视已分配给节点的Pod，具体功能包括：
- 创建Pod 所需的数据卷
- 创建Pod 所需的网络
- 下载Pod 所需的Secrets
- 启动Pod 之中运行的容器
- 定期执行容器健康检查
- 上报节点状态
-
Kube-proxy
Kube-proxy 通过主机上维护网络规则并执行连接转发来实现Kubernetes 服务抽象
-
Docker/Rkt
Docker/Rkt 用于运行容器
Kubernetes 安装部署
部署目标为一个Master 节点，一个 Node 节点，Etcd 装在 Master 节点上。
但是生产环境之中，建议是将Etcd 单独部署，并启用 Https
Kubernetes 小经验
最后一些我们在 K8s 引入和使用的过程中遇到的问题和积累的一些经验，在这里分享给大家。
1.不要盲目选型，先搞清楚业务需求，再确定是否需要 K8s。
引入任何的分布系统都意味着复杂度的大幅提升，虽然 K8s 设计上非常简洁，但是对于普通开发人员来讲，其复杂度仍然不低，出了问题排障也不容易。所以建议，能单机解决的不要考虑分布式，不要为了技术而选择技术。
2.将 Etcd 单独部署。
因为 Etcd 是整个集群的存储中心，是需要小心保护的，一旦出问题，很大可能会影响整个集群的可用性。
3.尽量保证大部分的应用无状态。
尽管 K8s 提供了承载有状态应用的方案，但是有状态意味着需要额外地关心应用状态，这会给后续运维带来很大的挑战。
4.尽量保证大部分的 Node 节点可被快速替换。
意思是不要在 Node 上存太关键的数据，当 Node 故障时， 我们可以在不需要做太多额外工作的情况下将其快速将其剔除。如果需要存储状态，应当对集群分区，让不同角色的节点运行不同的应用。
