1.Node

其实在我们使用k8s get no -oyaml node1这样的命令时，会看到apiVersion和kind，这两个就是metaData，kind会是node，它的apiVersion是v1，其实这个v1前面应该还有group的信息，但是因为node是core group，所以它的group在K8S里面是空，其他的group一般会有group名字斜杠v1去代表。
CIDR其实是节点的subnet，也就是这个节点上的pod，能用哪个子网去分IP。

2.Namespace

假设集群中有20W个Pod，属于1万个应用，可能每个应用我都创建一个Namespace，也就是创建出了一个个的虚拟目录。那么接下来就可以把这些对象装在这些namespace里面，那么当我去操作这些对象的时候，我能知道我要去看哪个业务的对象或者哪个部门的对象，我就可以去看对应的namespace。

3.Pod

3.1 如何通过Pod对象定义支撑应用运行

4.存储卷

5.Pod网络

当一个Pod里面有多个容器的时候，它们是共享同一个网络namespace的

6.资源限制

7.健康检查

8.ConfigMap

9.秘钥对象（Secret）

10.用户&服务账户

当我们去建立namespace的时候，比如说建立了default namespace，那么在每个namespace里面，它会去创建一个对象，叫做Service Account（比如defulat的service account)，k8s会自动为每一个namespace，创建一个service account,这个service account会对应一个Secret，所以也就是在当前的namespace下面，会有一个secret，这个secret会有namespace的名字。
ServiceAccount的作用：K8S在启动Pod的时候，它会默认地为这个pod分配一个service account，并且会把service account对应的secret mount到这个pod里面，在pod里面想要去跟api Server通信的时候，你就可以读取它mount进来的service account所对应secret里面的token和ca，并且以这个token的身份去跟apiServer通信。

11.Service

每个集群的节点上面，有一个kube-proxy的对象，这个对象会来watch service的变化，并且去配置负载均衡，当我们每创建一个Service，默认情况下，他就会为这个service创建一个分配一个cluster IP,我们接下来就可以通过cluster IP去访问这个服务了。Service是怎么跟Nginx的pod产生关系的呢，service里面有一个selector，selector中有一个run 等于pod label。

12.Service Spec

13.副本集

14.Deployment

Deployment创建的时候，它会继续计算当前的pod模板的hash，并且根据这个hash创建一个replicaSet，并且按照replica的数量去设置这个副本集里面需要多少个副本。如果我们做应用升级，就会导致hash发生变化，deployment controller会根据这个hash值创建新的deployment Set，接下来会逐渐让新的replicaSet慢慢涨副本，老的慢慢降副本，以此完成滚动升级。
Deployment用于控制无状态的应用副本。