一、Kubernetes架构
二、Kubernetes资源
图片地址：https://www.processon.com/mindmap/618666cd7d9c0828a156e0da
2.1 Pod资源
2.2 Service资源
2.3 Ingress资源
2.4 PV和PVC资源
三、Kubernetes总结
1. Pod是一个容器的集合，一个Pod包含一个或多个容器。Pod提供了更高层次的抽象，但是Pod的设计并不是为了运行同一个应用的多个实例，而是运行与一个应用紧密相联的程序，而且每个程序都运行在单独的容器之中，以Pod的形式组合成一个应用，相比于在单个容器中运行多个程序，这样的设计有以下好处：
- 透明性：Pod内的容器对基础设施可见，底层系统能向容器提供如进程管理和资源监控等服务，带给用户极大的便利
- 解绑软件的依赖：单个容器可以独立地重建和重新部署，可以实现独立容器的实时更新
- 易用性
- 高效性
2. Service是一种抽象的概念，它定义了一个Pod的集合以及访问它们的策略，Service和Pod之间的关联是通过Label Selector完成的。在Kubernetes中Pod的销毁和重建是非常频繁的，重建后的Pod的PodIP会发生变化这就会使对Pod的访问造成影响并且Pod的PodIP只能在集群内部被访问 ，Service资源可以解决上述两个问题。Service的目标是提供一种桥梁，它会为访问者提供一个固定的访问地址，用于在访问时重定向到相应的后端。
3. Service有两种重要的类型：NodePort和LoadBanlancer，每声明一个上述类型的Service就会占用宿主机的一个NodePort，这就会出现一个问题：宿主机的Port可能会被过多的占用，这就是Ingress资源出现的原因。Ingress只需要一个NodePort或者一个LB就可以满足暴露多个Service的需求。通过在Ingress里建立诸多映射规则，Ingress Controller就会监听这些配置规则并转化成Nginx的反向代理配置 , 并将生成的Nginx配置写入到一个运行着的Nginx服务中，到此为止，其实真正在工作的就是一个Nginx了，内部配置了用户定义的请求转发规则，然后对外部提供服务。