k8s 中的重要概念总结-抽出重点
1.k8s 的常见资源类型
1)Namespace 命名空间资源
概述：k8s 实现了多租户的资源隔离，通过将集群内部的资源对象分配到不同的 namespace 中，形成逻辑上分组，便于区分管理，可以针对每个
namespace 做资源配额。
举例：两个用户 tom 和 jim 都要创建一个 test01 的任务，如果都在在同一个 namespace（命名空间）中创建 test01，因为名字相同，则就会有影
响，甚至没法创建，可创建两个 namespace，在两个 namespace 中分别创建 test01 任务，这样任务就隔离开来，两个任务就不会互相影响了。
常见的 pod，service,replication controller(RC)和 deployment 等都是属于某一个 namespace 的（默认是 default）,而 nodes,persistent volume，
namespace 等资源则不属于任何 namespace。
默认 k8s 安装完成后，有 3 个命名空间：default，kube-public，kube-system
default: 若创建资源时候没有指定命名空间，默认会放在 default 名空间里。
kube-public： 此命名空间下的资源可以被所有人访问(包括未认证用户)
kube-system： 所有由 kubernetes 系统创建的资源都处于这个命名空间
2)Pod 资源：(Pod 不会被重启，不会被停止,但 Pod 里的容器可以重启，可以停止)——一般不会直接创建 Pod
Pod: 是 k8s 最小的管理单元，一个 pod 可以封装一个容器或多个容器。
Pod 内部容器是共享网络空间的，pod 封装多个容器可以使用 localthost 访问其他容器，k8s 在启动容器的时候会先启动一个 pause 容器，这个容
器就是实现这个功能的。因为 pod 的生命周期是短暂的，实际工作中不会直接创建 pod。
3)Deployment 和 ReplicaSet(RS)资源（都是用来控制管理 Pod 资源的，Pod 删除后,会自动创建新的 Pod,控制副本数量在定义的数量）
RS 和 Deployment 联系和区别：（一般使用 Deployment 资源）
a)这两个资源类型都是用来控制管理 Pod 的，当 Pod 删除后，能自动重建 Pod。
b)Deployment 相当于 RS 的一次升级，是运行在 RS 之上，比 RS 拥有更完善的功能。创建 Deployment 之后会同时有 RS，因为 Deployment 是运行在
RS 之上。
c)重要区别：金丝雀的人为升级和自动滚动升级。
RS 不能进行滚动升级，需要人为干预，修改镜像后，需手动删除 Pod 才能创建新的 Pod.而且还不能智能的回滚，只能手动修改成原来镜像后，再
手动删除 pod，才能回滚。RS 也不是没有好处，当处于测试阶段时候，可以手动控制升级,同时新老版本都存在，当确定新版本没问题后，再手动
删除老版本的 pod。
Deployment 可以自动实现滚动升级，修改镜像后，可以自动的删除 Pod，然后创建新的 Pod，不需要人为干预。而且还能智能回滚。
Deployment 继承了上线部署，滚动升级，创建副本，回滚到以前版本的 Deployment 等功能。有默认的更新策略：不是一次性的全部更新 pod，而
是一部分一部分的更新 pod，更新策略默认是： strategy: rollingUpdate（一般选择这个策略），rollingUpdate 这个策略下面又有两参数：maxSurge
和 maxUnavailable，即：设置一次更新几个 pod 和设置不可用的 pod 最多有几个,一般默认：maxSurge： 1,maxUnavailable：1，,可以设置为：
maxSurge： 1,maxUnavailable：0，默认是一个一个更新。也可自定义成一次更新多个 pod。更新策略可以保持默认，不写入 yaml 文件。
ReplicaSet： 支持新的基于集合的 selector,Replicaset 在继承 pod 的所有特性的同时，它可以利用预先创建的模板定义副本数量并自动控制。
Deployment:使用了 ReplicaSet，是更高一层的概念。除非需要自定义升级功能或者根本不需要升级 pod，否则是建议使用 Deployment 而不直接使
用 ReplicaSet。
4)DaemonSet 资源: 能够让所有（或者特定）的节点运行同一个 pod.（也会保证每个 node 运行一个 pod 的副本数，当删除了某个节点的 pod，会重
新创建一个新的 pod 运行到该节点上） 特点：跟 RS 一样，更新镜像后不会自动更新，需手动删除 pod 后才能更新 pod
DaemonSet 能够让所有（或者特定）的节点运行同一个 pod.一般应用于日志收集，监控采集，分布式存储守护进程，ingress 等。
当节点加入到 K8s 集群中，pod 会被（DaemonSet）调度到该节点上运行。当节点从 k8s 集群中被移除，被 DaemonSet 调度的 pod 会被移除。如果删
除 DaemonSet，所有跟这个 DaemonSet 相关的 pods 都会被删除。如果一个 DaemonSet 的 pod 被杀死、停止或者崩溃，那么 DaemonSet 将会重新创建
一个新的副本在这台计算节点上。
DaemonSet 不需要指定副本数量 replicas，它会在所有节点上默认运行一个 pod.
在使用 kubernetes 来运行应用时，很多时候我们需要在一个区域（zone）或者所有 Node 上运行同一个守护进程（pod），
使用场景：
每个 Node 上运行一个分布式存储的守护进程，例如 glusterd，ceph
每个 Node 上运行日志采集器，例如 fluentd，logstash
每个 Node 上运行监控的采集端，例如 Prometheus Node Exporter, collectd 等
5)Service 资源对象：
之前面临的问题：
0)Pod 是可能会被重建的：a）如果 pod 使用了 livenessprobe，当检测失败，pod 会被重建,b)当 pod 所在的 node 有问题，也会被重建。C）更新也
会重建 pod
1)Pod 的 ip 不固定，容器扩容缩容 ip 地址会改变。
2)集群外如何访问集群内 pod
Service 概念作用：
把 POD 与 POD 之间的通信，改成 POD 和 Service 之间的通信。或者改成 Service 和 Service 之间的通信，Service 的 IP,不会因为 pod 的重建而发
生变化，除非 Service 重建，而 Service 重建是需要人为干预的。
Service 做的事情：
当有一个请求，目的 IP 是 Service IP 的时候,Service 能把这个请求调度到这个 Service 所关联的 pod 上。
实现方式： a) iptables(主要实现方式) nat 表中 postrouting b)ipvs （新型的调度方式）
Service 后的 EndPoint ip1 ip2 ip3： 这个 Service 所关联的 POD 的 IP 列表。Service 会动态维护这个 IP 列表。当 POD 重建,ip 变化时候，Service
会更新 pod 的 ip 列表。附带了负载均衡的效果。
Service 关联 POD 的方式：
通过标签选择器：selector 来关联 POD
如何访问 Service:
1)通过 service IP
2)通过域名。从来没有搭建过 DNS 服务器，哪里来的 DNS 解析,搭建 k8s 集群时候，就已经创建了 dns 的 pod，core-dns 的 pod.
core-dns 有自己的两个 pod，也有自己的 core-dns 的 service.
当你新建一个 service 时候，他会给你这个 service 分配一个域名。
Service 的 3 种类型：
ClusterIP（默认类型）： 自动分配一个仅 cluster 内部可以访问的虚拟 ip，常用于内部程序互相的访问。
NodePort: 在 ClusterIP 基础上为 Service 在每台机器上绑定一个端口，这样就可以通过 NodeIP:NodePort 来访问服务。NodePort 方式暴露服务的
端口默认范围（30000-32767），如果需要修改，则在 apiserver 的启动命令里添加如下参数: --service-node-port=1-65535
LoadBalancer:使用支持外部负载均衡器的云提供商的服务。
参数介绍：
1)targetport: 是 pod 上的端口，从 port 和 nodeport 上来的数据最终经过 kube-proxy 流入到后端 pod 的 target 上进入容器。
2)port: service 暴露在 cluster ip 上的端口，是提供给集群内部客户端访问 service 的入口。
创建 service 对象的两种方式（命令行方式和 yaml 文件）
6)Ingress 资源对象(也是一种控制器,是一个 pod，作为负载均衡器，负载均衡器可以是 nginx，haproxy 等种类)：
Ingress 的作用： 就是作为一个负载均衡器，外部可以通过访问这个负载均衡器(也是一个 POD)，来调度访问到后端的应用 POD。
Ingress 的本质就是一个负载均衡器，只不过负载均衡器的种类很多：可以是 nginx，也可以是 haproxy，等等。且负载均衡器能自动的添加后端的
pod 或删除 pod，根据后端变化动态维护 pod.
注意;Ingress 后端不是直接关联 POD 的，而是关联 Service 的，然后再通过 Service 关联到 POD.
Ingress 也是一个 POD,可以通过 POD 控制器来创建，可以用：Deployment/DaemonSet/ReplicaSet 等控制器来创建 Ingress，但不建议用 ReplicaSet
来创建。
Ingress-controller 也是 pod，如果对该 pod 操作？有下面两种方案：
1)给这个 pod 创建 service
2)将这个 pod 和所在 node 节点机器，做 pod 和宿主机的端口映射，通过访问宿主机的端口来访问该 pod（此处选择该方案）
Ingress 所有相关 yaml 文件地址：
https://github.com/kubernetes/ingress-nginx/tree/master/deploy/static
综合的 yaml 地址：
https://github.com/kubernetes/ingress-nginx/blob/master/deploy/static/mandatory.yaml
