1. Kubernetes详细介绍

yeedomliu

发布于 2019-09-29 16:03:09

1.1K0

发布于 2019-09-29 16:03:09

文章被收录于专栏：yeedomliu

1. 内容

应用的开发和部署方式在近几年的发展趋势
容器如何保障应用间的隔离性，以及减少应用对部署环境的依赖性
docker容器如何在Kubernetes系统中应用
Kubernetes如何提高开发人员和系统管理员的工作效率

2. 介绍

开发方式

过去

多数的应用都是大型单体应用，以单个进程或几个进程的方式
发布周期长
迭代也不频繁
硬件故障时手动迁移应用
运行于几台服务器之上

现在

单体应用正被逐渐分解成小的、可独立运行的组件（微服务）
微服务之间独立开发、部署、升级、伸缩
快速迭代
随着部署组件的增多和数据中心的增长，配置、管理并保持系统的正常运行变得越来越困难

自动化

我们需要一些自动化的措施，包括自动调度、配置、监管和故障处理。这正是Kubernetes用武之地

脱离运维团队

Kubernetes使开发可以自主部署应用，并控制部署的频率，完全脱离运维团队的帮助

含义

Kubernetes是希腊语中领航员或舵手的意思

巨大资源池

Kubernetes抽象了数据中心的硬件基础设施，使得对外暴露的只是一个巨大的资源池，不用关注底层服务器

3. 系统需求

从单体应用到微服务

单体应用

一个小修改都需要重新部署整个应用
组件间相互依赖，日积月累导致系统复杂度提升，整体质量也急剧恶化
通过增加CPU、内存或其他系统资源的方式做垂直扩展，成本很高

将应用拆解为多个微服务

每个微服务以独立的进程运行，并通过简单且定义良好的接口通信
每个微服务可用最适合的开发语言来实现
可独立开发、部署、扩容单个微服务
服务增加导致部署相关的配置越来越困难
多个进程和机器间通信，使得调试代码和定位异常调用变得困难

为应用提供一个一致的环境

不管是开发或部署多少具独立组件，都需要解决程序运行环境的差异性，不仅存在于开发环境与生产环境，还存在于各个服务器之间
最理想的做法是让应用在开发和生产阶段可以运行在完全一样的环境下，有完全一样的操作系统、库、系统配置、网络环境

迈向持续交付：DevOps和无运维

介绍：现在，大家都意识到，让同一个团队参与应用的开发、部署、运维的整个生命周期更好，这种实践被称为DevOps
优点：开发更趋向于将应用尽快地发布上线，收集用户反馈，对应用做进一步开发；开发自己部署上线，而不需要交付给运维人员操作
NoOps：理想情况是，开发部署程序本身，不需要知道硬件基础设施的任何情况，也不需要和运维团队交涉

4. 容器技术

什么是容器

为什么使用容器
- 以往：通过给每个组件提供自己的操作系统实例来隔离它们的环境，数量变多后会浪费硬件资源
- 现在：使用linux容器技术，允许在同一台机器上运行多个服务，但开销小很多
比较虚拟机和容器
- 多个容器会完全执行运行在宿主机上同一个内核系统调用
- 虚拟机将物理硬件资源分成较小部分的虚拟硬件资源，每个虚拟机里的操作系统使用
image
image
- 图：使用虚拟机隔离一组应用程序与使用容器技术隔离单个应用程序
- 第一种类型管理程序不会使用宿主机OS，而第二种类型会
image
- 容器更加轻量，在相同硬件上运行更多数量的组件
- 隔离方式
- cpu使用方式对比
实现机制
- linux命名空间，每个进程只看到它自己的系统视图（文件、进程、网络接口、主机名等）
- Linux控制组（cgroups），限制了进程能使用的资源量（CPU、内存、网络带宽等），是linux内核功能

Docker容器平台介绍

参见《docker快速入门》

rkt——一个docker的替代方案

rkt（发音为“rock-it”）也是一个运行容器的平台，它强调安全性、可构建性、遵从开放标准
Kubernetes不止支持docker，还支持rkt

5. 大体介绍

初衷

谷歌等全球少数几个公司运行着成千上万的服务器，在如此海量规模下，不得不处理部署管理的问题。这推动着他们找出解决方案使成千上万组件的管理变得有效且成本低廉
谷歌开发出了Omega系统（原来叫Borg），开发和系统管理员管理那些数以千计的应用程序和服务都受益于它的帮助。简化开发和管理、获得更高的基础设施利用率，当有成千上万台机器，哪怕一丁点的利用率提升也意味着节约数百万美元。

了解

Kubernetes依赖于linux容器的特性，可以很容易地部署和管理容器化的应用
Kubernetes使你在数千台电脑节点上运行软件就像是单个大节点一样。它将底层基础设施抽象，简化了开发、部署、运维等工作
核心功能
- 开发把一个应用列表提交到主节点，Kubernetes会将它们部署到集群的工作节点
image

集群架构

一个Kubernetes餓由很多节点组成，分为两类：

主节点
- 功能：承载着Kubernetes控制和管理餓的控制面板
- Kubernetes API服务器：和其他控制面板组件通信
- Scheculer：调度应用，为应用的每个可部署组件分配一个工作节点
- Controller Manager：执行集群级别功能，如复制组件、跟踪工作节点、处理节点失败等
- etcd：一个可靠的分布式数据存储，持久化存储集群配置
工作节点
- 功能：运行容器化应用的机器
- docker、rtk等容器
- kubelet：与API服务器通信、管理所在节点容器
- Kubernetes Service Proxy（kube-proxy）：负责组件之间负载均衡

image

运行应用

介绍：要在Kubernetes中运行应用
- 将应用打包进容器镜像
- 将镜像推送到镜像仓库
- 将应用描述发布到Kubernetes API服务器
描述信息怎样成为一个运行的容器
- 当API服务器处理应用描述时，调度器调度指定组的容器到可用的工作节点上，调度是基于每组所需的计算资源，以及调度时每个节点未分配的资源。然后，那些节点上的Kubelet指示容器拉取镜像并运行容器
- 应用描述列出了四个容器，分为三组（这些集合被称为pod）
- 前两个pod只包含一个容器，最后一个包含两个
- 每个pod旁边的数字表示的副本数量
- 节点上的Kubelets告知要从镜像仓库拉取窗口镜像并运行容器
image
保持容器运行：Kubernetes不断确认程序状态是否与描述匹配，如发布描述需要5个实例，Kubernetes就会保持五个实例，如果有实例停止工作，Kubernetes将自动重启
扩展副本数量：可以手动增加或减少容器副本数，也可以根据指标自动调整副本数（如CPU、内存或其它指标）
命中移动目标
- Kubernetes对提供相同服务的容器提供一个静态ip，将该地址暴露给其它程序
- kube-proxy服务的容器实现负载均衡

好处

介绍：如果服务器部署了Kubernetes，那么运维团队不需要再部署应用程序，因为容器化的应用已经包含了运行所需的所有内容
简化应用部署
- 开发不需要关心应用部署在哪台服务器上，只要服务器能提供足够的系统资源就可以了
- 特殊情况下需要关心运行在哪台服务器上（是不是特需的硬件，如服务器上是否是SSD、是否有GPU）
更好利用硬件：通过使用容器，不用再把应用绑定在一个特定的集群节点，可以在集中中自由迁移
健康检查和自我修复：Kubernetes监控应用和节点，并在节点出现故障时自动调度到其他节点
自动扩容：使用Kubernetes不需要监控应用负载，它会自动监控应用使用的资源，并不断调整应用运行实例数量