前言
如果你刚接触 Kubernetes ，很可能会被 Pod 、 Deployment 、 Service 这些扑面而来的术语搞得一头雾水。就像学外语要先掌握词汇，要真正用好 Kubernetes ，第一步就是理解它的核心概念 ------ 这些概念不仅是 Kubernetes 设计思想的体现，更是你编写配置、排查问题、设计架构的 "基础语法"。
很多人上手 Kubernetes 时，习惯直接照着教程跑一个 kubectl create deployment 命令，却不知道这条命令背后到底创建了什么、各个对象之间又是什么关系。结果就是遇到问题时只能到处查文档，无法从根本上理解故障原因。其实，Kubernetes 的所有操作和能力，都建立在一套清晰的对象模型和核心概念之上。
在这篇文章里，我们将抛开复杂的架构细节，从最基础的 Pod 开始，一步步梳理 Deployment 、ReplicaSet 、Service 、Namespace 、ConfigMap 、Secret 等核心概念。我们不仅会解释每个概念是什么、解决了什么问题，还会用生动的类比和场景化的例子，帮你理解它们之间如何协同工作，让你真正建立起对 Kubernetes 应用编排的全局认知。无论你是准备第一次部署应用，还是想从运维视角加深理解，这篇文章都将是你 Kubernetes 学习路上的关键一站。
服务分类
有状态
代表服务 Mysql 、Redis
优点： 可以独立存储数据，实现数据管理
缺点： 集群环境下需要实现主从、数据同步、备份、水平扩容复杂
## 无状态
代表服务 Nginx、 Apache
优点： 对客户端透明，无依赖关系，可以高效实现扩容、迁移
缺点： 不能存储数据，需要额外的数据服务支撑
资源和对象
Kubernetes 中的所有内容都被抽象为资源 ，如 Pod 、Service 、Node 等都是资源。对象 就是资源 的实例，是持久化的实体。如某个具体的 Pod 、某个具体的 Node 。Kubernetes 使用这些实体去表示整个集群的状态。
对象的创建、删除、修改都是通过 Kubernetes API ，也就是 Api Server 组件提供的 API 接口，这些是 Restful 风格的 Api ，与 k8s 的万物皆对象 理念相符。命令行工具 kubectl ，实际上也是调用 Kubernetes api。
K8s 中的资源类别有很多种，kubectl可以通过配置文件来创建这些 "对象"，配置文件更像是描述对象"属性"的文件，配置文件格式可以是 JSON 或 YAML，常用 YAML。
资源的分类
元数据型
-
Horizontal Pod Autoscaler（HPA）
Pod 自动扩容：可以根据 CPU 使用率或自定义指标（metrics）自动对 Pod 进行扩/缩容。
控制管理器每隔30s（可以通过--horizontal-pod-autoscaler-sync-period修改）查询metrics的资源使用情况
支持三种metrics类型
-- 预定义metrics（比如Pod的CPU）以利用率的方式计算
-- 自定义的Pod metrics，以原始值（raw value）的方式计算
-- 自定义的object metrics
支持两种metrics查询方式：Heapster和自定义的REST API
支持多metrics
-
PodTemplate
Pod Template 是关于 Pod 的定义，但是被包含在其他的 Kubernetes 对象中（例如 Deployment、StatefulSet、DaemonSet 等控制器）。控制器通过 Pod Template 信息来创建 Pod。
-
LimitRange
可以对集群内 Request 和 Limits 的配置做一个全局的统一的限制，相当于批量设置了某一个范围内（某个命名空间）的 Pod 的资源使用限制。
集群级
- Namespace
Kubernetes 支持多个虚拟集群，它们底层依赖于同一个物理集群，这些虚拟集群被称为命名空间。
作用是用于实现多团队/环境的资源隔离。
命名空间 namespace 是 k8s 集群级别的资源，可以给不同的用户、租户、环境或项目创建对应的命名空间。
默认 namespace：
kube-system 主要用于运行系统级资源，存放 k8s 自身的组件
kube-public 此命名空间是自动创建的，并且可供所有用户（包括未经过身份验证的用户）读取。此命名空间主要用于集群使用，关联的一些资源在集群中是可见的并且可以公开读取。此命名空间的公共方面知识一个约定，但不是非要这么要求。
default 未指定名称空间的资源就是 default，即你在创建pod 时如果没有指定 namespace，则会默认使用 default - Node
不像其他的资源（如 Pod 和 Namespace），Node 本质上不是Kubernetes 来创建的，Kubernetes 只是管理 Node 上的资源。虽然可以通过 Manifest 创建一个Node对象（如下 json 所示），但 Kubernetes 也只是去检查是否真的是有这么一个 Node，如果检查失败，也不会往上调度 Pod。 - ClusterRole
ClusterRole 是一组权限的集合，但与 Role 不同的是，ClusterRole 可以在包括所有 Namespace 和集群级别的资源或非资源类型进行鉴权 - ClusterRoleBinding
将 Subject 绑定到 ClusterRole，ClusterRoleBinding 将使规则在所有命名空间中生效。
命名空间级
- 工作负载型
- 服务发现
- 存储
- 特殊类型配置
- 其它
资源清单
创建 k8s 的对象都是通过 yaml 文件的形式进行配置的
对象的规约和状态
对象是用来完成一些任务的，是持久的，是有目的性的，因此 Kubernetes 创建一个对象后，将持续地工作以确保对象存在。当然，kubernetes 并不只是维持对象的存在这么简单，Kubernetes 还管理着对象的方方面面。每个 Kubernetes 对象包含两个嵌套的对象字段，它们负责管理对象的配置，他们分别是 spec 和 status 。
规约（Spec）
Spec 是 "规约"、"规格" 的意思，Spec 是必需的，它描述了对象的期望状态（Desired State）------ 希望对象所具有的特征。当创建 Kubernetes 对象时，必须提供对象的规约，用来描述该对象的期望状态，以及关于对象的一些基本信息（例如名称）。
状态（Status）
表示对象的实际状态，该属性由 K8s 自己维护，K8s 会通过一系列的控制器对对应对象进行管理，让对象尽可能的让实际状态与期望状态重合。