（1） Service：描述了一个应用的访问入口，通过 Label（标签）实现 Service 与后端服
务（Pod）的关联，也就实现了服务发现功能。
（2） Ingress：支持 Kubernetes 集群以外的客户端访问应用。
（3） Configmap、Secret：描述应用所需的配置参数或加密的密钥等。
（4） PV、PVC、HostPath、EmptyDir：描述应用所需的各类存储，支持持久化存储、临时存储。
有了这些资源对象，使用者可以很方便地描述应用程序。通常使用 Yaml 文件表示，一个 kubectl apply -f myapp.yaml 命令就可以等待 Kubernetes 完成应用部署，达到期望状态，其背后重要的设计理念就是声明式 API 和控制器模式。简单理解，用户通过Yaml 文件描述了期望的最终状态，比如“我需要用 Nginx 镜像启动 3 个 Pod，然后通过名为 Myapp 的 Service 暴露这个应用”。Kubernetes 接收到这个请求时，会将其保存到 ETCD 数据库中，由控制器创建 3 个 Pod 和 1 个 Service。由于创建资源需要一定时间，控制器会不断检查这些资源的状态，并且和期望的状态比较，如果不一致，持续处理（例如调度到其他节点），直到最终达成一致，这个过程如图 1-4 所示。
图 1-4 Kubernetes 声明式 API、控制器模式
