K8S核心组件：
etcd：保存整个集群的状态
apiserver：提供了资源操作的统一入口，并提供认证、授权、访问控制、API注册和发现等机制；
controller manager：负责维护集群的状态，比如故障检查、自动扩展、滚动更新。故障检查是指发现某个容器异常时，会自动尝试拉起，如果出现宕机，会自动重建一个新的容器，从而保证业务正常可用
scheduler：负责资源的调度，按照预定的调度策略将pod调度到相应的节点上。
kubelet：负责维护容器的生命周期，会直接调用docker进行生命周期管理，同时也负责volume（CVI），同时也负责网络(vni)的管理
container runtime：负责镜像管理以及pod和容器的真正运行（CRI）；
kube-proxy:负责为service提供cluster内部的服务发现和负载均衡；换言之，保证外部能访问容器服务
kube-proxy.service loaded active running Kubernetes Kube-Proxy Server #提供容器网络访问
kubelet.service loaded active running Kubernetes Kubelet Server #调用docker，来管理容器的生命周期
kube-apiserver.service loaded active running Kubernetes API Server #接受并相应用户的请求
kube-controller-manager.service loaded active running Kubernetes Controller Manager #控制器的概念，保障容器的存活
kube-scheduler.service loaded active running Kubernetes Scheduler Plugin #调度器，选择容器启动的node节点
pod
pod是kubernetes的基本操作单元，也是应用运行的载体，整体kubernetes系统都是围绕着pod展开的，比如如何部署运行pod，如何保证pod的数量、如何访问pod等。另外，pod是一个或者多个相关容器的集合，这算是一大创新点，提供了一种容器的组合的模型；
k8s每启动一个pod，都需要先启动一个pod-infrastructure容器，一个pod中的多个相关容器（副本），共用pod容器的IP地址
可用于服务发现和负载均衡，新启动的容器，自动加入到负载均衡
pod和容器
在docker中，容器是最小的处理单元，增删改查的对象是容器，容器是一种虚拟化技术，容器之间隔离是通过Linux NS实现，而在k8s中，pod包含了一个或多个相关的容器，pod可以认为是容器的一种延伸扩展，一个pod也是一个隔离体，而pod内部包含的一组容器又是共享的（包括pid、network、IPC、UTS），除此之外，pod中的容器可以访问共同的数据卷来实现文件系统的共享。
镜像
在kubernetes中，镜像的下载策略为：
always：每次都下载最新的镜像；
never：只使用本地镜像，从不下载
ifnotpresent：只有当本地没有的时候才下载镜像
pod被分配到node以后，会根据镜像下载策略进行镜像下载，可以根据自身集群的特点来决定采用何种下载策略，但是无论哪种策略，都必须保证node上能有正确的镜像可用。
其他设置：
通过yaml文件，可以在pod中设置：
启动命令，spec-->container-->commond
环境变量，spec-->container-->env-->name/value
端口桥接，spec-->container-->ports-->containerPort/protocol/hostIP/hostPort（使用hostPort时需要注意端口冲突的问题，不过kubernetes在调度pod时会检查宿主机端口是否冲突，比如当两个pod均要求绑定宿主机的80端口时，kubernetes就会将这两个pod分别调度到不同的机器上）
host网络：一些特殊场景下，容器必须要以host方式进行网络设置，比比如接收物理机网络才能接收到的组播流量时，在pod中也支持host网络的设置，spec-->hostNetwork=true
数据持久化，spec-->container-->volumeMounts-->mountPath
replication controller
replication controller是kubernetes中的一个核心概念，应用托管在kubernetes之后，kubernetes需要保证应用能够持久运行，这是RC的工作内容，它会保证任何时间kubernetes中都有指定数量的pod在运行，在此基础上，rc还提供了一些更高级的特性，比如滚动升级、升级回滚等；
rc与pod的关联---label
rc与pod的关联是通过label来实现的，label机制是kubernetes中的一个重要设计，通过label进行对象的弱关联，可以灵活地进行分类和悬着，对于pod，需要设置其自身的label来进行标识，label是一系列的Key/value对，在pod-->metadate-->labels中进行设置。
label的定义是任意的，但是label必须具有可标识性，比如设置的pod的应用名称和版本号等，另外label是不具有唯一性的，为了更准确的标识一个pod，应该为pod设置多个维度的label
举例：当在rc的yaml文件中定义了该RC的selector中的label为app:nginx，那么这个rc就会去关注pod-->matadata-->labels中label为app：nginx的pod，修改了对应pod的label，就会使pod脱离rc的控制。同样，在RC运行正常的时候，若试图继续创建同样label的pod，是创建不出来，因为rc认为当前的副本数是正常的，再多起的话就会被rc删除掉。
