| 导语 上一篇文章我们讲解了什么是 kubernetes(K8S) , 你对 K8S 的概念目前已经有个初步的了解. 很多同学估计想开始着手学习了, 这篇文章我们来了解下 K8S 的一些必备基础是什么.
一, 系统运维基础
支撑 K8S 集群的操作系统基本上是 Linux, 而且内核版本是要在 3.8 以上(建议 3.10 以上). 因此, 学习 K8S 必须要会 Linux 操作. 另外初级的 Linux 水平是不够的, 至少要有 2-3 年的 Linux 系统运维经验, 在出现系统层问题的时候你能一定程度的定位和排障. 这里 K8S 支持多种 Linux 的发行版本, 也许你会问用 CentOS 还是 Ubuntu? 个人建议还是使用 CentOS, 理论上来说服务器领域 CentOS 稳定性会比 Ubuntu 强很多, 毕竟 CentOS 基于 RedHat, 有红帽这么强大的开源技术公司做后盾总比后边是社区的 Ubuntu 可靠些.
没有 Linux 系统运维经验的同学如果你想学习 K8S 会有点艰难, 建议先加强 Linux 的了解. 可以的话, 可以参加下红帽的系列认证, 能拿到 RHCA 的话是最好不过了. 目前网上也有很多 Linux 的学习视频, 学习路线图也很清晰和丰富, 建议从 7.x 版本的开始学习.
二, 网络运维基础
K8S 集群除了系统层面的维护网络这块也是需要了解的. 根据本人多年的运维经验, 网络层面出现的问题次数一般比系统层面的会多一些. 另外, K8S 底层是虚拟化技术, 这块又包含网络虚拟化. 网络本身就很抽象了, 如果是网络虚拟化就更加抽象. 现在搞云计算虚拟化运维的人员也是经常被网络问题搞得比较头疼, 这里不仅仅需要你懂传统的网络知识, 同时也需要你掌握虚拟化层网络连接通信. 不过, 网络这块如果比较弱, 不直接影响你开始的 K8S 入门学习, 不过在日后的 K8S 集群维护, 网络排障和网络调优是必不可少的, 因为 K8S 的底层网络用了大量的网络虚拟化. 如果你有兴趣加强学习这块, 建议按照 "传统网络技术学习 --> 虚拟化技术学习 --> 网络虚拟化 SDN 技术学习" 这样的路线行走.
网络虚拟化这项技术学习周期会比较长, 在云计算运维领域里, 这是一个单独的方向. 学习 K8S 可以不必在这块玩得很精通(前提参考你的工作性质), 但是基本的概念和知识点还是需要掌握的.
三, 存储运维基础
跟网络虚拟化一样, K8S 集群底层存储也需要用到虚拟化技术(当然排除有钱的公司直接用商业的集中式存储), 这里通常会用到开源的 ceph 技术. 存储虚拟化的运维相对网络虚拟化会简单一些, 但是它的重要性非常高(毕竟数据无价). 通常 K8S 集群设计方案会跑在稳定的 IAAS 层之上, IAAS 层会采用 OpenStack,vmware vSphere 等平台建设. IAAS 层本身就会用到成熟的存储和网络虚拟化技术, 因此 K8S 直接复用就行. 不过在一家体量不大的公司里, IAAS 层也是需要你或者同个部门维护, 毕竟上层会受到下一层的影响.
学习 K8S 需要一定的存储运维经验, 保证数据的稳定性, 是一个运维人员最基本的要求.
四, 安全机制基础
安全这个话题比较大, 而且在 IT 的任何时期都非常重要. 云时代的来临更加让安全受到重视. 想想用户在云平台里大规模使用云主机, 如果没有安全的保障那么跑在云上的应用很容易受到攻击. K8S 提供了 PAAS 层的解决方案, 那么如何保证 PAAS 层的安全? 这里也是个很值得研究的问题. 下面这张图是来自 CNCF 的一个统计数据, 表示的是用户在使用 K8S 的时候, 哪一技术领域最让用户担心和受到挑战:
来源 CNCF
很明显, Security 安全这块是 TOP1. 安全问题是 "道高一尺魔高一丈" 的问题, 有时候并不是完完全全靠技术就能搞定. 这里通常要做到 "技术 + 流程 + 意识 + 法律" 等多方面手段共同完成. 另外要提到一点的是, 容器技术本身就在安全性有很大的挑战, 它的隔离性问题一直是饱受诟病. 不过, 最新的 Kata 还有 Podman 的推出都在尝试着解决这个问题.
安全领域是一个方向, 我们在学习 K8S 的时候不了解安全不影响你学习 K8S 本身, 它其实就像一个套在 K8S 外层的护盾. 但是在日后维护没有安全方面的意识, 搭建的平台将有很高的风险. K8S 之前也是经常爆有安全漏洞, 这些安全信息我们需要及时了解, 然后快速找到有效的补丁进行解决.
五, 开发编程基础
前几年自动化运维让各种脚本语言大火了一下, 特别是 Python 语言. 一位运维工程师如果不会一门编程语言, 你很难有竞争力. 当前很多平台本身环境也复杂, 重复循环做的事情也很多, 不整理归纳做自动化处理工作量会很大. K8S 集群的维护也是少不了自动化的, 底层的部署, 配置修改, 资源管理等等. K8S 是 go 语言编写的. go 语言跟 python 一样, 目前也是非常火爆. 这门语言具有高并发性能, 使用学习也简单. 如果你要深入了解 K8S, 源码的阅读是少不了的.
不管是学习 python 也好还是 go 语言也好, 会开发语言能完成一些手动无法完成的事. 同时, 学习编程语言能让自己更加有竞争力. 而且 K8S 本身的一些使用方法, 设计模式都具有很浓的运维开发思维, 也就是大家常说的 devops. 想要高大上的做运维工作, 开发能力必须要有!
六, 容器技术基础
K8S 是容器资源管理平台, 它里面不仅仅可以支持 docker, 其他的容器技术比如 CoreOS 的 Rocket 以及最新的 Podman 都是可以支持的. 类似 OpenStack 不仅仅可以管理 KVM 也可以管理 Xen, 管理 vmware. 学习 OpenStack 我们要了解 KVM 虚拟化技术, 同理学习 K8S 必然要学会 Docker,Rocket 等容器技术.
目前 K8S 这块主要集成的是 Docker, 网上对 docker 描述的文章和书籍都非常多. 本人也写了 10 篇关于 docker 入门的知识文章, 大家有兴趣可以在专栏向前翻找.
七, 配置管理基础
这里主要是强调下 YAML 语言的学习. K8S 里面大量用到了 YAML, 通过定义 YAML 文件达到配置和管理 K8S 里各种资源的目的. 我们前面学到过 K8S 里面有多种控制器, 那么这些控制器如何操作资源(比如 Pod), 那么就需要通过 YAML 文件. 用户在 YAML 文件定义各种参数, 然后让控制器去执行.
另外, 除了 YAML 的学习, 咱们也需要掌握一些优秀的配置管理思维. K8S 能助力 CI/CD, 一些版本控制, 变更发布都需要有一套完善的标准化体系. 面对大型的 PAAS 资源平台, 除了运维能力的要求, 一些配置流程管理工作也是需要做到位的. 运维能力决定平台的稳定性, 配置管理决定的是平台的标准化, 流程化. 一些过往的大事故, 我们也经常有听说过是因为自动化配置出错导致的.
八, 云原生概念的了解
云原生 (Cloud Native) 这个概念最近在网上提得很多, 容器微服务火了之后经常见到这个词. 红帽对云原生是这么解释的: 云原生落地得靠云原生应用, 而云原生应用就是独立的小规模松散耦合服务的集合, 旨在提供被大家都认可的业务价值, 例如快速融合用户反馈和需求以实现持续改进. 简而言之, 通过云原生应用开发, 您可以快速构建新应用, 优化现有应用并将这些应用组合在一起, 其目标是以最快的速度满足用户的需求.
RedHat Cloud Native
个人理解 云原生(Cloud Native), 咱们可以拆分下, Cloud Native = 云 + Native.
云: 云计算, 上云
Native: 这里的 native 应该理解为 "原生方法" ,Native Method. 而这个原生方法主要由 devops, 微服务, 容器, 持续交付四种理论和方法来实现. 网上有关于云原生的结构图:
Cloud Native
云原生里四大方面包含了 CI/CD, 微服务, 容器等技术, 这三个很直接跟 docker 和 K8S 都有关系. 所以, 学习好 K8S 也是为新一代的架构方法打下基础. 未来, 用到 K8S 的地方会越来越多, 云原生直接给出了一个大的方向, 具有很强的指导意义.
总结: 以上从八个方面大概讲述了下学习 K8S 之前需要做的一些准备. 有些出发点更多是从本人经验得出的, 难免有纰漏, 大家可以适当参考. 不过总体来讲, 未来下个 10 年是属于容器的时代, 学习 K8S 势在必行.
来源: https://www.qcloud.com/developer/article/1431406