Kubernetes(k8s)是Google开源的容器集群管理系统。在Docker技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性。
Kubernetes最主要的设计思想是，从更宏观的角度，以统一的方式来定义任务之间的各种关系，并且为将来支持更多种类的任务留足余地。
Kubernetes所擅长的，是按照用户的意愿和整个系统的规则，完全自动化地处理好容器之间的各种关系。这种功能，就是我们经常听到的一个概念：编排。所以说，Kubernetes的本质，是为用户提供一个具有普遍意义的容器编排工具。
k8s中几个重要概念
(1) Cluster,Cluster是 计算、存储和网络资源的集合，k8s利用这些资源运行各种基于容器的应用。
(2) Master, Master是cluster的大脑，他的主要职责是调度，即决定将应用放在那里运行。master运行linux操作系统，可以是物理机或者虚拟机。为了实现高可用，可以运行多个master。
(3) Node, Node的职责是运行容器应用。node由master管理，node负责监控并汇报容器的状态，同时根据master的要求管理容器的生命周期。node运行在linux的操作系统上，可以是物理机或者是虚拟机。
(4),pod,pod是k8s的最小工作单元。每个pod可以包含一个或者多个容器。pod中的容器会作为一个整体被master调度到一个node上运行。 Pod有两种使用方式，运行单一容器和运行多个容器， 运行单一容器是Kubernetes 最常见的模型，即便是只有一个容器，Kubernetes 管理的也是Pod 而不是直接管理容器。而pod中运行多个容器的话，哪些容器应该放到一个Pod中？答案是：这些容器联系必须非常紧密，而且需要直接共享资源。
(5）controller, k8s不会直接创建pod,而是通过controller来管理pod的。controller中定义了pod的部署特性，比如有几个副本，在什么样的node上运行等。为了满足不同的业务场景，k8s提供了多种controller，包括Replication Controller（RC）、Replica Set（RS）、Deployment 、daemonset、statefulset、job等。
RC是K8s集群中最早的保证Pod高可用的API对象，通过监控运行中的Pod来保证集群中运行指定数目的Pod副本。指定的数目可以是多个也可以是1个；少于指定数目，RC就会启动运行新的Pod副本；多于指定数目，RC就会杀死多余的Pod副本。即使在指定数目为1的情况下，通过RC运行Pod也比直接运行Pod更明智，因为RC也可以发挥它高可用的能力，保证永远有1个Pod在运行。
(6)Replica Set （RS）
RS是新一代RC，提供同样的高可用能力，区别主要在于RS后来居上，能支持更多种类的匹配模式。RS对象一般不单独使用，而是作为Deployment的理想状态参数使用。使用deployment时会自动创建Replica Set ，也就是说deployment是通过Replica.Set来管理pod的多个副本的，我们通常不需要直接使用Replica Set 。
(7) deployment（部署）
Deployment表示用户对K8s集群的一次更新操作，它是一个比RS应用模式更广的API对象，可以是创建一个新的服务，更新一个新的服务，也可以是滚动升级一个服务。以K8s的发展方向，未来对所有长期伺服型的的业务的管理，都会通过Deployment来管理。
(8) daemonset（后台支撑型服务）
长期伺服型和批处理型服务的核心在业务应用，可能有些节点运行多个同类业务的Pod，有些节点上又没有这类Pod运行；而后台支撑型服务的核心关注点在K8s集群中的节点（物理机或虚拟机），要保证每个节点上都有一个此类Pod运行。节点可能是所有集群节点选定的一些特定节点。典型的后台支撑型服务包括，存储，日志和监控等在每个节点上支持K8s集群运行的服务。
(9) statefuleset
能够保证pod的每个副本在整个生命周期中名称是不变的，而其他controller不提供这个功能。当某个pod发生故障需要删除并重新启动时，pod的名称不会发生变化，同时statefulset会保证副本按照固定的顺序启动、更新或者删除。、
(10) job 用于运行结束就删除的应用，而其他controller中的pod通常是长期持续运行的。
(11) service, deployment可以部署多个副本，每个pod 都有自己的IP，外界如何访问这些副本那？答案是service。
k8s的service定义了外界访问一组特定pod的方式。service有自己的IP和端口，service为pod提供了负载均衡。
k8s运行容器pod与访问容器这两项任务分别由controller和service执行。
(12）、namespace
可以将一个物理的cluster逻辑上划分成多个虚拟cluster，每个cluster就是一个namespace。不同的namespace里的资源是完全隔离的。Kubernetes 默认创建了两个
Kubernetes 默认创建了两个,Namespace。default -- 创建资源时如果不指定，将被放到这个
Namespace 中。kube-system：Kubernetes 自己创建的系统资源将放到这个Namespace 中
1、k8s中master的组成
(1) API, Server(kube-apiserver),API Server是k8s的前端接口，各种客户端工具以及k8s其他组件可以通过它管理集群的各种资源。
(2) Scheduler(kube-scheduler),scheduer负责决定将pod放在哪个node上运行。另外scheduler在调度时会充分考虑集群的架构，当前各个节点的负载，以及应用对高可用、性能、数据亲和性的需求。
(3) Controller,Manager(kube-controller-manager),负责维护集群的状态，比如故障检测、自动扩展、滚动更新等。Controller
Manager 由多种 controller组成，包括 replication controller、endpoints,controller、namespace,controller、serviceaccounts controller 等。
不同的 controller管理不同的资源。例如 replication controller 管理 Deployment、StatefulSet、DaemonSet 的生命周期，namespace controller 管理 Namespace资源。
（4）etcd
负责保存k8s集群的配置信息和各种资源的状态信息，K8S中所有的服务节点的信息数据、配置数据都是存储在ETCD中，当数据发生变化时，etcd会快速的通知k8s相关组件。
（5）pod网络（flannel ）
pod要能够相互通信，k8s集群必须掌握pod网络，flannel是其中一个可选的方案。
k8s中node的组成
（1）kubelet, 是node的agent，当scheduler去确定在某个node上运行pod后，会将pod的具体配置信息发送给该节点的kubelet，kubelet会根据这些信息创建和运行容器，并向master报告运行状态。
（2）kube-proxy, service 在逻辑上代表了后端的多个 Pod，外界通过service 访问 Pod。service接收到的请求是如何转发到 Pod 的呢？这就是kube-proxy要完成的工作。proxy是配合service实现从pod到service， 以及从外部的node port到service的访问。每个 Node都会运行 kube-proxy 服务，它负责将访问 service 的 TCP/UPD,数据流转发到后端的容器。如果有多个副本，kube-proxy会实现负载均衡。
（3）pod网络, pod能能够互相通信，k8s集群必须部署pod网络，flannel是其中一个可以选择的方案
1. kubectl发送部署deployment的请求到API Server。
2、API Server通知Controller Manager创建一个deployment资源。
3、Deployment controller向API Server发送创建ReplicaSet的需求。
4、ReplicaSet通知ReplicaSet controller启动。
5、ReplicaSet controller发送创建Pod需求到API Server
6、API Server通知Scheduler执行调度任务
7、Scheduler根据副本数将分配Pod到集群中的node节点
8、API Server通知对应的node节点上面的kubelet组件准备创建pod
9、kubelet告诉docker在本节点上运行容器。
10、docker在节点上运行一个或多个容器。
Deployment 的概念
作为最常用的Kubernetes对象，Deployment经常会用来创建 ReplicaSet和Pod，我们往往不会直接在集群中使用ReplicaSet部署一个新的微服务，一方面是因为ReplicaSet 的功能其实不够强大，一些常见的更新、扩容和缩容运维操作都不支持，Deployment的引入就是为了支持这些复杂的操作
Deployment 执行流程总结
最后，总结一下deployment实现的过程：
（1）首先用户通过 kubectl 创建Deployment。
（2）接着，Deployment创建 ReplicaSet。
（3）然后，ReplicaSet 创建Pod
（4）最后，pod在每个节点上通过kubelet调用docker完成容器创建。
这个工作就变成了一个挑战，而且全部停止了服务，再逐步升级的方式会导致服务较长时间不可用。针对这个问题，k8s提供了滚动更新(rolling-update)的方式来解决上述问题。滚动更新是针对pod来操作的，它通过一次只更新一小部分副本，成功后，再更新更多的副本，最终完成所有副本的更新。滚动更新的最大的好处是零停机，整个更新过程始终有副本在运行，从而保证了服务的连续性。
Kubectl get 命令 ：获得资源信息
# 查看所有的资源信息
$ kubectl get all
$ kubectl get --all-namespaces
# 查看pod列表
$ kubectl get pod
# 显示pod节点的标签信息
$ kubectl get pod --show-labels
# 根据指定标签匹配到具体的pod
$ kubectl get pods -l app=example
# 查看node节点列表
$ kubectl get node
# 显示node节点的标签信息
$ kubectl get node --show-labels
# 查看pod详细信息，也就是可以查看pod具体运行在哪个节点上（ip地址信息）
$ kubectl get pod -o wide
# 查看服务的详细信息，显示了服务名称，类型，集群ip，端口，时间等信息
$ kubectl get svc
$ kubectl get svc -n kube-system
# 查看命名空间
$ kubectl get ns
$ kubectl get namespaces
# 查看所有pod所属的命名空间
$ kubectl get pod --all-namespaces
# 查看所有pod所属的命名空间并且查看都在哪些节点上运行
$ kubectl get pod --all-namespaces -o wide
# 查看目前所有的replica set，显示了所有的pod的副本数，以及他们的可用数量以及状态等信息
$ kubectl get rs
# 查看已经部署了的所有应用，可以看到容器，以及容器所用的镜像，标签等信息
$ kubectl get deploy -o wide
$ kubectl get deployments -o wide
