之前企业都是使用容器化和来构建自己的服务和应用程序，其中容器化优点有很多：提升了部署效率、稳定性、提高了资源的利用率降低了成本。
但是也带来了一些新的问题：容器的数量变得很多，管理就是一个新的问题。所以Kubernetes就出现了，用于管理容器化引擎的部署、扩展和管理等等
Kubernetes组件
Pod
Kubernetes最小调度单元，是一个或者多个容器的组合，一般场景都是单个容器，多个容器的场景就是仅限于这些容器是高度耦合的情况下，它们之间共享某些资源，不得不放在同一个容器当中，比如边车模式，就是将一个应用容器和一个辅助容器放到同一个Pod中，这个辅助容器就是Sidecar（边车模式），通常用于实现一些辅助功能，日志收集、服务监控等
Node
首先一个节点就是可以理解为一个简单的虚拟机，我们可以在节点上运行一个或者多个Pod（Kubernetes最小调度单元，是一个或者多个容器的组合）
现在我们已经将应用程序和数据库放到两个Pod中，如果需要进行访问就需要在内部根据对应的ip进行访问，但是会有两个问题：
-
ip是内部ip集群外部无法访问
-
Pod不是一个稳定实体，很容易被创建和销毁，所以每一次的ip都不是固定的
所以就需要引入一个新的组件service
Service
service可以将一组Pod封装成一个服务，根据一个同一个路口进行访问
服务也分为内部服务和外部服务，内部服务就是我们自己内部使用的服务，外部服务就是我们提供给用户的后端接口之类的，第一种是ip地址和端口来访问Service（仅限开发环境），第二种就是我们通过对应的域名来进行访问所以这个时候就需要一个组件Ingress
Ingress
管理集群外部访问集群内部服务的入口和方式，可以通过Ingress来配置不同的转发策略，根据不同的规则访问不同的Service；还可以配置域名将原来ip+端口方式转换为域名来访问Service，还有负载均衡、SSL证书之类的
ConfigMap
ConfigMap主要是将我们的程序和配置信息进行解耦合的一个组件，正常我们的数据库配置信息是存储在应用程序的，但是如果说我需要换一个数据库，就需要重新编译，那么对于我们服务的可用性，就造成了破坏，所以就可以将对应的配置信息存储到ConfigMap当中，但是ConfigMap存储信息是明文的，所以需要一定的加密策略
Sercret
和ConfigMap类似，但是做了一层Base64编码，所以不能完全保证安全性，所以就需要使用K8S给我们提供的网络安全、访问控制、身份认证等
Volumes
持久化组件，当容器重启或者销毁的时候，里面的数据就会丢失，所以就需要通过Volumes将一些持久化资源，挂在到本地磁盘上
Deployment
我们目前的程序是一个节点的，所以无法保证程序的高可用性，所以就需要搭建集群。而Deployment可以定义和管理应用程序的副本数量以及应用程序的更新策略，可以简化应用程序的部署和更新操作
Pod可以理解为在容器的上面加了一层抽象，这样就可以将一个或者多个容器组合在一起；而Deployment就可以理解在Pod上面加了一层抽象，将一个或者多个Pod组合在一起，并且还具有副本控制（可以保证我们应用程序的可用性，如果有一个挂了，就会生成一个新的替换）、滚动更新（定义和管理应用程序的更新策略，实现平滑更新，逐渐使用新的版本替换旧的版本）、自动扩缩容
StatefulSet
和Deployment类似，但是我们应用程序之间是无状态的，是不需要进行数据同步的，数据库之间是有状态的，是需要相互同步传递数据的。statefulSet也是有副本控制、自动扩缩容的机制，并且还有稳定的网络标识符和持久化存储，像一些数据库、redis、mq这些有状态的程序都是需要通过StatefulSet进行管理，但是StatefulSet还是比较复杂的，一般是可以将数据库这些有状态的程序从集群当中拿出来，单独部署就防止了上述问题
Kubernetes架构
Kubernetes是一个典型的Master-Worker架构，Master-Node负责管理整个集群，Worker-Node负责运行应用程序和服务
为了运行应用程序，Worker-Node主要是有三个组件：kubelet（管理和维护每个节点上的Pod，确保按照预期运行；定期从api-server组件接收新的或者修改后的Pod规范，监控工作节点的运行情况，汇报给api-server）、kube-proxy（为node提供网络代理和负载均衡服务）、container-runtime（可以理解为运行程序的环境，负责拉取容器镜像、创建容器、启动或者停止容器）
Master节点组件：
Kube-Apiserver：提供Kubernetes集群的API接口服务，类似集群的网关，整个系统的入口，所有的请求都会经过它，然后进行分发，比如一些创建、更新、删除Pod请求、查询集群状态的命令；并且读增删改查操作进行认证、授权和访问控制，确保只有认证和授权的请求才可以进行操作
Scheduler：负责监控集群中所有节点的资源使用情况，根据一些调度策略，将一些Pod调度到合适的节点运行。例如，增加一个Pod，第一个节点上占用了80%，第二个节点占用了20%，那个Pod就会自动的存储在第二个资源上
Controller-Manager：负责管理集群中的各种资源对象的状态（Node、Pod、Server等）确保各种资源都处于我们预期的状态
Etcd：高可用的键-值存储系统，用于存储集群中的所有资源对象的状态信息。比如，一个Pod挂掉了，或者新增一个Pod都会记录到ectd里面，整个集群的数据存储中心
Cloud-Controller-Manager：如果你使用的是云服务厂商的云服务集群，就需要这个组件了，负责与云平台相关API进行交互，提供一致的管理接口，在不同的云平台中运行和管理他们的应用程序
