为甚麽 「需要」 Kubernetes?

一个走完开发流程之後所产出的软件应用程序(或称系统)，都会有他自己的架构。
而我们在 Development 环境下的架构跟 Production 环境下的架构肯定是不会一样的，毕竟里面牵扯了很多安全性、可靠性、稳定性...之类的 Issue。

在真正的 Production 环境下，可能会涉及多个服务。 Maybe 你的系统会牵扯到资料库服务、後台管理服务、程序码版本控制服务、云端储存服务等各式各样的其他系统，那麽就有极大的可能你会在部属的时候需要去做「跨服务器、跨主机」的部属。

这时候 Kubernetes 就会派上用场了，不论是在安全性、附载均衡、服务的 recovery、服务的 orchestration、日後的水平或垂直扩展，它都可以提供一个稳定、便捷的解决方案。

为甚麽「采用」 Kubernetes?

Source: https://www.redhat.com/en/topics/containers/what-is-kubernetes

一切都要从这张图片开始说起，我将会由下往上说明。

容器化的服务 --- 微服务

如果有空的话可以先参考一下以下文章：
DevOps、微服务、容器化
何谓微服务？

有别於传统的应用程序系统架构，这样子微服务的架构会将一个应用到的服务部属在一台虚拟主机上，会呈现一个一对多的样态。而这样子分散式部属的系统会把整体应用程序切分成多个独立的流程，为将来的扩充性跟服务的恢复提供一个解套。

小结论：微服务加上容器化技术，大大地将软件系统的扩展性与服务开发的速度提升，也可以让整个软件系统更加的稳定。

容器服务的编排

Orchestration 编排一词，主要叙述的是将微服务放进容器之後去编排它的执行，在 Kubernetes 中它的编排可以在该服务的 configuration yaml file 里面去做详细的设定，不仅仅是它的储存位置、网路设定、以及安全性、自动化都会被有效的处理。
这不仅是对於 Production 环境有帮助，对於在 Git Repository 跟 Development 环境都会有大大的帮助。

根据 RedHat 组织所描述的 Container Orchestration 用途有：

• 服务供应、部属
• 组态设定与排程
• 资源分配
• 可用性
• 水平扩展或减少
• 附载均衡
• 容器状态监控
• 自动编排需要启用的服务
• 维护容器间沟通的安全性

Migration 迁移

当你的应用程序系统已经采用了微服务的架构去部属、开发了之後，将会获得前所未有的可用性、可迁移性。
这代表说未来你在不论私有网路里的服务器、云端服务的服务器、又或者是自己架设的服务器从集中都可以自由的迁移，也可以实现多方的服务备份、在服务器不预期的 outage 或 downtime 时候快速的重新布署、甚至是高速的 rollback 以及 self-recovery。

结论

经过这样子的介绍，可以了解到在系统充分的容器化、微服务化之後，就可以更完善的利用 Kubernetes 的特性了，如果想要了解微服务的夥伴不妨可以先参考看看 RESTful API ，再重新审视过 datatable 的设计与 data 的可用性，最後去看看 Monolithic 架构与 Microservices 架构的不同，虽然这些都是开发取向的知识，但却是更好的部属进 Kubernetes 的基础喔!