1.kubernetes架构与组件
Kubernetes集群是由一组节点，也就是node节点组成，可以是物理服务器，也可以是虚拟机。
每个node节点上都安装了kubelet和kube-proxy这两个node组件。
而安装了master组件的节点称为master node。
node组件通过kubelet组件与master组件进行交互，维护着该node上的pod的生命周期。
一个典型的master集群是由一个master node和若干个承载工作负荷的node组成。
kubernetes通过etcd存储着集群中的所有对象和状态。
kubernetes还提供了集群维护的超级命令行工具kubectl。
（1）master
master组件主要包括：Apiserver、Scheduler、Controller Manager和etcd。
Api Server是master组件的中枢，其余的master组件都是通过调用Api的接口，实现各自的功能。
API server是整个集群控制的前端，是唯一可以修改集群状态和数据库的组件。
master组件是Kubernetes集群的大脑。
所有集群的控制命令都传递给Master组件并在其上执行。
每个Kubernetes集群至少有一套Master组件。来负责控制和管理整个集群，才能保证集群的正常运转。
它协调集群中的所有活动，包括集群中应用的调度、状态维护、应用升级和伸缩，以及对外的API接口。
API Server：
集群控制的唯一入口，是提供Kubernetes集群控制Restful API的核心组件。封装了核心对象的增删改查等操作。
提供集群控制的安全机制（身份认证、授权以及admission control）。
Scheduler：
通过API Server的Watch接口监听新建Pod副本信息，并通过调度算法为该Pod选择一个最合适的Node。
支持自定义调度算法provider。
默认调度算法内置预选策略和优选策略，决策考量资源需求、服务质量、软硬件约束、情缘性、数据局部性等指标参数。
ControllerManager：
集群内各种资源controller的核心管理者。
针对每一种具体的资源，都有对应的Controller。
保证其下管理的每个Controller所对应的资源始终”处于期望状态“。
Etcd：
Kubernetes集群的主数据库，存储着所有资源对象以及状态。
默认与Master组件部署在一个Node上。
Etcd的数据变更都是通过API Server进行的。
（2）Node组件
Kubernetes集群中真正的工作负载均衡节点。
Kubernetes集群由多个Node共同承担工作负载，Pod被分配到某个具体的Node上执行。
Kubernetes通过node controller对资源进行管理。支持动态在集群中添加或刪除Node。
每个集群Node1上都会部署Kubelet和Kube-proxy两个组件。
Kubelet：
位于集群中每个Node上的非容器形式的服务进程组件，Master和node之间的桥梁。
处理master下发到本Node上的Pod创建、启停等管理任务，向APIServer注册Node信息。
监控本Node上容器和节点资源情况，并定期向master汇报资源占用情况。
Kube-proxy：
Service抽象概念的实现，将到Service的请求按策略（负载均衡）算法分发到后端Pod上。
默认使用iptables mode实现。
支持nodeport模式，实现从外部访问集群内的service。
2.Kubernetes基本概念
（1）kubernetes对象和对象模型
Kubernetes对象是一种持久化的、用于表示集群状态的实体。
一种声明式的意图的记录，一般使用yaml文件描述对象。
Kubernetes集群使用Kubernetes对象来表示集群的状态。
通过API/kubectl管理Kubernetes对象。
（2）常用的metadata属性
Name和UID：
Kubernetes集群中所有对象都通过name和UID明确标识。
在Kubernetes集群的整个生命周期内创建的每个对象实例都具有不同的UID。
Namespace：
不仅仅是一个属性，本身也是一个object。
用于将物理集群划分为多个虚拟集群。
常用来隔离不同的用户及权限。
内置三个Namespaces：default、kube-system和kube-public、Node和PersistentVolume不属于任何namespace。
Label：
用于建立集群对象之间的灵活的、松耦合的多维关联关系。
一个label是一个键值对，其中key、value均由用户自己定义。
label可以附着在任何对象上，每个对象也可以有任意个标签。
标签可在对象定义时附加上，也可以通过命令动态管理标签。
Label可以将有组织目的的结构映射到集群对象上，从而形成一个与现实世界管理结构同步对应松耦合的、多维的对象管理结构。
通过label select查询和刷选建立对象间的关系。
Annotations（注解）：
可以将任意非标识性元数据附加到对象上。也是以键值对形式呈现。
工具和库可以检索到并使用这些Annotation元数据。
将数据作为Annotation附着在对象上，有利于创建一些用于部署、管理和做内部检查的共享工具或客户端。
（3）kubernetes对象分类
Kubernetes中的对象有很多，主要可以分为以下：
Pod：
一个有特定关系的容器集合。
Pod是集群中可以创建和部署的最小且最简的Kubernetes对象单元。
Pod也是一种封装。它封装了应用容器，存储资源，独立的网络以及决定容器如何运行的策略选项。
每个Pod中预置一个Pause容器，其名字空间、IPC资源、网络和存储资源被Pod内其它容器共享。
Pod中所有容器紧密协作并且作为一个整体被管理、调度和运行。
Pod是一个非持久性实体，在调度失败、节点故障、缺少资源等情况下都可以被终止掉。
即使只有一个Pod，也不应该手动创建。
Pod的生命周期图如下：
Service：
与云原生应用中”微服务“概念对应。
Kubernetes集群为每个Service分配一个集群唯一的IP地址。
在service的生命周期内，该IP地址不变；在内部DNS的支持下，轻松实现服务发现机制。
Service通过label selector关联到实际支撑业务运行的Pod上，
并通过集群内置的负载均衡将服务请求分发到后端Pod。
通过nodeport或设置loadbalancer机制实现集群外部对service的访问。
Controllers：
Controller是Kubernetes核心对象之一。
Controller用于保证集群内一组Pod能始终按照某种期望的状态正常运行。
状态包括：Pod副本数量、节点选择、资源约束、持久化数据维持等。
Kubernetes支持多种Controller，常用的Deployment、replicaset、statefulset、daemonset等。
ReplicaSet：
确保健康Pod的副本数始终满足用户定义的数量。
前身是ReplicationController（rc），相比rc，增加集合式label selector的支持。
支持单独使用，但更多隐藏在Deployment控制器后面，由deployment自动管理。
deployment
为Pod和ReplicaSet提供了声明式的定义（declarative）。
用户在deployment文件中描述期望状态，Deployment controller就会自动将Pod和Reploca Set的实际状态变更到期望状态。
Deployment支持Pod的RollingUpdate，并自动管理背后的Replicaset。
Deployment支持将pod Rollback到之前的任意revision。
StatefulSet
StatefulSet提供对有状态的应用的部署和控制的支持。
使用场景：稳定的持久化存储、稳定的网络标志、有序部署有序扩展、有序收缩有序刪除、有序自动滚动升级等。
Pod的存储必须由PersistentVolume Provisioner根据请求的Storage Class进行配置，或由管理员预先配置好。
考虑数据安全性，伸缩或刪除StatefulSet不会刪除关联的存储；
另外StatefulSet目前要求Headless Service负责Pod的网络身份，用户有责任创建此服务。
DaemonSet
保证每个Node上都运行一个Pod副本。
适用场景：系统Daemon程序、监控跟踪、日志收集等。
可指定Node：nodeSelector、nodeAffinity、podAffinity
ConfigMap
常用来向Pod提供非敏感的配置信息。
ConfigMap用于保存配置数据的键值对，可以用来保存单个属性，也可以用来保存配置文件。
ConfigMap可以适用命令行基于字面值、文件或目录来创建或通过configmap对象定义文件创建。
ConfigMap可以通过三种方式在Pod中使用：环境变量、命令行参数或以文件形式通过数据卷插件挂载到Pod中。
Secret
解决的是集群内密码、token、密钥等敏感的数据的配置问题。
常用于与ServiceAccount股那里，存储在tmpfs文件系统中，刪除后Secret文件也会对应的刪除。
支持Opaque、kubernetes.io/Service Account，kubernetes.io/dockerconfigjson三种类型。
Secret可以以Volume或者环境变量配合使用。
Service：
与云原生应用中”微服务“概念对应。
Kubernetes集群为每个Service分配一个集群唯一的IP地址。
在service的生命周期内，该IP地址不变；在内部DNS的支持下，轻松实现服务发现机制。
Service通过label selector关联到实际支撑业务运行的Pod上，
并通过集群内置的负载均衡将服务请求分发到后端Pod。
通过nodeport或设置loadbalancer机制实现集群外部对service的访问。
Controllers：
Controller是Kubernetes核心对象之一。
Controller用于保证集群内一组Pod能始终按照某种期望的状态正常运行。
状态包括：Pod副本数量、节点选择、资源约束、持久化数据维持等。
Kubernetes支持多种Controller，常用的Deployment、replicaset、statefulset、daemonset等。
（1）ReplicaSet
确保健康Pod的副本数始终满足用户定义的数量。
前身是ReplicationController（rc），相比rc，增加集合式label selector的支持。
支持单独使用，但更多隐藏在Deployment控制器后面，由deployment自动管理。
（2）deployment
为Pod和ReplicaSet提供了声明式的定义（declarative）。
用户在deployment文件中描述期望状态，Deployment controller就会自动将Pod和Reploca Set的实际状态变更到期望状态。
Deployment支持Pod的RollingUpdate，并自动管理背后的Replicaset。
Deployment支持将pod Rollback到之前的任意revision。
（3）StatefulSet
StatefulSet提供对有状态的应用的部署和控制的支持。
使用场景：稳定的持久化存储、稳定的网络标志、有序部署有序扩展、有序收缩有序刪除、有序自动滚动升级等。
Pod的存储必须由PersistentVolume Provisioner根据请求的Storage Class进行配置，或由管理员预先配置好。
考虑数据安全性，伸缩或刪除StatefulSet不会刪除关联的存储；
另外StatefulSet目前要求Headless Service负责Pod的网络身份，用户有责任创建此服务。
（4）DaemonSet
保证每个Node上都运行一个Pod副本。
适用场景：系统Daemon程序、监控跟踪、日志收集等。
可指定Node：nodeSelector、nodeAffinity、podAffinity
（5）ConfigMap
常用来向Pod提供非敏感的配置信息。
ConfigMap用于保存配置数据的键值对，可以用来保存单个属性，也可以用来保存配置文件。
COnfigMap可以适用命令行基于字面值、文件或目录来创建或通过configmap对象定义文件创建。
ConfigMap可以通过三种方式在Pod中使用：环境变量、命令行参数或以文件形式通过数据卷插件挂载到Pod中。
（6）Secret
解决的是集群内密码、token、密钥等敏感的数据的配置问题。
常用于与ServiceAccount股那里，存储在tmpfs文件系统中，刪除后Secret文件也会对应的刪除。
支持Opaque、kubernetes.io/Service Account，kubernetes.io/dockerconfigjson三种类型。
Secret可以以Volume或者环境变量配合使用。
来源：https://www.cnblogs.com/yangmingxianshen/p/12547335.html