一、 概念篇

1. 请简单描述下K8S中Pod和Container的关系。

云计算系统的操作系统是 k8s ，container就相当于是其进程，而 Pod 则是进程组。

在 Kubernetes 项目里，Pod 的实现需要使用一个中间容器，这个容器叫作 Infra 容器。在这个 Pod 中，Infra 容器永远都是第一个被创建的容器，而其他用户定义的容器，则通过 Join Network Namespace 的方式，与 Infra 容器关联在一起。

这个 Pod 里有两个用户容器 A 和 B，还有一个 Infra 容器。很容易理解，在 Kubernetes 项目里，Infra 容器一定要占用极少的资源，所以它使用的是一个非常特殊的镜像，叫作：k8s.gcr.io/pause。这个镜像是一个用汇编语言编写的、永远处于“暂停”状态的容器，解压后的大小也只有 100~200 KB 左右。

「 Pod 实际上是在扮演传统基础设施里"虚拟机"的角色；而容器则是这个虚拟机里的应用程序」。要完成传统基于虚拟机的应用到微服务架构的迁移，核心思想是：分析应用组成（组件、进程），将其拆分成松耦合的容器（以容器镜像方式分发），利用 Init Container 来解决顺序和依赖关系。

2. 请简单描述下Pod和Deployment的关系。

Pod被ReplicaSet管理，ReplicaSet控制pod的数量；ReplicaSet被Deployment管理，Deployment控制pod应用的升级、回滚，当然也能控制pod的数量。Service提供一个统一固定入口，负责将前端请求转发给Pod。

可以看出，在deployment级别上，不再受其他组件的控制，而他的状态的转变是作为API被调用而产生的。我们看到，在deployment级别上发生的事件一般是创建服务、滚动升级一个服务，或者是操作RS伸缩Pod集群。

3. Service在K8S中的含义及其作用。

service其实是在这一整套基础之上提供给外部的稳定的服务

4. 简单描述下PV、PVC、StorageClass三者之间的关系。

Kubernetes 目前主要使用 PersistentVolume、PersistentVolumeClaim、StorageClass 三个 API 对象来进行持久化存储，下面分别介绍下这三个API对象。

PV

PV 的全称是PersistentVolume（持久化卷）。PersistentVolume 是 Volume 的一种类型，是对底层存储的一种抽象。PV 由集群管理员进行创建和配置，与Node一样，PV 也是属于集群级别的资源。PV 包含存储类型、存储大小和访问模式。PV 的生命周期独立于 Pod，即使用它的Pod被 销毁时，PV 可以依然存在。

PVC

PVC 的全称是PersistentVolumeClaim（持久化卷声明），PVC 是用户对存储资源的一种请求。PVC 和 Pod 比较类似，Pod 消耗的是节点资源，PVC 消耗的是 PV 资源。Pod 可以请求 CPU 和内存，而 PVC 可以请求特定的存储空间和访问模式。对于真正使用存储的用户不需要关心底层的存储实现细节，只需要直接使用 PVC 即可。

StorageClass

由于不同的应用程序对于存储性能的要求也不尽相同，比如：读写速度、并发性能、存储大小等。如果只能通过 PVC 对 PV 进行静态申请，显然这并不能满足任何应用对于存储的各种需求。为了解决这一问题，Kubernetes 引入了一个新的资源对象：StorageClass，通过 StorageClass 的定义，集群管理员可以先将存储资源定义为不同类型的资源，比如快速存储、慢速存储、共享存储（多读多写）、块存储（单读单写）等。

当用户通过 PVC 对存储资源进行申请时，StorageClass 会使用 Provisioner（不同存储资源对应不同的 Provisioner）来自动创建用户所需 PV。这样应用就可以随时申请到合适的存储资源，而不用担心集群管理员没有事先分配好需要的 PV。

二、动手实践

1. 在UK8S中创建一个nginx服务，并可通过公网访问。 参见：docs.ucloud.cn