download：Kubernetes 入门到进阶实战

Kubernetes
本文内容仅为集体理解，如有偏颇，欢迎斧正。

一、传统的运维形式
在了解Kubernetes之前，咱们有必要先简略了解一下传统的运维模式。在传统的我的项目架构中(单体or微服务)，咱们一般将我的项目打包为war或fatJar的形式进行部署。

在部署时，需要人工创建相应的服务器及资源，并搭建我的项目运行的依赖环境，预估服务需要占用的内存与CPU，共事还要考虑到高可用的部署环境，在不同配置的服务器上部署相应的服务。当服务意外崩溃或者服务器意外宕机时，需要人工处理。总结一下传统部署的不足如下:

依赖服务器环境，需要各服务器资源对立。
无奈充分利用服务器等资源，使用率一般仅能达到70%。
无奈或很难做到容灾复原。
需要人工进行服务扩容，修改服务配置。
服务资源散乱(域名，服务器，负载，数据库)，无奈做集中管理。
工夫消耗较多，减少运维成本。
需要借助第三方工具进行资源监控，较为麻烦。
需要对开发、测试、生产环境进行区别治理。
要想解决以上的问题是相比照较麻烦的，特地是现在的我的项目多为微服务我的项目，少则几十，多则上百，极大的减少了运维的难度和成本。

一、Kubernetes是什么？
官网文档中描述为:v

Kubernetes一个用于容器集群的自动化部署、扩容以及运维的开源平台。通过Kubernetes,你可能疾速无效地响应用户需要;疾速而有预期地部署你的利用;极速地扩大你的利用;无缝对接新利用功能;俭约资源，优化硬件资源的使用。为容器编排治理提供了完整的开源打算。

介绍一下其中提到的几个词:

容器
咱们现在常说的容器一般是指Docker容器，通过容器隔离的个性和宿主机进行解耦，使咱们的服务不需要依赖于宿主机而运行，与宿主机互不影响，Docker容器十分轻量。而kubernetes则负责治理服务中所有的Docker容器，创建、运行、重启与删除容器。
疾速响应
集体理解为两个方面。一、新增或者修改需要时，可能疾速进行部署测试(CICD)；二、kubernetes可能根据不同条件进行动静扩缩容，举个栗子，用户访问量突然由1000人回升到100000人时，现有的服务已经无奈撑持，kubernetes会主动将用户服务模块减少更多实例以保障以后的零碎访问量。
扩大
在疾速响应的个性中已经有所提及，这里再补充一点: Kubernetes外部有欠缺的注册发现机制，当某个服务的实例减少时，kubernetes会主动将其加入服务列表中，罢黜在传统运维中需要人工保护服务列表的问题。
对接新利用
kubernetes是一个通用的容器编排框架，反对不同类型的语言，或者是语言无关的，新减少的利用都会以一个新的对象进行接入。
硬件资源
这一点我感觉是kubernetess很基本然而非常重要的一个长处了，kubernetes在部署利用时会主动查看各个服务器的cpu与内存使用量，同时会根据服务申请的cpu与内存资源，将服务部署到最合适的服务器。(其实这就是容器调度的核心功能了)
小学问: 因kubernetes名字过长，一般简称为k8s，因为k与s之间有8个字母，故而称之。

二、Kubernetes解决了什么问题？
上面以几个case进行阐述，便于理解。

服务器环境
kubernetes是使用Docker进行容器治理的，所以天生具备Docker的所有个性，只需要使用相应环境的Docker镜像就可能运行服务，还需要关心宿主机是redhat、centos还是ubuntu，只需在宿主机上安装Docker环境即可，相比传统运维，缩小了各种依赖环境的冲突，升高运维成本，也便利整体服务的迁徙。

服务器资源管理
对于kubernetes来说，是不关心有几台服务器的，每个服务器都是一个资源对象(Node)，kubernetes关心的是这个Node上有几可用的cpu和内存。例如现在有两台服务器

server01 (4c16g), 已用(2c7.5G)
server02 (4c16g), 已用(3c13G)
现在有一个服务ServiceA需要部署，ServiceA申明自己运行需要至多3G内存，这时kubernetes会根据调度策略将其部署到server01上，很显著server01的资源是更加短缺的。实际上kubernetes的调度策略要简单的多，kubernetes会监控整体服务器资源的状态进行调度，而以前的运维形式只能由人工判断资源使用。这里只做简略示例。

各个服务器节点的状态

总体集群的资源状态

服务容灾复原
说简略点，就是服务挂了之后，能够主动复原。例如现在有一个ServiceA，运行在server01上，kubernetes会通过外部的kubelet组件监控ServiceA服务过程的状态，一旦发现过程丢失(服务本身挂掉或者整个server01的服务器挂掉)，就会尝试换一台资源短缺的服务器重新部署ServiceA并启动，这样就可能确保咱们的服务一直是可用状态，而不需要人工保护。

硬件资源利用
后面已经说过，kubernetes会根据节点(Node)的CPU与内存资源的可用量对服务进行部署调度，在调度策略中，可能配置不同的调度策略。例如现在有两台服务器：

server01 (4c16g), 已用(3c7.5G)
server02 (4c16g), 已用(1c13G)
需要部署两个服务

serviceA-Java, 申请2G内存，0.5CPU单位
ServiceB-Nginx, 申请200M内存,申请1CPU单位
这里kubernetes如果讲道理的话，会将ServiceA-Java部署到server01，将serviceB-Nginx部署到server02。这里server01的内存和server02的CPU资源都失去了充分的利用。通过集体实践，相比之前的部署形式，kubernetes俭约了很多资源，资源利用是非常高效的。

服务资源创建
kubernetes创建服务是非常便利的，分为以下两个方面：

自有服务
在kubernetes中，进行我的项目服务部署是十分便利的，只需要构建好相应的镜像，编写一个yaml文件即可实现服务的部署。
yaml示例

apiVersion: apps/v1beta1
kind: Deployment
metadata:
# 部署的模块名称
name: phantom-server-admin
# 需要部署哪个环境
namespace: develop
spec:
# 部署的实例数量
replicas: 1
template:

metadata:  labels:    # 给这个部署打个标签，便利之后进行抉择    app: phantom-server-adminspec:  containers:  # 服务的名称  - name: phantom-server-admin    # 服务的镜像    image: phantom-server-admin:v1    ports:    # 服务的端口    - containerPort: 7006    resources:      limits:        # 该服务需要的内存        memory: 1000Mi