基本概念
1. Cluster
Cluster是计算、存储和网络资源的集合,Kubernetes 利用这些资源运行各种基于容器的应用。
2. Master
Master是Cluster的大脑,它的主要职责是调度,即决定将应用放在哪里运行。Master运行Linux操作系统,可以是物理机或者虚拟机。为了实现高可用,可以运行多个Master。
3. Node
Node的职责是运行容器应用。Node由Master管理,Node负责监控并汇报容器的状态,同时根据Master的要求管理容器的生命周期。Node运行在Linux操作系统上,可以是物理机或者是虚拟机。
4. Pod
Pod是Kubernetes 的最小工作单元。每个Pod 包含-一个或多个容器。Pod中的容器会作为一个整体被Master 调度到一个Node上运行。
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.