一个正在运行的 Linux 容器可以被“一分为二”地看待：
Kubernetes关心的是“容器镜像”
控制节点（Master）：由负责 API 服务的 kube-apiserver（整个集群的持久化数据，也由 kube-apiserver 处理后保存在 Ectd 中）、负责调度的 kube-scheduler，以及负责容器编排的 kube-controllermanager组成，在kubeadm这种部署方式中，一个组件以一个Pod形式被部署
计算节点（Node）：
kubelet主要负责同容器运行时（比如 Docker 项目）打交道，使用 CRI（Container Runtime Interface），接口，该接口定义了 容器运行时的各项核心操作，比如启动一个容器需要的所有参数
OCI：具体的容器运行时，比如 Docker 项目，一般通过 OCI 这个容器运行时规范同底层的 Linux 操 作系统进行交互，即：把 CRI 请求翻译成对 Linux 操作系统的调用（操作 Linux Namespace 和 Cgroups 等）。
gRPC：和 Device Plugin进行交互。该插件是 Kubernetes 项目用来管理 GPU 等宿主机物理设备的主要组件，也是基于 Kubernetes 项目进行机器学习训练、高性能作业支持等工作必须关注的功能
CNI：调用网络插件为容器配置网络
CSI：调用存储插件为容器配置持久化存储
声明式API： API 对应的“编排对象”和“服务对象”，都是 Kubernetes 项目中的 API 对象（API Object）。
首先，通过一个“编排对象”，比如 Pod、Job、CronJob 等，来描述你试图管理的应用；
然后，再为它定义一些“服务对象”，比如 Service、Secret、Horizontal Pod Autoscaler（自 动水平扩展器）等；这些对象，会负责具体的平台级功能。
容器间的关系
Pod：最基础的一个对象，Pod 里的容器共享同一个 Network Namespace、同一组数据卷，从而达到高效率交换信息的目的，可以将交互密切的容器放在同一个Pod里，可以等价为一个应用
Service：解决不同服务的交互问题，比如 Web 应用与数据库之间的访问关系；
给 Pod 绑定一个 Service 服务，而 Service 服务声明的 IP 地址等信息是固定的，Service 服务的主要作用就是作为 Pod 的代理入口（Portal），从 而代替 Pod 对外暴露一个固定的网络地址。 这样，对于 Web 应用的 Pod 来说，它需要关心的就是数据库 Pod 的 Service 信息，而Service 后端真正代理的 Pod 的 IP 地址、端口等信息的自动更新、维护，则是 Kubernetes 的职责。
Deployment：Pod多实例管理器，能一次启动多个应用的实例
容器的形态
Secret：是一个保存在 Etcd 里的键值对数据。把 Credential（数据库的用户名和密码）信息以 Secret 的方式存在 Etcd 里，Kubernetes 就会在指定的 Pod启动时，自动把 Secret 里的数据以 Volume 的方式挂载到容器里
Job：基于 Pod 改进后的对象，用来描述一次性运行的 Pod（比如，大数据任务）
DaemonSet：用来描述每个宿主机上必须且只能运行一个副本 的守护进程服务
Cronjob：用于描述定时任务
与Linux对比：（图源《趣谈Linux》）
Kubernetes 推荐的使用方式，是用一个 YAML 文件来描述你所要部署的 API 对象。然 后，统一使用 kubectl apply 命令完成对这个对象的创建和更新操作
Kubernetes API 对象往往由 Metadata 和 Spec 两部分组成；
Metadata 的字段是 API 对象 的“标识”，即元数据，也是从 Kubernetes 里找到这个对象的主要依据，其中最主要 用到的字段是 Labels，是一组 key-value 格式的标签，而像 Deployment 这样的控制器对象，就可以通过这个 Labels 字段从 Kubernetes 中过滤出它所关心的被控制对象；
Spec存放属于这个对象独有的定义，用来描述它所要表达的功能，比如容器想要使用的数据卷Volume
本文地址：https://blog.csdn.net/qq_41594698/article/details/107158363
如对本文有疑问， 点击进行留言回复！！
【HDFS篇14】HA高可用 --- Federation架构设
gitea宝塔插件 GiteaForBt 宝塔git社区服务器插件比gitlab更轻量的gitea插件
我要评论
网友评论