一、服务的分类(无状态&有状态)
1.1.无状态（不依赖本地服务器环境）
代表服务：nginx、Apache
优点：对客户端透明，无依赖关系，可以高效实现扩容、迁移
缺点：不能存储数据，需要额外的数据服务支撑
1.2.有状态（依赖本地服务器环境，需要数据迁移）
代表服务：MySQL、Redis
优点：可以独立存储数据，实现数据管理
缺点：集群环境下需要实现主从、数据同步、备份、水平扩容复杂
二、对象的规约和状态
2.1.对象规约 Spec
spec 是规约，规格的意思，spec是必需的，它描述了对象的期望状态——希望对象所具有的特征。当创建Kubernetes对象时，必须提供对象的规约，用来描述该对象的期望状态，以及关于对象的一些基本信息。
2.2.状态 Status
状态(status)属性由 k8s 自己维护，k8s 会通过一系列的控制器对对应对象进行管理，让对象尽可能的让实际状态与期望状态(spec)重合。
三、资源和对象
3.1.资源的分类
3.1.1.元数据类型：
（1）Horizontal Pod Autoscaler（HPA）：Pod 自动扩容，可以根据 CPU 使用率或自定义指标metrics 自动对 Pod 进行扩/缩容，方便我们进行弹性伸缩。
（2）Pod Template ：是关于 Pod 的定义，控制器通过 Pod Template 信息来创建 Pod，通过定义模版来进行弹性伸缩。
（3）LimitRange：可以对集群内 Request 和 Limits 的配置做一个全局的统一的限制，相当于批量设置了某一个范围内（某个命名空间）的 Pod 的资源使用限制。
3.1.2.集群级别
（1）Namespace命名空间
（2）Node节点资源：Node本质上不是k8s 来创建的，k8s只是管理 Node 上的资源。虽然可以通过 Manifest创建一个Node对象，但Kubernetes 也只是去检查是否真的是有这么一个 Node，如果检查失败，也不会往上调度Pod。
（3）ClusterRoles声明权限组：用于鉴权，用于对集群的角色进行管理。
（4）ClusterRoleBinding对集群级别进行绑定：角色的绑定只能用于集群级别的资源。
3.1.3.命名空间级别
（1）Pod（容器组）： Kubernetes 中最小的可部署单元。一个 Pod（容器组）包含了一个应用程序容器（某些情况下是多个容器）、存储资源、一个唯一的网络 IP 地址、以及一些确定容器该如何运行的选项。Pod 容器组代表了 Kubernetes 中一个独立的应用程序运行实例，该实例可能由单个容器或者几个紧耦合在一起的容器组成。一个 Pod 中只运行一个容器。“one-container-per-pod” 是 Kubernetes 中最常见的使用方式。此时，您可以认为 Pod 容器组是该容器的 wrapper，Kubernetes 通过 Pod 管理容器，而不是直接管理容器。
（2）副本(replicas)：一个 Pod 可以被复制成多份，每一份可被称之为一个“副本”，这些“副本”除了一些描述性的信息（Pod 的名字、uid 等）不一样以外，其它信息都是一样的，譬如 Pod 内部的容器、容器数量、容器里面运行的应用等的这些信息都是一样的，这些副本提供同样的功能。Pod 的***“控制器”***通常包含一个名为 “replicas” 的属性。“replicas”属性则指定了特定 Pod 的副本的数量，当当前集群中该 Pod 的数量与该属性指定的值不一致时，k8s 会采取一些策略去使得当前状态满足配置的要求。
（3）控制器：当 Pod 被创建出来，Pod 会被调度到集群中的节点上运行，Pod 会在该节点上一直保持运行状态，直到进程终止、Pod 对象被删除、Pod 因节点资源不足而被驱逐或者节点失效为止。Pod 并不会自愈，当节点失效，或者调度 Pod 的这一操作失败了，Pod 就该被删除。如此，单单用 Pod 来部署应用，是不稳定不安全的。Kubernetes 使用更高级的资源对象 “控制器” 来实现对Pod的管理。控制器可以为您创建和管理多个 Pod，管理副本和上线，并在集群范围内提供自修复能力。 例如，如果一个节点失败，控制器可以在不同的节点上调度一样的替身来自动替换Pod。
四、Pod控制器的分类
4.1.适用无状态服务
（1）ReplicationController（帮助我们动态的更新副本数量）
如果实际 Pod 数量比指定的多那就结束掉多余的，如果实际数量比指定的少就新启动一些Pod，当 Pod 失败、被删除或者挂掉后，RC 都会去自动创建新的 Pod 来保证副本数量，所以即使只有一个 Pod，我们也应该使用 RC 来管理我们的 Pod。可以说，通过 ReplicationController，Kubernetes 实现了 Pod 的高可用性，已被RS替换。
（2）ReplicaSet（帮助我们动态更新副本数，可以通过指定selector来选择对哪些Pod生效）
label 标签是附加到 Pods上的键值对，用于区分对象Pod。 label 可以用于组织和选择对象的子集。在创建时附加到对象上，随后可以随时添加和修改。使用 label 来获取某类对象，同时 label 可以与 selector 一起配合使用，用表达式对条件加以限制，实现更精确、更灵活的资源查找。label 与 selector 配合，可以实现对象的“关联”，“Pod 控制器” 与 Pod 是相关联的 —— “Pod 控制器”依赖于 Pod，可以给 Pod 设置 label，然后给“控制器”设置对应的 selector，这就实现了对象的关联。此外，我们还可以通过 label 和 selector 实现依据指定的Pod来进行扩容和缩容。
（3）Deployment（对RS做了进一步封装）
Deployment controller 就会帮你将 Pod 和 Replica Set 的实际状态改变到你的目标状态。
1.创建 Replica Set / Pod
2.滚动升级/回滚 -> 升级后的RS1会保留着，用于回滚
3.平滑扩容和缩容,本质上还是基于ReplicaSet 来实现扩缩容
4.暂停与恢复 Deployment，由于升级回滚，是自动的 -> 可以利用暂停与恢复，文件修改之前令
其暂停，等我们文件修改完毕在恢复。
4.2.使用有状态服务（StatefulSet）
有状态服务特点：稳定的持久化存储、稳定的网络状态、有序部署有序扩展、有序收缩有序删除；
4.2.1.StatefulSet的组成
Headless Service
用于定义网络标志DNS，将域名与 ip 绑定映射关系，服务名 => 访问路径（域名） => ip
StatefulSet 中每个 Pod 的 DNS 格式为：
statefulSetName-{0..N-1}.serviceName.namespace.svc.cluster.local
（1）serviceName 为 Headless Service 的名字
（2）0…N-1 为 Pod 所在的序号，从 0 开始到 N-1
（3）statefulSetName 为 StatefulSet 的名字
（4）namespace 为服务所在的 namespace，Headless Service 和 StatefulSet 必须在相同的 namespace
（5）.cluster.local 为 Cluster Domain
VolumeClaimTemplate
用于创建持久化卷的模版
4.3.DaemonSet （为每一个匹配的Node都部署一个守护进程）
DaemonSet 保证在每个 Node 上都运行一个容器副本，常用来部署一些集群的日志、监控或者其他系统管理应用。
典型的应用包括：
（1）日志收集，比如 fluentd，logstash 等
（2）系统监控，比如 Prometheus Node Exporter，collectd，Ganglia gmond 等
（3）系统程序，比如 kube-proxy, kube-dns, glusterd, ceph 等
4.4.Job和CronJob
Job：一次性任务，运行完成后Pod销毁，不再重新启动新容器。
CronJob：CronJob 是在 Job 基础上加上了定时功能，周期性执行。
五、服务发现
5.1.Service 集群内部通信，横向流量(东西流量)
“Service” 简写 “svc”。Pod 不能直接提供给外网访问，而是应该使用 service。Service 就是把 Pod 暴露出来提供服务，Service 才是真正的“服务”， 是一个应用服务的抽象，定义了 Pod 逻辑集合和访问这个 Pod 集合的策略。Service 代理 Pod 集合，对外表现为一个访问入口，访问该入口的请求将经过负载均衡，转发到后端 Pod 中的容器。
5.2.Ingress 纵向流量(南北流量)
Ingress 提供外网访问 Service 的能力。可以把某个请求地址映射、路由到特定的 service。ingress 需要配合 ingress controller 一起使用才能发挥作用，只是相当于路由规则的集合而已，真正实现路由功能的，是 Ingress Controller，ingress controller 和其它 k8s 组件一样，也是在 Pod 中运行
六、存储
6.1.Volume
数据卷，共享 Pod 中容器使用的数据。用来放持久化的数据，比如数据库数据。
6.2.CSI
Container Storage Interface 是由来自 Kubernetes、Mesos、Docker 等社区成员联合制定的一个行业标准接口规范，旨在将任意存储系统暴露给容器化应用程序。CSI 规范定义了存储提供商实现 CSI 兼容的 Volume Plugin 的最小操作集和部署建议。CSI 规范的主要焦点是声明 Volume Plugin 必须实现的接口。
七、特殊类型配置
（1）ConfigMap：使用key-value 键值对用来放配置，与 Secret 是类似的，只是 ConfigMap 放的是明文的数据，Secret 是密文存放。
（2）Secret：Secret 解决了密码、token、密钥等敏感数据的配置问题，而不需要把这些敏感数据暴露到镜像或者 Pod Spec 中。Secret 可以以 Volume 或者环境变量的方式使用。
（3）downwardAPI 这个模式和其他模式不一样的地方在于它不是为了存放容器的数据也不是用来进行容器和宿主机的数据交换的，而是让 pod 里的容器能够直接获取到这个 pod 对象本身的一些信息。
7.2.Secret 有三种类型：
1、Service Account：用来访问 Kubernetes API，由 Kubernetes 自动创建，并且会自动挂载到 Pod 的 /run/secrets/kubernetes.io/serviceaccount 目录中；
2、Opaque：base64 编码格式的 Secret，用来存储密码、密钥等；
kubernetes.io/dockerconfigjson：用来存储私有 docker registry 的认证信息。
3、DownwardAPI(将pod的信息共享搭配容器内)
7.3.downwardAPI 提供了两种方式用于将 pod 的信息注入到容器内部
（1）环境变量：用于单个变量，可以将 pod 信息和容器信息直接注入容器内部
（2）volume 挂载：将 pod 信息生成为文件，直接挂载到容器内部中去
八、权限
（1）Role：Role 是一组权限的集合，例如 Role 可以包含列出 Pod 权限及列出 Deployment权
限，Role 用于给某个 Namespace 中的资源进行鉴权。
（2）RoleBinding：将 Subject 绑定到 Role，RoleBinding 使规则在命名空间内生效。