Kubernetes 简介_高可用高并发是kubernetes的特性吗-CSDN博客

本文链接：https://blog.csdn.net/tiancxz/article/details/104325235

简称k8s

Kubernetes为什么叫k8s呢，中间ks有8个字母。类似i18n，i和n，18为中间的字符数是“国际化”的简称。k8s是建立在容器引擎之上的，但容器不一定是docker。

现在又出来一个新产品k3s,它是容器管理软件提供商Rancher Labs(以下简称Rancher)宣布推出轻量级Kubernetes发行版 K3S 。主要用于一些小型的开发/生产环境、边缘计算节点甚至性能极其有限的设备（比如树莓派3）。

这所有的技术都是为业务服务的。

那k8s到底是解决什么业务问题的？

微服务开发三大指标

高可用，高性能，高并发

高性能方案

RPC通信,对外rest,对内RPC
Kyro高速序列化
HikariCP连接池,号称最快的连接池
SQL优化
Redis缓存
JVM优化
GC优化

高并发方案

垂直扩展
水平扩展
负载均衡
集群

高并发这些说白了就是烧钱。

高可用方案

那高可用是什么。就是一直可以用，达到99.999999%。一年允许宕机的时间大概是32秒左右，这个叫高可用。Kubernetes就是高可用方案里面的一个环节。

怎么做到高可用呢？

实现崩溃恢复，解决单点故障问题。
假设我们有2台Tomcat->1，挂掉一个。那这个怎么办，让我们手动去重启吗？我们肯定是想要自动重启。Kubernetes就提供了这个功能，自动重启。高可用肯定想实现自动重启这个效果。

自动扩缩容

另外一个就是并发大了以后，我开始水平扩展，从两台服务器扩展到5个、7个、9个。我们扩展是不是都要手动去扩展。那能不能自动去扩展？

比如网站压力一上来，我们就想根据压力自动扩展。打个比方一台tomcat抗1000个并发，2台可以2000并发。现在过来5000个并发，是不是至少需要5台服务器。
但是我们怎么知道什么时候会来5000个并发呢？我们是不是不知道，那我们又怎么可能及时上线去扩展服务器。也许就因为我们没有及时去扩展，导致我们前面两台服务器，压力负载过大都奔溃了。奔溃了是不是要重启，重启是不是需要时间。那我们的服务器可用性是不是就下降了。

换句话说，能不能流量来了以后，立即自动的启动多台tomcat来抗这个压力呢。所以这个Kubernetes又有一个功能叫自动扩缩容。这个什么意思呢？正常我们开两台tomcat，压力上来后，根据当前压力自动启动多台。压力离开以后呢，又能自动自释放资源变成两台。我们是不是需要有这样一个功能.

金丝雀发布

除了这个单点故障，自动重启，自动扩缩容还有一个问题就是服务要更新。更新服务是不是要重启，重启是不是可用度就要要往下掉了。
比如我们服务版本从1.0更新到1.1。要是我们运维手动斜街不好的话，上面两台tomcat全部挂掉。我们重新部署重新升级。那是不是代表着这个可用度又不行了。到这里是不是有个解决方案，能不能新旧版本同时，交替使用。

这里就有个新的概念叫金丝雀发布，也叫灰度发布，滚动更新。

又比如我们在更新的时候，1.1版本有bug。是不是要回滚。我们有2000台机器，如果你一次性把它更新上去后，是不是表示你2000台服务器都有bug。那我们是不是先更新一部分，再更新一部分，然后逐渐慢慢更新全部机器。一旦发现有问题，立即进行版本回滚。

概述

从Kubernetes的Logo可以看到它是一个舵，舵是轮船的方向盘，正所谓大海航行靠舵手，为什么叫舵呢？因为Kubernetes它最早出现的时候是和Docker的Swarm做竞争的。作为容器管理系统，Docker是集装箱，我是运集装箱的船，所以Kubernetes叫舵。

Kubernetes这个项目从出来之后就是以一种横扫别人的项目的趋势。别的项目基本上慢慢的被淘汰了。这些项目就有Docker自家的 Swarm。

Kubernetes 是 Google 2014 年创建管理的，是 Google 10 多年大规模容器管理技术 Borg 的开源版本。

Kubernetes 是容器集群管理系统，是一个开源的平台，可以实现容器集群的自动化部署、自动扩缩容、维护等功能。使用 Kubernetes 我们可以：

快速部署应用
快速扩展应用
无缝对接新的应用功能
节省资源，优化硬件资源的使用

Kubernetes 的目标是促进完善组件和工具的生态系统，以减轻应用程序在公有云或私有云中运行的负担。

特点

可移植： 支持公有云，私有云，混合云，多重云（多个公共云）
可扩展： 模块化，插件化，可挂载，可组合
自动化： 自动部署，自动重启，自动复制，自动伸缩/扩展

从传统到容器化部署

传统的部署方式

传统的应用部署方式是通过插件或脚本来安装应用。这样做的缺点是应用的运行、配置、管理、所有生存周期将与当前操作系统绑定，这样做并不利于应用的升级更新/回滚等操作，当然也可以通过创建虚机的方式来实现某些功能，但是虚拟机非常重，并不利于可移植性。

容器化部署的优势

快速创建/部署应用： 与虚拟机相比，容器镜像的创建更加容易。
持续开发、集成和部署： 提供可靠且频繁的容器镜像构建/部署，并使用快速和简单的回滚(由于镜像不可变性)。
开发和运行相分离： 在 build 或者 release 阶段创建容器镜像，使得应用和基础设施解耦。
开发，测试和生产环境一致性： 在本地或外网（生产环境）运行的一致性。
云平台或其他操作系统： 可以在 Ubuntu、RHEL、CoreOS、on-prem、Google Container Engine 或其它任何环境中运行。
分布式，弹性，微服务化： 应用程序分为更小的、独立的部件，可以动态部署和管理。
资源隔离
资源利用更高效