一、资源与对象

1、pod

容器都是由镜像启动的，但在容器外面会包裹通过Pod将容器包裹起来这个是K8s的概念，在这个Pod里面可以有一个或多个容器，那这个Pod的有什么特征呢

• Pod里的所有容器都会调度在同一个节点上运行0。
• Pod中的所有容器会共享同一网络，它们有一个唯一的IP，就叫PodIP;
• Pod中还有一个特殊的容器叫Pause，它会优先启动然后进行IP分e配，而后将其他容器都Link到该容器上，实现网络共享
• pod 是kubernetes的最小资源

Pod是Kubernetes中的抽象概念，也是Kubernetes中的最小部署单元。在每个Pod中至少包含一个容器或多个容器，这些容器共享Network (网络) 、PID (进程) 、IPC (进程间通信)HostName (主机名称) 、Volume (卷) 。当我们需要部署应用时，其实就是在部署Pod，Kubernetes会将Pod中所有的容器作为一个整体，由Master调度到一个Node上运行。

2、Deployment

在Pod的上一层就是ReplicaSet控制器，它主要负责管理Pod的副本数，但通常我们并不直接使用ReplicaSet，而是使用比ReplicaSet更高一级的DepLoyment。由DepLoyment管理ReplicaSet，它会自动帮我们创建和销毁RS，有了Deployment就可以实现应用的滚动更新。
ReplicaSet是副本控制器

[root@master ~]# kubectl  create  deployment  nginx --image=nginx --replicas=3
deployment.apps/nginx created
[root@master ~]# kubectl  get pod
NAME                     READY   STATUS    RESTARTS   AGE
nginx-85b98978db-4475f   1/1     Running   0          22m
nginx-85b98978db-5r87f   1/1     Running   0          22m
nginx-85b98978db-85wtn   1/1     Running   0          22m
[root@master ~]# kubectl  get rs
NAME               DESIRED   CURRENT   READY   AGE
nginx-85b98978db   3         3         3       22m
[root@master ~]# kubectl  get deployments.apps 
NAME    READY   UP-TO-DATE   AVAILABLE   AGE
nginx   3/3     3            3           22m

3、Service

Service，是Kubernetes用来实现Pod负载均衡的一个服务;要想实现Pod的负载均衡，首先需要通过Labels为Pod打上特定的标签，而后创建Service时使用SeLector选择对应的标签，最终通过节点的kube-proxy来完成负载均衡的规则创建

4、Namespace

在 Kubernetes 中，名字空间’(Namespace) 提供一种机制，将同-集群中的资源划分为相互隔离的组。同一名字空间内的资源名称要唯，但跨名字空间时没有这个要求

• 对资源对象进行隔离: 比如: Pod、Deployment、Service、将其划分为相互隔离的组。
• 对资源配额进行隔离: CPU，Memory ，限制某个NS的可以使用的cpu和内存;

二、 kubernetes核心资源pod

1、为什么需要Pod
有些容器关系比较紧密，必须要再一起工作。Pod提供了比容器更高层次的抽象，将它们封装到一个部署单元中进行调度，从而达到一起部署、一起管理。

pod 使用场景

场景一：

比如：日志收集：
Tomcat filebeat 收集 access.log error.log 日志信息 推送到 logging-server，一个pod有两个镜像

服务模块已经实现了一些核心的业务逻辑，并且稳定运行了一段时间，日志记录在了某个目录下，按照不同类别分别为 error.togaccess.Tog，现在希望收集这些日志并发送到统一的日志处理服务器上。
这时我们可以修改原来的服务模块，在其中添加日志收集、发送的服务但这样可能会影响原来服务的配置、部署方式，从而带来不必要的问题和成本，也会增加业务逻辑和基础服务的藕合度
如果使用Pod的方式，通过简单的编排，既可以保持原有服务逻辑、部署方式不变，又可以增加新的日志收集服务。而且如果我们对所有服务的日志生成有一个统一的标准，或者仅对日志收集服务稍加修改，就可以将日志收集服务和其他服务进行Pod编排，提供统一、标准的日志收集方式。

场景二：

提供ssh、ftp访问容器数据的能力
Docker Hub或者很多第三方的镜像并没有安装sshd的服务，不方便我们进入容器进行配置、代码的修改、调试，很多时候需要重新构建镜像或者在镜像基础上安装sshd的服务，这都需要时间和一定的学习成本
而通过Pod的方式，我们就可以将现有镜像和一个ssh、ftp镜像进行编排，获得操作容器内数据的能力。

场景三：

适配不同IaaS平台的环境

比如开发了一个节点管理agent程序，这个agent需要读取当前部署环境的一些信息，可以通过底层平台的API实现。但是，当部署到AWS、阿里云、青云等不同平台时，API就无法统一了。
但是我们可以运行一个适配各平台的服务用来获取不同平台的相关信息然后通过Pod编排部署，在不改变agent逻辑的情况下，通过服务组合来适配于不同平台。

场景四：

一个Nginx容器用来发布软件，另一个容器专门用来从源仓库做同步，这两个容器的镜像不太可能是一个团队开发的，但是他们一块儿工作才能提供一个微服务;所以需要将这些位于同一Pod内的容器形成单个服务对外提供，一个容器将共享卷获取的数据提供给用户， 而另一个容器 (边车sidecar) 则不断更新文件到共享卷中来
通过这种方式，就可以将来自不同团队的容器镜像，在部署的时候组合成一个微服务对外提供服务。

但是在kubernetes新版本中，可以通过pod的编排进行解决，可以不通过修改代码进行解决

场景五：

pod 共享网络：

在Docker中，如果 tomcat 容器想与 mysgl容器进行共享，需要先启动mysql容器，然后tomcat容器通过 --net=db:mysgl选项即可和mysql共享网络，这也就意味着我们必须先运行mysql，后运行tomcat，才可以实现共享网络。
在Kubernetes中，Pod的网络共享和Docker的网络共享实现方式一致只不过在启动Pod时，会先启动一个 pause的容器，然后将后续的所有容器都 --Tink到这个 pause的容器࿰