参考

  • 面向 Kubernetes 编程： Kubernetes 是下一代操作系统

    命令对比

    Kubernetes 是一个操作系统。

    要点摘录

  • kubectl 对应的 linux 中的 shell

  • kubectl 访问集群的凭据好比远程连接 linux 机器的密钥；
  • pod 对应的是 linux 中的进程！
  • kubectl 应用的 yaml 对应 linux 中的一大堆配置；
  • kubectl 中的应用资源限制对应 linux 中的 cgroup。（kubectl 能实现资源限制，背后的原理也是 linux 的cgroup）
  • 分布式应用发布，使用linux还需要配置nginx、形成一个内网；
  • 分布式应用容灾，linux 部署时还需要搞健康检查。

  • 数据持久化。通过挂载存储卷，能够无障碍使用老数据。—— 但是我觉得不是那么完美，比如把 mysql 镜像的版本安装错误那次。

    个人体会

  • 之前想做 Linux 的运维开发，那么现在就是 K8S 的运维开发了。

  • Linux 的底层是 C，K8S 的底层是 Golang。

    完整对比

    | 功能/名词 | 单机 Linux | Kubernetes | 说明 | | —- | —- | —- | —- | | Shell, CMD | sh, bash | kubectl | kubectl 是 Kubernetes 的 shell 工具，有了 kubectl 你就可以连接并管理 Kubernetes 这个超级虚拟机了。 | | 用户，登录 Linux | User, Group, ssh 登录 | kubeconfig 文件类似 Linux ssh 的 .key 文件，用户使用 kubeconfig 访问 Kubernetes 就自带了用户信息。Kubernetes 能根据用户限制权限，也能限制用户能使用的资源。
    kubectl 使用 kubeconfig 访问 Kubernetes 就好比使用 .ssh key 访问 Linux | Kubernetes 集群管理员(或者自动化的申请系统)为用户颁发 kubeconfig 文件。
    (理解为创建 K8S 集群时的 RSA 密钥对。)
    也就是 K8S01 集群页面的上的访问凭据。
    kubectl 只有配置了此访问凭据才能访问集群。 | | 进程 | 进程 | Pod | Pod 就是 Kubernetes 这个 “超级虚拟机” 的进程。 | | 管理进程 | ps, kill | kubectl get pod, kubectl delete pod | 发布、升级、管理 “进程”(或者说应用) | | 配置管理 | 登录各个 Linux VM，替换机器上的文件。 | kubectl apply -f ./cm.yaml | 使用 ConfigMap 管理应用的配置文件，一次提交，进程的每个实例自动生效新的配置。由于篇幅管理，使用 ConfigMap 配置应用（“进程”）启动参数不在此文章里面举例。 | | 发布、管理、升级应用 | 在 Linux 上面发布一个应用，需要一顿疯狂的操作：先阅读如何发布、参数有什么、下载二进制包、搞定一些配置文件，然后运行应用。 | kubectl apply -f ./my-app.yaml | my-app.yaml 可能是应用提供商提供的、面向 Kubernetes 发布应用的“菜单”文件(为什么叫“菜单”我后面会介绍)。只要提交这个“菜单”，应用就部署好了。Kubernetes 让一切简单，而且，它是分布式，是天然容灾的。只要向 Kubernetes 提交 Deployment 这样的“资源”即可，下文有介绍。 | | 限制应用资源 | 一顿疯狂的操作，把应用进程的 Cgroup 限制好。 | 发布应用时已经做了 | Kubernetes 让一切简单。 | | 分布式应用发布 | 在各个 Linux 虚拟机上面发布好应用，然后把他们组网。 | 发布应用时已经做了 | 还是那句话，Kubernetes 让一切简单。 | | 分布式应用容灾 | 搞个监控，监控我们各个 Linux 虚拟机上面的应用是不是不健康了。不健康了的话，我们起床，来一次“一顿操作猛如虎”的故障恢复操作。 | / | 天然容灾，安心睡你的觉。 | | 数据持久化，故障时数据迁移 | “一顿操作猛如虎” | 用 PV（持久化存储卷），容灾把应用的一个应用实例从 “节点一” 切换到了 “节点二”，都不用做任何数据迁移。新的应用实例起来就能使用老数据。 | |