简述pod概念和服务发现_服务pod

pod类型（非官方概念）

自主式 Pod

也叫作静态pod，这个就是不被控制器管理的pod，它一旦死亡，就没有人会去管理它了，也不会有人去创建一个新的期望值去满足我们的需求。

控制器管理的 Pod

（下面的都是围绕控制器管理的pod来讲的）

在我们的传统容器概念中，每一个容器都要自己对应的IP地址，都是独立存在的，通过我们的名字空间进行隔离等等，但在进行k8s移植的时候，就不是那么的容易了

但是k8s给我们实现了解决办法，那就是提出pod的概念，我们先定义一个pod，它会先启动第一个容器，这个容器的特点就是只要我们运行容器（只要有pod），就会启动这个容器，这个容器叫做pause，我们的容器中可能有多个pod（下图以两个为例，一个PHP，一个NGINX），这两个pod没有自己的独立的IP地址，他们有的只是pause的或者是它两外部的pod的地址，如果NGINX想要访问到PHP的话，只需要写localhost：9000即可，不需要写对方的IP地址加映射等等，原因是这两个容器共享的是pause的网络栈。

也就意味的在同一个pod里面，容器之间（下图中的Php-fpm和nginx）的端口不能重复，即PHP和NGINX的端口号不能一样，若一样的话，要么NGINX或者PHP起不来，要么无限的重启。

下图的html表示一个存储，挂载在我们的pod上面。我们的Php-fpm和nginx都想去访问我们的html存储，此时，因为Php-fpm和nginx都会共享pause的存储，而html存储和pause又是共享存储的，所以我们的容器Php-fpm和容器nginx都可以访问到html存储。

总结：还有就是在同一个pod里面，即共享网络栈，又共享存储。

 下面我们讲的是控制器（控制器的特点和管理的pod有什么特点）

ReplicationController（RC） 用来确保容器应用的副本数始终保持在用户定义的副本数，即如果

有容器异常退出，会自动创建新的 Pod 来替代（注意：新的pod跟原来的ip和端口不一样）；而如果异常多出来的容器也会自动回收。

在新版本的 Kubernetes 中建议使用 ReplicaSet 来取代 ReplicationControlle。

1. ReplicaSet（RS） 跟 ReplicationController 没有本质的不同，只是名字不一样，并且ReplicaSet 支持集合式的 selector。（我们在创建pod的时候会打标签label，打上标签之后，我们的RS支持当满足我们的标签的时候，可以执行某个操作。

虽然 ReplicaSet 可以独立使用，但一般还是建议使用 Deployment 来自动管理ReplicaSet ，这样就无需担心跟其他机制的不兼容问题，比如 ReplicaSet 不支持rolling-update 但 Deployment 支持，rolling-update滚动更新的机制还是蛮有用的，比如说，我们的要更新一个pod：

两个旧的pod1和pod2都是v1版，我们需要更新到v2版，此时我们先创建一个v2版的pod，然后删除一个旧的pod，在生成一个v2版，再删除一个旧的。。。我们还可以回滚，即回到最初的版本。。

2. Deployment 为 Pod 和 ReplicaSet 提供了一个 声明式定义 (declarative) 方法，用来替

代以前的 ReplicationController 来方便的管理应用。典型的应用场景包括：

* * 定义 Deployment 来创建 Pod 和 ReplicaSet

* * 滚动升级和回滚应用

* * 扩容和缩容

* * 暂停和继续 Deployment

3. Horizontal Pod Autoscaling 仅适用于 Deployment 和 ReplicaSet ，在 V1 版本中仅支持根据 Pod的 CPU 利用率扩所容，在 v1alpha 版本中，支持根据内存和用户自定义的 metric

4. StatefulSet 是为了解决有状态服务的问题（对应 Deployments 和 ReplicaSets 是为无状态服务而设计），其应用场景包括：

* * 稳定的持久化存储，即 Pod 重新调度后还是能访问到相同的持久化数据，数据不会丢失，基于 PVC 来实现

* * 稳定的网络标志，即 Pod 重新调度后其 PodName 和 HostName 不变，基于 Headless Service（即没有 Cluster IP 的 Service ）来实现

* * 有序部署，有序扩展，即 Pod 是有顺序的，在部署或者扩展的时候要依据定义的顺序依次依次进行（即从 0 到 N-1 ，在下一个 Pod 运行之前所有之前的 Pod 必须都是 Running 和 Ready 状态），基于 init containers 来实现

* * 有序收缩，有序删除（即从 N-1 到 0 0 ）

5. DaemonSet  确保全部或者一些（因为我们可以在我们的node上打一些“污点”，那这些“污点”是可以不被调度的，所以在DaemonSet创建的时候，这些打了“污点”的node就不会运行pod，但是正常情况下，我们所有的node都会运行pod） Node 上运行一个 Pod 的副本。当有 Node 加入集群时，也会为他们新增一个 Pod 。当有 Node 从集群移除时，这些 Pod 也会被回收。删除DaemonSet 将会删除它创建的所有 Pod

使用 DaemonSet 的一些典型用法：

* * 运行集群存储 daemon ，例如在每个 Node 上运行 glusterd 、 ceph 。

* * 在每个 Node 上运行日志收集 daemon ，例如 fluentd 、 logstash 。

* * 在每个 Node 上运行监控 daemon ，例如 Prometheus Node Exporter

（也就意味着，我们只要我们有需求，每一个node都需要运行一个守护进程去帮我们干某些事情，DaemonSet是一个很好的选择）

6. Job 负责批处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个 Pod 成功结束

7. Cron Job    管理基于时间的 Job ，即：

* * 在给定时间点只运行一次

* * 周期性地在给定时间点运行

比如说我们想要备份一下我们的数据库，那备份代码我们完全可以放在一个pod里面去运行，那我们再把它放到job里面去执行一下，那么这个代码脚本就可把我们的数据库备份出来。虽然可以在我们的Linux系统直接运行备份脚本，但是我们封装的这个pod是可以重复利用的，这是好处之一。之二是如果我们的脚本意外退出的话，在Linux下是没办法重复执行的，但我们的job有一种机制可以判断我们的这个脚本若不是正常退出的话，那么就重新执行一遍脚本，直到正常退出为止，并且我们还可以设置正常退出的次数，比如说，正常退出两次，我们的job才算运行成功。

服务发现

比如说我们的客户端想要访问一组pod，如果这些pod不相关的话，是不可以通过我们的service统一代理的，相关性的就是，比如说是我们同一个RS或者RC或者Deployment 创建的，或者拥有同一组标签，就可以被我们的server所收集到。。。。也就是说我们的service去收集这些pod是通过我们的标签去选择到，选择到之后我们service会有自己的ip和端口，我们的客户端就可以通过访问service的ip和端口，间接的访问到我们的pod。访问的方式是轮询的方式，如下：

这里只是简单的有个概念，后边还会深入的了解到各个模块的原理及应用。