k8s学习笔记

最新推荐文章于 2023-10-21 22:17:45 发布

白日盛夏

最新推荐文章于 2023-10-21 22:17:45 发布

阅读量664

点赞数

文章标签：学习 kubernetes docker

本文链接：https://blog.csdn.net/qq_33545635/article/details/123558033

版权

Kubernetes学习笔记

参考文档：https://www.orchome.com/1786

官方文档：http://docs.kubernetes.org.cn/109.html

中文文档（有架构图）：https://www.kubernetes.org.cn/kubernetes%e8%ae%be%e8%ae%a1%e6%9e%b6%e6%9e%84

Kubernetes 是为容器服务而生的一个可移植容器的编排管理工具。

Kuberneters 是一个完备的分布式系统支撑平台。 Kuberneters 具有完备的集群管理能力，包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制，以及多粒度的资源配额管理能力。

同时， Kuberneters 提供了完善的管理工具，这些工具涵盖了包括开发、部署测试、运维监控在内的各个环节。因此，Kuberneters是一个全新的基于容器技术的分布式架构解决方案，并且是一个一站式的完备的分布式系统开发和支撑平台。

一、常用概念

Service

Service 是分布式集群架构的核心，一个Service对象拥有如下关键特征：

拥有一个唯一指定的名字 (比如mysql-server)。
拥有一个虚拟IP (ClusterIP、ServiceIP或VIP)和端口号。
能够提供某种远程服务能力。
被映射到了提供这种服务能力的一组容器应用上。

Service的服务进程目前都基于Socket通信方式对外提供服务，比如 Redis、 Memcache、 MySQL、 Web Server，或者是实现了某个具体业务的一个特定的TCP Server进程。虽然一个 Service 通常由多个相关的服务进程来提供服务，每个服务进程都有一个独立的Endpoint (IP+Port)访问点，但 Kuberneters 能够让我们通过 Service (虚拟 Cluster IP + Service Port〉连接到指定的 Service 上。

Pod、RC与Service的逻辑关系:

Pod、RC与Service的关系

Pod

容器提供了强大的隔离功能，所以有必要把为 Service 提供服务的这组进程放入容器中进行隔离。

为此，Kuberneters 设计了Pod对象，将每个服务进程包装到相应的Pod中，使其成为Pod中运行的一个容器(Container)。为了建立Service和Pod间的关联关系， Kuberneters 给每个Pod贴上一个标签(Label)，给运行MySQL的Pod贴上name=mysql标签，给运行PHP的Pod贴上name=php标签，然后给相应的 Service 定义标签选择器( Label Selector)。

比如MySQL Service的标签选择器的选择条件为name=mysql，意为该Service要作用于所有包含name=mysqlLabel的Pod上。这样一来，就巧妙地解决了Service与Pod的关联问题。

screenshot

RC(Replication Controller)

在一个 RC 定义文件中包括以下3个关键信息。

目标Pod的定义。
目标 Pod 需要运行的副本数量( Replicas )
要监控的目标 Pod 的标签( Label ）。

在创建好 RC（系统将自动创建好 Pod）后，Kuberneters 会通过 RC 中定义的 Label 筛选出对应的 Pod 实例并实时监控其状态和数量，如果实例数量少于定义的副本数量（Replicas），则会根据 RC 中定义的 Pod 模板来创建一个新的Pod，然后将此 Pod调度到合适的 Node 上启动运行，直到 Pod 实例的数量达到预定目标。这个过程完全是自动化的，无须人工干预。

有了RC，服务的扩容就变成了一个纯粹的简单数字游戏了，只要修改 RC 中的副本数量即可。后续的Service升级也将通过修改RC来自动完成。

Master

集群控制节点，每个Kubernetes集群里需要有一个Master节点来负责整个集群的管理和控制，基本上Kubernetes的所有控制命令都发给它，它来负责具体的执行过程。

Master节点通常会占据一个独立的服务器（高可用部署建议用3台服务器）。

Master节点上运行着以下一组关键进程。

Kubernetes API Server (kube-apiserver)：提供了 HTTP Rest 接口的关键服务进程，是Kubernetes里所有资源的增、删、改、查等操作的唯一入口，也是集群控制的入口进程。
Kubernetes Controller Manager (kube-controller-manager)：Kubernetes里所有资源对象的自动化控制中心。
Kubernetes Scheduler (kube-scheduler)：负责资源调度（Pod调度）的进程。

另外，在Master节点上还需要启动一个etcd服务，Kubernetes里的所有资源对象的数据全部是保存在etcd中的。

Node

除了Master，Kubernetes集群中的其他机器被称为Node节点，在较早的版本中也被称为Minion。

Kubernetes Master将分配一些工作负载（应用程序）给每个Node，当某个Node宕机时，其上的工作负载会被Master自动转移到其他节点上去。

每个Node节点上的组件包括：

kubelet：负责Pod对应的容器的创建、启停等任务，同时与Master节点密切协作，实现集群管理的基本功能。
kube-proxy：实现Kubernetes Service的通信与负载均衡机制的重要组件。
Docker Engine（容器运行时）：Docker引擎，负责本机的容器创建和管理工作。

Node节点可以在运行期间动态增加到Kubernetes集群中，前提是这个节点上已经正确安装、配置和启动了上述关键进程，在默认情况下kubelet会向Master注册自己，这也是Kubernetes推荐的Node管理方式。

一旦Node被纳入集群管理范围，kubelet进程就会定时向Master节点汇报自身的情报，例如操作系统、Docker版本、机器的CPU和内存情况，以及当前有哪些Pod在运行等，这样Master可以获知每个Node的资源使用情况，并实现高效均衡等资源调度策略。

而某个Node超过指定时间不上报信息时，会被Master判断为“失联”，Node的状态被标记为不可用（Not Ready），随后Master会触发“工作负载大转移”的自动流程。

我们可以执行下述命令查看集群中有多少个Node和详细信息：

# kubectl get nodes
# kubectl describe node

Lable

Label是Kubernetes系统中另外一个核心概念。一个Label是一个key=value的键值对，其中key与value由用户自己指定。

Label可以附加到各种资源对象上，例如Node、Pod、Service、RC等，一个资源对象可以定义任意数量的Label，同一个Label也可以被添加到任意数量的资源对象上去，Label通常在资源对象定义时确定，也可以在对象创建后动态添加或者删除。

我们可以通过指定的资源对象捆绑一个或多个不同的Label来实现多维度的资源分组管理功能，以便于灵活、方便地进行资源分配、调度、配置、部署等管理工作。例如：部署不同版本的应用到不同的环境中；或者监控和分析应用（日志记录、监控、告警）等。一些常用等label示例如下。

版本标签：“release” : “stable” , “release” : “canary”…
环境标签：“environment” : “dev” , “environment” : “production”
架构标签：“tier” : “frontend” , “tier” : “backend” , “tier” : “middleware”
分区标签：“partition” : “customerA” , “partition” : “customerB”…
质量管控标签：“track” : “daily” , “track” : “weekly”

Label相当于我们熟悉的“标签”，給某个资源对象定义一个Label，就相当于給它打了一个标签，随后可以通过Label Selector（标签选择器）查询和筛选拥有某些Label的资源对象，Kubernetes通过这种方式实现了类似SQL的简单又通用的对象查询机制。

Annotation

可以使用 Kubernetes Annotation（注解）为对象附加任意的非标识的元数据自定义信息。

Annotation与Label类似，也使用key/value键值对的形式进行定义。不同的是Label具有严格的命名规则，Label定义的是Kubernetes对象的元数据（Metadata），并且用于Label Selector（标签选择器）。而Annotation（注解）则是用户任意定义的“附加”信息，便于用户自行的一些查找行为。

Deployment

Deployment是Kubernetes v1.2引入的概念，引入的目的是为了更好地解决Pod的编排问题。为此，Deployment在内部使用了Replica Set来实现目的，无论从Deployment的作用与目的，它的YAML定义，还是从它的具体命令行操作来看，我们都可以把它看作RC的一次升级，两者相似度超过90%。

Deployment相对于RC的一个最大升级是我们随时知道当前Pod“部署”的进度，典型使用场景：

创建一个Deployment对象来生成对应的Replica Set并完成Pod副本的创建过程。
检查Deployment的状态来看部署动作是否完成（Pod副本的数量是否达到预期的值）。
更新Deployment以创建新的Pod（比如镜像升级）。
如果当前Deployment不稳定，则回滚到一个早先的Deployment版本。
暂停Deployment以便于一次性修改多个PodTemplateSpec的配置项，之后再恢复Deployment，进行新的发布。
扩展Deployment以应对高负载。
查看Deployment的状态，以此作为发布是否成功的指标。
清理不再需要的旧版本ReplicaSets。

StatefulSet

解决有状态的、复杂中间件集群的管理

集群特点：

每个节点都有固定的身份ID，通过这个ID，集群中的成员可以相互发现并且通信。
集群的规模是比较固定的，集群规模不能随意变动。
集群里的每个节点都是有状态的，通常会持久化数据到永久存储中。
如果磁盘损坏，则集群里的某个节点无法正常运行，集群功能受损。

StatefulSet特性：

StatefulSet里的每个Pod都有稳定、唯一的网络标识，可以用来发现集群内的其他成员。假设StatefulSet的名字叫kafka，那么第一个Pod叫kafka-0，第二个Pod叫kafka-1，第三个叫kafka-2，以此类推。
StatefulSet控制的Pod副本的启停顺序是受控的，操作第n个Pod时，前n-1个Pod已经时运行且准备好的状态。
StatefulSet里的Pod采用稳定的持久化存储卷，通过 PV/PVC 来实现，删除Pod时默认不会删除与StatefulSet相关的存储卷（为了保证数据的安全）。

Volume(存储卷)

Volume是Pod中能够被多个容器访问的共享目录，我们先在Pod上声明一个Volume，然后在容器里引用该Volume并Mount到容器里的某个目录上。

persistent volumes

PersistentVolume给用户和管理员提供了一套API，抽象出存储是如何提供和消耗的细节。在这里，我们介绍两种新的API资源：PersistentVolume（简称PV）和PersistentVolumeClaim（简称PVC）。

PersistentVolume（持久卷，简称PV）是集群内，由管理员提供的网络存储的一部分。就像集群中的节点一样，PV也是集群中的一种资源。它也像Volume一样，是一种volume插件，但是它的生命周期却是和使用它的Pod相互独立的。PV这个API对象，捕获了诸如NFS、ISCSI、或其他云存储系统的实现细节。
PersistentVolumeClaim（持久卷声明，简称PVC）是用户的一种存储请求。它和Pod类似，Pod消耗Node资源，而PVC消耗PV资源。Pod能够请求特定的资源（如CPU和内存）。PVC能够请求指定的大小和访问的模式（可以被映射为一次读写或者多次只读）。

Namespace（命名空间）

Namespace在很多情况下用于实现多租户的资源隔离。Namespace通过将集群内部的资源对象“分配”到不同的Namespace中，形成逻辑上分组的不同项目、小组或用户组，便于不同的分组在共享使用整个集群的资源的同时还能被分别管理。

Kubernetes集群在启动后，会创建一个名为“default”的Namespace，通过kubectl可以查看到：

$ kubectl get namespaces

Horizontal Pod Autoscaler（HPA）

Pod水平自动扩缩（Horizontal Pod Autoscaler），简称HPA，意思是Pod横向水平自动扩容，与之前的RC、Deployment一样，也属于一种Kubernetes资源对象。可以基于 CPU 利用率自动扩缩 ReplicationController、Deployment、ReplicaSet 和 StatefulSet 中的 Pod 数量。如果Pod负载超过预定值，就开始增加Pod的个数，如果低于某个值，就自动减少Pod的个数。

二、核心组件

etcd保存了整个集群的状态；
apiserver提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制；
controller manager负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；
scheduler负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上；
kubelet负责维持容器的生命周期，同时也负责Volume（CVI）和网络（CNI）的管理；
Container runtime负责镜像管理以及Pod和容器的真正运行（CRI）；
kube-proxy负责为Service提供cluster内部的服务发现和负载均衡；

除了核心组件，还有一些推荐的add-ons（扩展）：

kube-dns负责为整个集群提供DNS服务
Ingress Controller为服务提供外网入口
Heapster提供资源监控
Dashboard提供GUI
Federation提供跨可用区的集群
Fluentd-elasticsearch提供集群日志采集、存储与查询

三、安装k8s

1、通过镜像源安装kubelet、kubeadm、kubectl

https://www.orchome.com/10036

2、使用kubeadm创建k8s集群

https://www.orchome.com/9907

四、kubernetes命令大全

https://www.orchome.com/617

采集、存储与查询