在Kubernetes Service基础一节中，我们了解到可以通过设置Service NodePort向Kubernetes集群外部暴露端口，外部服务可以通过Kubernetes集群节点IP+NodePort访问集群内部资源。当集群内部服务众多时，需要暴露的端口也会越来越多。这样不仅端口维护困难，集群边界也变得“千疮百孔”。针对这个问题，Kubernetes提供了Ingress来解决，Ingress对象用于配置外部请求转发到集群内部服务的具体规则，而实际的转发操作由Ingress Controller来完成。

前面介绍的Pod管理对象，如RC/RS、Deployment、DaemonSet等都是面向无状态服务的，而对于有状态的应用，比如MySQL集群，MongoDB集群等，则可以使用StatefulSet来完成。有状态的应用集群通常有以下这些特点：

1. 每个节点都有固定的身份ID，通过这个ID，集群中的成员可以相互发现并通信；

2. 集群的规模是比较固定的，集群规模不能随意变动；

3. 集群中的每个节点都是有状态的，通常会持久化数据到永久存储中。

手动创建PV不仅繁琐，还可能造成资源浪费。比如某个PV定义的存储空间为10Gi，该PV被某个声明需要8Gi内存的PVC绑定上了，这时候该PV处于Bound状态，无法再和别的PVC进行绑定，PV上剩下的2Gi内存实际上浪费的。StorageClass可以根据PVC的声明，动态创建对应的PV，这样不仅省去了创建PV的过程，还实现了存储资源的动态供应。

在Kubernetes中，我们虽然可以使用volume将容器内目录挂载到宿主机目录上，但由于Pod调度的不确定性，这种数据存储方式是不牢靠的。对于有状态的应用，我们希望无论Pod被调度到哪个节点上，它们的数据总能够完整地恢复，这时候我们就不能用volume挂载了，而应该使用“网络共享存储”。PV/PVC就是用于解决问题而存在的，它们屏蔽了底层存储实现的细节，使得我们很容易上手使用。

CICD（Continuous Integration/Continuous Deployment），持续集成持续部署的意思。完成CICD实践需要Kubernetes集群，Harbor，GitLab和Jenkins等软件配合完成，在前面几篇博客中，我已经搭建好了Kubernetes集群，并且在master节点（192.168.33.11,CentOS）上安装好了Harbor、GitLab和Jenkins，有需要可以参考下。

在CentOS下安装GitLab和Jenkins。

Harbor是一款开源的Docker镜像存储仓库，其扩展了Docker Distribution，在此基础上添加了我们常用的功能，比如安全认证，RBAC用户权限管理，可视化页面操作等功能。Harbor还支持多个Harbor仓库间的相互拷贝，以实现Docker镜像仓库的高可用。这节我们在CentOS虚拟机（192.168.33.11）上搭建个单机版的Harbor体验一下。

通过前面的学习我们知道，我们可以通过requests和limits给Pod指定资源配置，但如果每个Pod都要指定的话略显繁琐，我们可以使用LimitRange指定一个全局的默认配置；此外通过ResourceQuota对象，我们可以定义资源配额，这个资源配额可以为每个命名空间都提供一个总体的资源使用的限制：它可以限制命名空间中某种类型的对象的总数目上限，也可以设置命名空间中Pod可以使用的计算资源的总上限。