关于kubernetes:Kubernetes-入门到进阶实战

5次阅读

共计 2863 个字符，预计需要花费 8 分钟才能阅读完成。

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-admin
spec:
  containers:
  # 服务的名称
  - name: phantom-server-admin
    # 服务的镜像
    image: phantom-server-admin:v1
    ports:
    # 服务的端口
    - containerPort: 7006
    resources:
      limits:
        # 该服务需要的内存
        memory: 1000Mi

正文完