Node
Node是Pod真正运行的主机， 可以物理机， 也可以是虚拟机。为了管理Pod，每个Node
节点上至少要运行container runtime（ 比如docker或者rkt） 、kubelet 和 kube-proxy 服务。
kubeadm
K8s集群的管理工具。
kubectl
K8s的命令行工具，用户使用它来管理集群资源（如 pod,service,deployment等）。
kubelet
kubelet 是运行在每个集群节点上的主要的“节点代理”，每个节点都会启动 kubelet进程，用来处理 Master 节点下发到本节点的任务。负责维护容器的生命周期， 同时也负责Volume（ CVI） 和网络（ CNI）的管理。
ectd
ectd存储整个集群的状态。etcd是CoreOS基于Raft开发的分布式key-value存储， 可用于服务发现、 共享配置以及 一致性保障（ 如数据库选主、 分布式锁等） 。
apiserver
提供了资源操作的唯一入口， 并提供认证、 授权、 访问控制、 API注册和 发现等机制。
controller manager
负责维护集群的状态， 比如故障检测、 自动扩展、 滚动更新等。Controller Manager由kube-controller-manager和cloud-controller-manager组成，是Kubernetes的大脑，它通过apiserver监控整个集群的状态，并确保集群处于预期的工作状态。
kube-scheduler
负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上。它监听kube-apiserver，查询还未分配Node的Pod，然后根据调度策略为这些Pod分配节点（ 更新Pod的NodeName 字段）
container runtime
负责镜像管理以及Pod和容器的真正运行（ CRI）； 比如docker或者rkt。
kube-proxy
负责为Service提供cluster内部的服务发现和负载均衡。
Namespace
Namespace是对一组资源和对象的抽象集合，比如可以用来将系统内部的对象划分为不
同的项目组或用户组。常见的pod, service, replication controllers和deployments等都是属于某一个namespace的（ 默认是default，系统使用的命名空间是kube-system），而node, persistentVolumes等则不属于任何namespace。查看命令：kubectl get ns
Pod
Pod是一组紧密关联的容器集合， 它们共享IPC、 Network和UTC namespace， 是 Kubernetes调度的基本单位。 Pod的设计理念是支持多个容器在一个Pod中共享网络和 文件系统， 可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。
Pod通常通过其它资源来管理和创建，比如Deployment,DaemonSet等。
Deployment
Deployment为Pod和Replica Set（升级版的 Replication Controller）提供声明式更新。 你只需要在 Deployment 中描述您想要的目标状态是什么，Deployment controller 就会帮您将 Pod 和ReplicaSet 的实际状态改变到您的目标状态。您可以定义一个全新的 Deployment 来创建 ReplicaSet 或者删除已有的 Deployment 并创建一个新的来替换。
DaemonSet
DaemonSet 确保全部（或者某些）节点上运行一个 Pod 的副本。当有节点加入集群时，会为他们新增一个 Pod。当有节点从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。例如适合于：日志收集，监控等场景
StatefulSet
statefulSet是有状态的资源，可以用来部署：redis，mysql等。
它具有如下特点：唯一的网络标识符。持久化存储。 有序的部署和扩展。 有序的删除和终止。 有序的自动滚动更新。
ReplicationController（RC）(已废弃)
RC确保用户定义的Pod副本数保持不变，RC能指定Pod数量，并通过健康检查来移除不正常的Pod，并创建新的Pod。使得Pod数量稳定而健康。
ReplicationController会替换由于某些原因而被删除或终止的pod，例如在节点故障或中断节点维护（例如内核升级）的情况下。因此，即使应用只需要一个pod，我们也建议使用ReplicationController。
RC跨多个Node节点监视多个pod
ReplicaSet（RS）
RS在RC的基础上增加了label selector集合的功能,而RC只支持单个选择器。RS通常通过Deployment来创建和管理，因为它自己有些功能不支持。
Service
Service是应用服务的抽象， 通过labels为应用提供负载均衡和服务发现。 匹配labels的 Pod IP和端口列表组成endpoints， 由kube-proxy负责将服务IP负载均衡到这些 endpoints上。
每个Service都会自动分配一个cluster IP（ 仅在集群内部可访问的虚拟地址） 和DNS
名， 其他容器可以通过该地址或DNS来访问服务， 而不需要了解后端容器的运行。
Kubernetes ServiceTypes 允许指定一个需要的类型的 Service，默认是 ClusterIP 类型。 Type 的取值以及行为如下：
ClusterIP：通过集群的内部 IP 暴露服务，选择该值，服务只能够在集群内部可以访问，这也是默认的 ServiceType。
NodePort：通过每个 Node 上的 IP 和静态端口（NodePort）暴露服务。NodePort 服务会路由到 ClusterIP 服务，这个 ClusterIP 服务会自动创建。通过请求 <NodeIP>:<NodePort>，可以从集群的外部访问一个 NodePort 服务。
LoadBalancer：使用云提供商的负载局衡器，可以向外部暴露服务。外部的负载均衡器可以路由到 NodePort 服务和 ClusterIP 服务。
ExternalName：通过返回 CNAME 和它的值，可以将服务映射到 externalName 字段的内容（例如， foo.bar.example.com）。 没有任何类型代理被创建，这只有 Kubernetes 1.7 或更高版本的 kube-dns 才支持。
Ingress
ingress可以理解为nginx，是提供给集群外部访问的入口；通常情况下，service和pod仅可在集群内部网络中通过IP地址访问。所有到达边界路由器的流量或被丢弃或被转发到其他地方。
你可以给Ingress配置提供外部可访问的URL、负载均衡、SSL、基于名称的虚拟主机等。用户通过POST Ingress资源到API server的方式来请求ingress。 Ingress controller负责实现ingress，通常使用负载平衡器，它还可以配置边界路由和其他前端，这有助于以HA方式处理流量。
Label
Label是识别Kubernetes对象的标签， 以key/value的方式附加到对象上（ key最长不能超 过63字节，value可以为空，也可以是不超过253字节的字符串）。Label不提供唯一性，并且实际上经常是很多对象（ 如Pods）都使用相同的label来标志 具体的应用。Label定义好后其他对象可以使用Label Selector来选择一组相同label的对象（ 比如 ReplicaSet和Service用label来选择一组Pod）。Label Selector支持以下几种方式：
等式，如 app=nginx 和 env!=production
集合， 如 env in (production, qa)
多个label（ 它们之间是AND关系） ，如 app=nginx,env=test
Horizontal Pod Autoscaling(HPA)
Horizontal Pod Autoscaling可以根据CPU使用率或应用自定义metrics自动扩展Pod数量（支持replication controller、deployment和replica set）。
控制管理器每隔30s（可以通过–horizontal-pod-autoscaler-sync-period修改）查询metrics的资源使用情况。
支持三种metrics类型:
预定义metrics（比如Pod的CPU）以利用率的方式计算。
自定义的Pod metrics，以原始值（raw value）的方式计算。
自定义的object metrics。
支持两种metrics查询方式：Heapster和自定义的REST API。
支持多metrics。
