标签
note
字数
961 字
阅读时间
4 分钟
背景
- 早期的部署方式是将若干应用打成 jar 包后，通过 tomcat 等容器运行到服务器上
- 缺点：对于复杂大型应用，某个服务引发的内存溢出则会导致整个应用宕机
- 为解决上述问题，采用服务器上多开
虚拟机的方式隔离各个应用- 缺点：服务器上再开虚拟机，对于资源消耗大
- 基于前两种问题，演化出基于容器的不是方式
- 优点：一个容器就好比一个 linux 服务器，轻量
基于容器化的部署方式已经成为主流，但工业界一个成熟的项目可能需要成百上千的应用来支撑，如此一来，大量分布在不同服务器上的容器就靠人工就非常难以管理
而 Kubernetes 的出现就是为了解决这个问题，它将大量的容器编排管理起来
k8s 特性
- 服务发现与负载均衡：这点类似于 Nacos 等注册中心，同一个应用可能在不同的容器，各个容器又处于不同的服务器节点，K8s 能够将这些容器管理起来，请求来了以后能根据负载的情况将请求发送到具体的服务器。
- 存储编排：K8s 允许你自己来选择当前容器的存储空间大小，假如超过了这个空间它还能将这个容器杀死。
- 自动部署和回滚：自动的对容器进行部署，如果发生紧急事件，当前的新版本出现了生产事故并且当前来不及进行修复的话可以回滚到历史稳定版本。
- 自我修复：一个容器假如因其挂载的服务器出现问题而导致不能正常工作了，能够自动的将这个容器部署到别的健康的服务器。
架构
工作方式
kubernetes cluster = N master node + N worker node：N个主节点 + N个工作节点；N >= 1会有一个主节点起主要的发号施令的作用，若干个主节点又组成董事会，一旦主节点出现问题了就由其他的主节点通过投票的方式选举出新的发号施令的主节点
类似 Redis
角色
Node：就是各个负责工作的地方也就是工厂。
Kubelet：每一个工厂的负责人。
k-proxy：每一个工厂的门卫，当总部的人要来巡视工厂了，可以通过它来询问当前的项目是不是在这开展，不管有没有在它这开展它都能告诉领导该去哪里查看。
controller manager：决策者，决定项目由哪一个工厂来开展。
API server：秘书部，决策者的决策不会直接告诉工厂而是通过它来进行转达，同样地，工厂的情况也是通过它来转给决策者。
scheduler：调度者，调度项目的执行。
etcd：资料库，用于存放集团的资料。
- 每一个服务器中要有一个监工：kubelet，由它来负责监控整个服务器里面容器的监控状
- 所有的沟通都是通过秘书（api-server）
- 所有的服务器都要装上运行时环境，可以是 docker
- 可以通过命令的形式来进行部署
参考
Kubernetes 入门：一文带你快速看懂 K8s 是什么？
贡献者
jiechen