《k8s in action》第一章

简介

这一章主要阐述什么是 k8s？它的由来是怎样的？它能对开发者和运维带来怎样的帮助。

重点内容

• 软件开发和部署在最近几年的变化
• 通过容器隔离应用以及减少环境差异
• 理解 k8s 是怎么使用容器和 docker
• 简化开发和运维工作

k8s 的由来

从单体到微服务

早期，软件通常是单体应用，功能模块都在一个进程里面。这种做法缺乏影响隔离，运维部署的时候，也需要小心翼翼地搭建整套的环境，随着功能越多，运维部署也越复杂。同时伸缩性通常也较差，垂直伸缩，上限较低；水平伸缩，很多时候又不太可行，尤其是所有模块都在一个进程里面，某些模块无法做垂直伸缩的话，就会导致整个进程无法进行水平伸缩。

后来，有了一种更好的解决方案，就是微服务，或者说吧单体应用进行拆分。这样一方面能做到进程隔离，也能起到解偶的作用。使用微服务还可以将水平伸缩的服务进行独立部署，对不能水平伸缩的服务做垂直提升，灵活性较高。

但服务化带来一个运维部署新的困难。首先，服务数量越多，服务之间可能存在内部依赖，这对服务发现带来了一定的挑战。其次，难以调试和跟踪调用情况（不过现在的分布式 trace 也日趋成熟）。最后，来自于环境差异性的困难。这些服务可能会有一些依赖库，每个服务要求的库版本可能不同，这种情况如果同机部署的话，可能会带来不小的维护负担。尤其是模块化后，可能不同的模块由不同的人开发，这种情况出现可能性就越大。此外，诸如生产环境和开发环境的差异，也会造成影响，尤其是生产环境往往是运维部署，而开发环境是由开发同学打理。对于运维同学更关注的是资源使用率，是安全问题；而对开发同学更关注功能实现，那假设有因为安全漏洞要升级，运维的库替换、版本升级都可能对服务造成影响。

因此，我们需要消除环境的差异，最好是能做到环境是相同的，一致的。

从 DevOps 到 NoOps

DevOps： 快速交付，无需等待运维，但需要了解硬件
NoOps：使用 k8s 无需了解硬件架构，且无需跟运维打交道。

容器技术由来

VM: 开销大，每个 vm 都需要独立的系统资源，每个 VM 都有自己的操作系统，这些系统资 源的 overhead 也会导致资源的浪费。另外，随着服务的增加，VM 的管理和维护成本也需要更多的人力。

容器：通过软件技术做到应用的相互隔离，大家共用相同的操作系统，由于开销小，所以实际上每个应用都可以有自己的容器，配套独立的环境，成本低。

容器是如何实现的？

Linux 的命名空间可以对资源做隔离，一个资源只能对应一个唯一的命名空间。但用户可以创建命名空间，把某些资源划分到这个资源下。这样进程只能看到自己对应命名空间的资源，从而做到了资源隔离。

Linux 的资源限制，借助 croup 来实现，Linux 的 cgroup 可以限定一个进程使用的资源量（cpu、内存、网卡带宽）。