k8s专题-链接

简介

包含关于 k8s 一些合集内容

现在主流的项目运行环境有三类环境

如果选择呢？主要看项目的首要需求。

侧重点主要是高性能, 其次是兼容性；

性能:
分布式架构, 因为有跨节点通信和同步的开销, 所以性能绝对没有单节点内运行高;
例如对延迟要求极高, 或性能要求极高的场景, 还是得直接在物理机上跑好一些

兼容性:
对于老旧应用, 以及需要专有硬件外设的场景; 物理机如果跑不起来, 其它环境就更别想了；

侧重点主要是隔离，其次是资源利用率

隔离:
当一个公司20个部门共享10台物理机的时候, 怎么分配合适？
向其它部门借用几台主机后，如何尽快纳管, 后续如何归还？
我部门部署的应用运行时会不会影响到别的部门;

虚拟化的隔离性，可以有效解决这些问题;

利用率:
纯物理机的场景, 很多非核心应用主机，常年CPU使用率不足 1%-5%，太浪费了；
多部门复用一台机器, 只要CPU使用率没有上饱和都可以继续分配；有效提升资源利用率；

侧重点主要是调度

误区: 容器化的核心并不是提升资源使用率；
虚拟化场景下已经能做到有效利用 CPU 或内存资源 80% 了，容器化后最多加到90%，如果只是为了提升这一点其实意义不大。

容器化的核心是调度, 一个应用实例能最快速度的部署, 最快速度的扩容和缩容, 下线等。

传统模式下，如果某个线上运行了50份实例的应用需要更新，并且扩容到1000份；需要很大的运维支持能力;
新环境准备, 代码更新、编译打包、上传更新、断流、重启、恢复流量、更新配置中心、更新网关等等一长串步骤。

现在容器化后，其实可以理解为使用业内最佳实践标准化了发布更新流程;

所以
如果有极致性能、兼容性、稳定性需求，优先考虑物理机环境；
如果有强隔离需求, 例如前面提到的多部门共享一批主机的场景，优先考虑虚拟化环境；
如果是要求快速业务变更，标准化部署模式，优先考虑容器化环境;

如果是部门专用的物理机环境, 则直接在物理机上部署k8s环境。
如果是公司的共享物理机资源池, 则先划分虚拟机分配给各部门后, 各部门再独立部署k8s环境;

虽然k8s也可以通过命名空间进行租户隔离, 但隔离程度还是不高；
举个例子: 两个部门都部署了一个程序, 需要相同的 hostPath 路径, 此时就会冲突；

我目前有 4 台电脑

早期是采用 j6412 跑虚拟机部署, 3主节点 + 3 worker 节点的方式;

后来发现即便空跑, 资源占用也非常高, 物理机上看着CPU使用率都上60%了，于是放弃虚拟机方案;

目前的部署方式:
j6412: 部署单节点 etcd，加单 master 节点;
y410p 和 ser6 为 worker 节点;

资源损耗已经降低到最少了;

注意事项:
etcd 集群同步起来后即便空跑开销也挺大的, 所以我这才使用单节点;

我之前为了节省资源, 用的是物理机的 docker + docker-cri 来跑 k8s 环境, 但要折腾很多内容;
所性后面都换成了 containerd 来跑, 省心省力, 也是趋势所在。