关于k8s
Kubernetes学习
·
1.k8s是如何⽕起来的
是由于云计算，云计算这个概念是google提出的，可以为企业带来便利，降低成本。
云计算分为三⼤服务层：
IaaS
（Infrastructure as a Service，基础设施即服务）、
PaaS
（Platform as a Service，平台即服务、
SaaS
（Software as a Service，软件即服务）。
- IaaS 层通过虚拟化技术提供计算、存储、⽹络等基础资源，可以在上⾯部署各种 OS 以及应⽤程序。开发者可以通过云⼚商提供的 API 控制整个基础架构，⽆须对其进⾏物理上的维护和管理。
- PaaS 层提供软件部署平台（runtime），抽象掉了硬件和操作系统，可以⽆缝地扩展(scaling）。开发者只需要关注⾃⼰的业务逻辑，不需要关注底层。
- SaaS 层直接为开发者提供软件服务，将软件的开发、管理、部署等全部都交给第三⽅，⽤户不需要再关⼼技术问题，可以拿来即⽤。
以前主流的做法就是申请或创建⼀批云服务（Elastic Compute Service），⽐如亚⻢逊的
AWS EC2
、阿⾥云
ECS
或者
OpenStack
的虚拟机，然后通过
Ansible
、
Puppet
这类部署⼯具 在机器上部署应⽤。
但随着应⽤的规模变得越来越庞⼤，逻辑也越来越复杂，迭代更新也越来越频繁，这时我们就逐渐发现了⼀些问题，⽐如：
- 性价⽐低，资源利⽤率低
有时候⽤户只是希望运⾏⼀些简单的程序⽽已，⽐如跑⼀个⼩进程，为了不相互影响，就要建⽴虚拟机。这显然会浪费不少资源，毕竟
IaaS
层产品都是按照资源进⾏收费的。同时操作也⽐较复杂，花费时间也会⽐较⻓；
- 迁移成本⾼
如果想要迁移整个⾃⼰的服务程序，就要迁移整个虚拟机。显然，迁移过程也会很复杂；
- 环境不⼀致
在进⾏业务部署发布的过程中，服务之间的各种依赖，⽐如操作系统、开发语⾔及其版本、依赖的库
/
包等，都给业务开发和升级带来很⼤的制约。
Docker：
Docker
这个新的容器管理引擎⼤⼤降低了使⽤容器技术的⻔槛，轻量、可移植、跨平台、镜像⼀致性保障等优异的特性，⼀下⼦解放了⽣产⼒。开发者可以根据⾃⼰的喜好选择合适的 编程语⾔和框架，然后通过微服务的⽅式组合起来。交付同学可以利⽤容器保证交付版本和交付环境的⼀致性，也便于各个模块的单独升级。测试⼈员也可以只针对单个功能模块进⾏测试，加快测试验证的速度。
在某⼀段时期内，⼤家⼀提到
Docker
，就和容器等价起来，认为
Docker
就是容器，容器就是
Docker
。其实容器是⼀个相当古⽼的概念，并不是
Docker
发明的，但
Docker
却为其注⼊了新的灵魂——Docker
镜像。
Docker
镜像解决了环境打包的问题，它直接打包了应⽤运⾏所需要的整个
“
操作系统
”
，⽽且不会出现任何兼容性问题，它赋予了本地环境和云端环境⽆差别的能⼒，这样避免了⽤户通过“
试错
”
来匹配不同环境之间差异的痛苦过程， 这便是
Docker
的精髓。
容器调度平台：
⼀个容器编排引擎需要哪些能⼒？
如表所示，⾸先容器调度平台可以⾃动⽣成容器实例，然后是⽣成的容器可以相邻或者相隔，帮助提⾼可⽤性和性能，还有健康检查、容错、可扩展、⽹络等功能，它⼏乎完美地解决了需求与资源的匹配编排问题。
其实主流的容器管理调度平台有三个，分别是
Docker Swarm
、
Mesos Marathon
和
Kubernetes
，它们有各⾃的特点。但是同时满⾜上⾯所述的⼋⼤能⼒的容器调度平台，其实非Kubernetes 莫属了。
Kubernetes
的⽬标就是消除编排物理或者虚拟计算、⽹络和存储等基础设施负担，让应⽤运营商和开发⼯作者可以专注在以容器为核⼼的应⽤上⾯，同时可以优化集群的资源利⽤率。
Kubernetes
采⽤了
Pod
和
Label
这样的概念，把容器组合成⼀个个相互依赖的逻辑单元，相关容器被组合成
Pod
后被共同部署和调度，就形成了服务，这也是
Kuberentes
和其他两个调度管理系统最⼤的区别。
相对来说，
Kubernetes
采⽤这样的⽅式简化了集群范围内相关容器被共同调度管理的复杂性。换种⻆度来说，
Kubernetes
能够相对容易的⽀持更强⼤、更复杂的容器调度算法。
2.k8s的架构是什么样的
Kubernetes
借鉴了
Borg
的整体架构思想，主要由
Master
和
Node
共同组成。
我们需要注意
Master
和
Node
两个概念。
其中
Master
是控制节点，部署着
Kubernetes
的控制⾯，负责整个集群的管理和控制。
Node
为计算节点，或者叫作⼯作负载节点，每个 Node 上都会运⾏⼀些负载容器。
为了保证⾼可⽤，我们也需要部署多个
Master
实例，最好为这些
Master
节点选择⼀些性能好且规格⼤的物理机或者虚拟机，毕竟控制⾯堪称
Kubernetes
集群的⼤脑，要尽⼒避免这些
实例宕机导致集群故障。
同样在
Kubernetes
集群中也采⽤了分布式存储系统
Etcd
，⽤于保存集群中的所有对象以及状态信息。有的时候，我们会将
Etcd
集群也⼀起部署到
Master
上。
k8s组件
Kubernetes
的控制⾯包含着
kube-apiserver
、
kube-scheduler
、
kube-controller-manager
这三⼤组件，我们也称为
Kubernetes
的三⼤件。
1
、⾸先来看
kube-apiserver
，它 是整个
Kubernetes
集群的
“
灵魂
”
，是信息的汇聚中枢，提供了所有内部和外部的
API
请求操作的唯⼀⼊⼝。同时也负责整个集群的认证、授权、访问
控制、服务发现等能⼒。⽤户可以通过命令⾏⼯具 kubectl
和
APIServer
进⾏交互，从⽽实现对集群中进⾏各种资源的增删改查等操作。
APIServer
跟
BorgMaster
⾮常类似，会将所有的改动持久到
Etcd
中，同时也保存着⼀份内存拷⻉。
2
、再来看
Kube-Controller-Manager
，它负责维护整个
Kubernetes
集群的状态，⽐如多副本创建、滚动更新等。
Kube-controller-manager
并不是⼀个单⼀组件，内部包含了⼀组资源控制器，在启动的时候，会通过 goroutine
拉起多个资源控制器。这些控制器的逻辑仅依赖于当前状态，因为在分布式系统中没办法保证全局状态的同步。同时在实现的时候避免使⽤过于复杂的状态机，因此每个控制器仅仅对⾃⼰对应的资源对象做操作。⽽且控制器做了很多容错处理，⽐如增加 retry
机制等。
3
、最后来看
Kube-scheduler
，它的⼯作简单来说就是监听未调度的
Pod
，按照预定的调度策略绑定到满⾜条件的节点上。这个⼯作虽说看起来是三⼤件中最简单的，但是做的事情可⼀点不少。
Node节点
- 容器运⾏时主要负责容器的镜像管理以及容器创建及运⾏。⼤家都知道的 Docker 就是很常⽤的容器，此外还有 Kata、Frakti等。只要符合 CRI（Container Runtime Interface，容器运⾏时接⼝）规范的运⾏时，都可以在 Kubernetes 中使⽤。
- Kubelet 负责维护 Pod 的⽣命周期，⽐如创建和删除 Pod 对应的容器。同时也负责存储和⽹络的管理。⼀般会配合 CSI、CNI 插件⼀起⼯作。
- Kube-Proxy 主要负责 Kubernetes 内部的服务通信，在主机上维护⽹络规则并提供转发及负载均衡能⼒。
Master和Node交互⽅式
Kubernetes
中所有的状态都是采⽤上报的⽅式实现的。
APIServer
不会主动跟
Kubelet
建⽴请求链接，所有的容器状态汇报都是由
Kubelet
主动向
APIServer
发起的。
当集群资源不⾜的时候，可以按需增加
Node
节点。⼀旦启动
Kubelet
进程以后，它会主动向
APIServer
注册⾃⼰，这是
Kubernetes
推荐的
Node
管理⽅式。当然你也可以在
Kubelet
启
动参数中去掉⾃动注册的功能，不过⼀般都是默认开启这个模式的。
⼀旦新增的
Node
被
APIServer
纳管进来后，
Kubelet
进程就会定时向
APIServer
汇报
“
⼼跳
”
，即汇报⾃身的状态，包括⾃身健康状态、负载数据统计等。当⼀段时间内⼼跳包没有更新，那么此时 kube-controller-manager
就会将其标记为
NodeLost
（失联）
Kubernetes
中各个组件都是以
APIServer
为中⼼，通过松耦合的⽅式进⾏。借助声明式
API
，各部件通过
watch
的机制就可以根据各个对象的变化，很快地做出相应的处理操作。
K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容
更多推荐
0
0- 0
已为社区贡献1条内容
所有评论(0)