https://www.jianshu.com/p/4b16c995990b
在kubernetes中，pod是应用程序的载体，我们可以通过pod的ip来访问应用程序，但是pod的ip地址不是固定的，如果pod挂掉或者重启后，其ip会发生变化，也就意味着每次pod重启后都需要手工更换ip去访问应用程序。
为了解决这个问题，kubernetes提供了Service资源，Service会对提供同一个服务的多个pod进行聚合，并且提供一个统一的入口地址，一个固定的ip地址。通过访问Service的入口地址就能访问到后面的pod服务，即使pod发生重启或者删除，用户也不需更换service ip。对用户来说service ip是不变的，用户无法感知pod ip地址。
Kubernetes 主要通过 API Server 对外提供服务，Kubernetes 对于访问 API 的用户提供了相应的安全控制：认证和授权。认证解决用户是谁的问题，授权解决用户能做什么的问题。只有通过合理的权限控制，才能够保证整个集群系统的安全可靠。
下图是 API 访问需要经过的三个步骤，它们分别是：认证、授权和准入。
2、Pod异常状态排错
首先列出Pod排查过程中我这边的常用命令：
在K8s集群中微服务的负载均衡是由Kube-proxy实现的，它是K8s集群内部的负载均衡器，也是一个分布式代理服务器，在K8s的每个节点上都有一个，这一设计体现了它的伸缩性优势，需要访问服务的节点越多，提供负载均衡能力的Kube-proxy就越多，高可用节点也随之增多。kube-porxy负责为Service资源提供cluster集群内部的服务发现和负载均衡，它运行在每一个Node物理节点之上，负责为节点上的所有pod资源提供网络代理服务。他会定时的从etcd数据库获取到service维护的路由信息做出相应的负载策略，维护网络负载策略和4层负载均衡工作。
一个kubernetes集群主要是由控制节点(master)、**工作节点(node)**构成，每个节点上都会安装不同的组件。
master：集群的控制平面，负责集群的决策 ( 管理 )
1、进程间高度耦合的应用：此类应用具有高度耦合特点，不利于横向拓展。例如：应用间通信使用非API设计；单个进程启动依赖其他进程启停。此类应用建议改造，使用接口通信，利于横向拓展。例如使用共享内存，管道，信号、信号量等做进程间通信，就不适合部署在容器云上。
2、单个进程启动依赖其他进程启停，容器云是一种不可变的基础设施，POD在云上可以进行漂移，扩缩容，所以通过容器云建设的应用系统启停次数会比通过虚拟机建设的应用系统更加频繁一些。
3、此类应用具有大量存储IO读写的特点，不利于数据快速落盘和读取。例如：数据库。集中式的网络存储要求非常高，并且不可以随时进行横向扩展。典型的例如高吞吐的集中式数据库，高吞吐的有状态应用需要落地数据。
4、安全敏感的服务：例如，某些服务需要严格的安全控制，可能不适合部署在公共云或不受保护的环境中。
5、资源密集型应用程序：某些应用程序可能会消耗大量资源，如果部署在k8s上，可能会影响集群中其他服务的性能。（内存，cpu，网络，存储）
Pod是Kubernetes中的基本运行单元，可以包含一个或多个紧密相关的容器。它们共享相同的网络命名空间、IP地址和端口空间，可以访问相同的存储资源。Pod作为单个应用的最小单元，确保其中的容器在同一个运行环境中并且相互之间的网络通信更为简单。
Pod与容器的区别主要在于：
1、抽象层级不同： 容器是轻量级、可移植的计算环境，而Pod是在容器上更高一层的抽象，代表在同一个应用上下文中运行的一个或多个容器。
2、生命周期管理：Kubernetes通过Pod来管理应用的生命周期而不是直接管理容器。Pod封装了容器的运行环境，为其提供协调的操作环境。
Pod是Kubernetes中的基本运行单元，可以包含一个或多个紧密相关的容器。它们共享相同的网络命名空间、IP地址和端口空间，可以访问相同的存储资源。Pod作为单个应用的最小单元，确保其中的容器在同一个运行环境中并且相互之间的网络通信更为简单。
Pod与容器的区别主要在于：
1、抽象层级不同： 容器是轻量级、可移植的计算环境，而Pod是在容器上更高一层的抽象，代表在同一个应用上下文中运行的一个或多个容器。
2、生命周期管理： Kubernetes通过Pod来管理应用的生命周期而不是直接管理容器。Pod封装了容器的运行环境，为其提供协调的操作环境。
