目录

Pod

1. Pod控制器

1. Deployment

2. ReplicaSet

3. Daemonset

4. Statefulset

5. Job

6. Cronjob

2. Label标签

3. Label  selector标签选择器

4. Service

5. Ingress

6. name

7. namespace

---

Kubernetes 包含多种类型的资源对象：Pod、Label、Service、Replication Controller 等。

所有的资源对象都可以通过 Kubernetes 提供的 kubectl 工具进行增、删、改、查等操作，并将其保存在 etcd 中持久化存储。

Kubernets其实是一个高度自动化的资源控制系统，通过跟踪对比etcd存储里保存的资源期望状态与当前环境中的实际资源状态的差异，来实现自动控制和自动纠错等高级功能。

Pod

Pod：由一个或多个容器组成​

1. 一个Pod代表正在运行的一个进程，一个Pod里可以运行多个容器，又叫边车模式（SideCar）【类似自行车前面的篮子】
2. 只有一个Pod之间的容器，可以通过localhost互相访问，并可以挂载Pod内数据卷

1. Pod控制器

Pod控制器是Pod启动的一种模板，用来保证用户的期望值​

Pod 控制器是 Pod 启动的一种模版，用来保证在K8S里启动的 Pod 应始终按照用户的预期运行（副本数、生命周期、健康状态检查等）。

1. Deployment

无状态应用部署（没有变化的），管理和控制Pod和ReplicaSet，管控他们运行在用户的期望值中

2. ReplicaSet

管理Pod；但是ReplicaSet受控于yuDeploment

可以理解成 Deployment 就是总包工头，主要负责监督底下的工人 Pod 干活，确保每时每刻有用户要求数量的 Pod 在工作。如果一旦发现某个工人 Pod 不行了，就赶紧新拉一个 Pod 过来替换它。而ReplicaSet 就是总包工头手下的小包工头。
从 K8S 使用者角度来看，用户会直接操作 Deployment 部署服务，而当 Deployment 被部署的时候，K8S 会自动生成要求的 ReplicaSet 和 Pod。用户只需要关心 Deployment 而不操心 ReplicaSet。
资源对象 Replication Controller 是 ReplicaSet 的前身，官方推荐用 Deployment 取代 Replication Controller 来部署服务。

3. Daemonset

当我们需要3台nginx时，只需要创建一台，然后会复制（不是真的复制，只是类似）两台nginx到其他主机上

4. Statefulset

有状态应用部署（有变化的）

5. Job

一次性任务，任务完成后，就退出了

6. Cronjob

周期性计划性任务

2. Label标签

通过Label标签，来获取节点、Pod、服务

一个 Label 是一个 key-value 的键值对，其中 key 与 value 由用户自己指定。
一个资源对象可以定义任意数量的Label，同一个Label 也可以被添加到任意数量的资源对象中，也可以在对象创建后动态添加或者删除。
可以通过给指定的资源对象捆绑一个或多个不同的 Label，来实现多维度的资源分组管理功能。

与 Label 类似的，还有 Annotation（注释）。
区别在于有效的标签值必须为63个字符或更少，并且必须为空或以字母数字字符（[a-z0-9A-Z]）开头和结尾，中间可以包含横杠（-）、下划线（_）、点（.）和字母或数字。注释值则没有字符长度限制。

3. Label  selector标签选择器

来选择相应的标签，根据标签，会把服务分布发送到各个Pod上

4. Service

相当于一个负载均衡器；只能进行四层调度

在K8S的集群里，虽然每个Pod会被分配一个单独的IP地址，但由于Pod是有生命周期的（它们可以被创建，而且销毁之后不会再启动），随时可能会因为业务的变更，导致这个 IP 地址也会随着 Pod 的销毁而消失。

Service 就是用来解决这个问题的核心概念。
K8S 中的 Service 并不是我们常说的“服务”的含义，而更像是网关层，可以看作一组提供相同服务的Pod的对外访问接口、流量均衡器。
Service 作用于哪些 Pod 是通过标签选择器来定义的。
在 K8S 集群中，Service 可以看作一组提供相同服务的 Pod 的对外访问接口。客户端需要访问的服务就是 Service 对象。每个 Service 都有一个固定的虚拟 ip（这个 ip 也被称为 Cluster IP），自动并且动态地绑定后端的 Pod，所有的网络请求直接访问 Service 的虚拟 ip，Service 会自动向后端做转发。
Service 除了提供稳定的对外访问方式之外，还能起到负载均衡（Load Balance）的功能，自动把请求流量分布到后端所有的服务上，Service 可以做到对客户透明地进行水平扩展（scale）。
而实现 service 这一功能的关键，就是 kube-proxy。kube-proxy 运行在每个节点上，监听 API Server 中服务对象的变化， 可通过以下三种流量调度模式： userspace（废弃）、iptables（濒临废弃）、ipvs（推荐，性能最好）来实现网络的转发。

Service 是 K8S 服务的核心，屏蔽了服务细节，统一对外暴露服务接口，真正做到了“微服务”。比如我们的一个服务 A，部署了 3 个副本，也就是 3 个 Pod； 对于用户来说，只需要关注一个 Service 的入口就可以，而不需要操心究竟应该请求哪一个 Pod。
优势非常明显：一方面外部用户不需要感知因为 Pod 上服务的意外崩溃、K8S 重新拉起 Pod 而造成的 IP 变更， 外部用户也不需要感知因升级、变更服务带来的 Pod 替换而造成的 IP 变化。

5. Ingress

K8S的接入层，负责集群内外通讯，工作在应用层

Service 主要负责 K8S 集群内部的网络拓扑，那么集群外部怎么访问集群内部呢？这个时候就需要 Ingress 了。Ingress 是整个 K8S 集群的接入层，负责集群内外通讯。
Ingress 是 K8S 集群里工作在 OSI 网络参考模型下，第7层的应用，对外暴露的接囗，典型的访问方式是 http/https。
Service 只能进行第四层的流量调度，表现形式是 ip+port。Ingress 则可以调度不同业务域、不同URL访问路径的业务流量。
比如：客户端请求 http://www.kgc.com:port —> Ingress —> Service —> Pod

6. name

每个资源都有自己的名字

由于 K8S 内部，使用 “资源” 来定义每一种逻辑概念（功能），所以每种 “资源”，都应该有自己的 “名称”。
“资源” 有 api 版本（apiversion）、类别（kind）、元数据（metadata）、定义清单（spec）、状态（status）等配置信息。
“名称” 通常定义在 “资源” 的 “元数据” 信息里。在同一个 namespace 空间中必须是唯一的。

7. namespace

为了做隔离，分离项目

随着项目增多、人员增加、集群规模的扩大，需要一种能够逻辑上隔离 K8S 内各种 “资源” 的方法，这就是 Namespace。
Namespace 是为了把一个 K8S 集群划分为若干个资源不可共享的虚拟集群组而诞生的。
不同 Namespace 内的 “资源” 名称可以相同，相同 Namespace 内的同种 “资源”，“名称” 不能相同。
合理的使用 K8S 的 Namespace，可以使得集群管理员能够更好的对交付到 K8S 里的服务进行分类管理和浏览。
K8S 里默认存在的 Namespace 有：default、kube-system、kube-public 等。
查询 K8S 里特定 “资源” 要带上相应的 Namespace。

总结：k8s核心组件：

标签选择器：标签选择器 可以用来选择一组具有相同的标签的pod，service；RC、deployment和RS，使用标签选择器可以轻松地管理
各部署应用程序和其他资源
service：service是通过标签选择器关联具有对应lable（标签）的pod，再把相关的pod的ip加入到自己的endpoints中。
service再根据endpoints里的ip进行转发。
ingress：是一种API对象，用于管理k8s集群中入口流量，他为我们提供了一种统一的方式来管理不同的服务方式
的路由规则和负载均衡。
name：通常是指资源的对象名称。
namespace：k8s中的namespace是一种虚拟化的技术，他将一个物理的k8s集群划分多个虚拟集群，每个虚拟化集群都有自己的资源和对象，不同的虚拟集群相互隔离。