基本概念前端
1. Cluster后端
Cluster是计算、存储和网络资源的集合，Kubernetes 利用这些资源运行各类基于容器的应用。api
2. Master网络
Master是Cluster的大脑，它的主要职责是调度,即决定将应用放在哪里运行。Master运行Linux操做系统，能够是物理机或者虚拟机。为了实现高可用，能够运行多个Master。负载均衡
3. Node工具
Node的职责是运行容器应用。Node由Master管理,Node负责监控并汇报容器的状态，同时根据Master的要求管理容器的生命周期。Node运行在Linux操做系统上，能够是物理机或者是虚拟机。性能
4. Pod测试
Pod是Kubernetes 的最小工做单元。每一个Pod 包含-一个或多个容器。Pod中的容器会做为一个总体被Master 调度到一个Node上运行。spa
5. Controller操作系统
Kubernetes一般不会直接建立Pod，而是经过Controller 来管理Pod 的。Controller 中定义了Pod的部署特性，好比有几个副本、在什么样的Node.上运行等。 为了知足不一样的业务场景，Kubernetes 提供了多种Controller， 包括Deployment、 ReplicaSet、 DaemonSet、StatefuleSet、Job等，咱们逐- -讨论。
(1) Deployment是最经常使用的Controller， 好比在线教程中就是经过建立Deployment 来部署应用的。Deployment 能够管理Pod的多个副本，并确保Pod按照指望的状态运行。
(2) ReplicaSet实现了Pod 的多副本管理。使用Deployment 时会自动建立ReplicaSet,也就是说Deployment 是经过ReplicaSet 来管理Pod 的多个副本的，咱们一般不须要直接使用ReplicaSet。
(3) DaemonSet 用于每一个Node 最多只运行一个Pod副本的场景。正如其名称所揭示的，DaemonSet 一般用于运行daemon。
(4) StatefuleSet 可以保证Pod的每一个副本在整个生命周期中名称是不变的，而其余Controller不提供这个功能。当某个Pod发生故障须要删除并从新启动时，Pod 的名称会发生变化，同时StatefuleSet 会保证副本按照固定的顺序启动、更新或者删除。
(5) Job用于运行结束就删除的应用，而其余Controller中的Pod一般是长期持续运行。
6. Service
Deployment能够部署多个副本，每一个Pod都有本身的IP, 外界如何访问这些副本呢?经过Pod的IP吗?
要知道Pod极可能会被频繁地销毁和重启，它们的IP会发生变化，用IP 来访问不太现实。
答案是Service。
Kubernetes Service定义了外界访问一组特定Pod 的方式。Service有本身的IP和端口，Service为Pod提供了负载均衡。
Kubernetes运行容器(Pod)与访问容器(Pod)这两项任务分别由Controller 和Service执行。
7. Namespace
若是有多个用户或项目组使用同-一个 Kubernetes Cluster,如何将他们建立的Controller、Pod等资源分开呢?
答案就是Namespace。
Namespace能够将-一个物理的Cluster 逻辑上划分红多个虚拟Cluster， 每一个Cluster 就是一个Namespace。不一样Namespace里的资源是彻底隔离的。
Kubernetes默认建立了两个Namespace
default:建立资源时若是不指定，将被放到这个Namespace 中。
kube-system: Kubernetes 本身建立的系统资源将放到这个Namespace 中。
kubelet 运行在Cluster 全部节点上，负责启动Pod和容器。
kubeadm 用于初始化Cluster。
kubectl是Kubernetes 命令行工具。经过kubectl能够部署和管理应用，查看各类资源，建立、删除和更新各类组件。
Master节点
1. API Server ( kube- apiserver )
API Server 提供HTTP/HTTPS RESTful API，即Kubernetes API。 API Server 是Kubernetes Cluster的前端接口，各类客户端工具(CLI或UI)以及Kubernetes 其余组件能够经过它管理Cluster 的各类资源。
2. Scheduler ( kube -scheduler )
Scheduler负责决定将Pod 放在哪一个Node. 上运行。 Scheduler 在调度时会充分考虑Cluster的拓扑结构，当前各个节点的负载，以及应用对高可用、性能、数据亲和性的需求。
3. Controller Manager ( kube-controller-manager )
Controller Manager负责管理Cluster 各类资源，保证资源处于预期的状态。ControllerManager由多种controller 组成，包括replication controller、 endpoints controller、 namespacecontroller、serviceaccounts controller
不一样的controller 管理不一样的资源。例如，replication controller 管理Deployment 、StatefulSet、DaemonSet 的生命周期，namespace controller管理Namespace 资源。
4. etcd
etcd负责保存Kubernetes Cluster 的配置信息和各类资源的状态信息。当数据发生变化时，etcd 会快速地通知Kubernetes 相关组件。
5. Pod网络
Pod要可以相互通讯，Kubernetes Cluster 必须部署Pod 网络，flannel 是其中一个可选方案。
Node节点
1. kubelet
kubelet是Node的agent， 当Scheduler 肯定在某个Node.上运行Pod 后，会将Pod ，
的具体配置信息(image、 volume 等)发送给该节点的kubelet, kubelet 根据这些信息建立和运行容器，并向Master 报告运行状态。
2. kube-proxy
service在逻辑.上表明了后端的多个Pod,外界经过service 访问Pod。 service 接收到的请求是如何转发到Pod的呢?这就是kube-proxy要完成的工做。
每一个Node都会运行kube-proxy 服务，它负责将访问service 的TCP/UPD数据流转发到后端的容器。若是有多个副本，kube-proxy 会实现负载均衡。
3. Pod网络
Pod.要可以相互通讯，Kubernetes Cluster 必须部署Pod 网络，flannel 是其中-一个可选方案。
kubelet是惟一没 有以容器形式运行的Kubernetes 组件，它在Ubuntu 中经过Systemd服务运行
Helm- Kubernetes 的包管理器。
每一个成功的软件平台都有一个优秀的打包系统，好比Debian、 Ubuntu 的apt, Red Hat、CentOS的yum。 Helm 则是Kubernetes. 上 的包管理器。
Helm有两个重要的概念: chart 和release。
●chart 是建立一个应用的信息集合，包括各类Kubernetes 对象的配置模板、参数定
义、依赖关系、文档说明等。chart 是应用部署的自包含逻辑单元。能够将chart想象成apt、yum中的软件安装包。
●release是chart 的运行实例，表明了一个正在运行的应用。当chart 被安装到
Kubernetes集群，就生成一个release。 chart 可以屡次安装到同一个集群，每次安装都是一个release。
Helm是包管理工具，这里的包就是指的chart。 Helm可以:
●从零建立新chart。
●与存储chart 的仓库交互，拉取、保存和更新chart。在Kubernetes 集群中安装和卸载release。
●更新、回滚和测试release.