1-深入浅出认识Kubernetes

最新推荐文章于 2024-01-31 22:35:09 发布

Nekoosu

最新推荐文章于 2024-01-31 22:35:09 发布

阅读量478

点赞数

分类专栏： Kubernetes从入门到放弃文章标签： kubernetes k8s diandian xingdain docker

本文链接：https://blog.csdn.net/Houaki/article/details/115142350

版权

Kubernetes从入门到放弃专栏收录该内容

24 篇文章 2 订阅

订阅专栏

<文章感谢 xingdian >

深入浅出认识Kubernetes

一:kubernetes简介

1.简介

云原生基金会 CNCF

Kubernetes是谷歌严格保密十几年的秘密武器—Borg的一个开源版本，是Docker分布式系统解决方案。

官方网站：https://kubernetes.io/

2.Kubernetes能为您做什么

使用现代的Web服务，用户希望应用程序可以24/7全天候可用，而开发人员则希望每天多次部署这些应用程序的新版本。容器化有助于打包软件来实现这些目标，从而使应用程序可以轻松快速地发布和更新，而无需停机。Kubernetes可帮助您确保那些容器化的应用程序在所需的位置和时间运行，并帮助他们找到工作所需的资源和工具。

3.kubernetes组件

Kubernetes Master ：

kube-apiserver, kube-controller-manager, kube-scheduler

Kubernetes Node：

kube-proxy,kubelet

kube-apiserver: 负责 API 服务

kube-scheduler: 负责调度

kube-controller-manager: 负责容器编排

kubelet：它与Kubernetes Master进行通信。

kube-proxy：一个网络代理，可反映每个节点上的Kubernetes网络服务。

4.Kubernetes的基本对象包括

Pod

Service

Volume

Namespace

5.Kubernetes 的顶层设计

6.kubernetes是什么

Kubernetes 是一个可移植的、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。Kubernetes拥有一个庞大且快速增长的生态系统。

7.为什么 Kubernetes 如此有用

传统部署时代：

早期，组织在物理服务器上运行应用程序。无法为物理服务器中的应用程序定义资源边界，这会导致资源分配问题。例如，如果在物理服务器上运行多个应用程序，则可能会出现一个应用程序占用大部分资源的情况，结果可能导致其他应用程序的性能下降。一种解决方案是在不同的物理服务器上运行每个应用程序，但是由于资源利用不足而无法扩展，并且组织维护许多物理服务器的成本很高。

虚拟化部署时代：

作为解决方案，引入了虚拟化功能，它允许您在单个物理服务器的 CPU 上运行多个虚拟机（VM）。虚拟化功能允许应用程序在 VM 之间隔离，并提供安全级别，因为一个应用程序的信息不能被另一应用程序自由地访问。因为虚拟化可以轻松地添加或更新应用程序、降低硬件成本等等，所以虚拟化可以更好地利用物理服务器中的资源，并可以实现更好的可伸缩性。每个 VM 是一台完整的计算机，在虚拟化硬件之上运行所有组件，包括其自己的操作系统。

容器部署时代：

容器类似于 VM，但是它们具有轻量级的隔离属性，可以在应用程序之间共享操作系统（OS）。因此，容器被认为是轻量级的。容器与 VM 类似，具有自己的文件系统、CPU、内存、进程空间等。由于它们与基础架构分离，因此可以跨云和 OS 分发进行移植。

容器是打包和运行应用程序的好方式。在生产环境中，您需要管理运行应用程序的容器，并确保不会停机。例如，如果一个容器发生故障，则需要启动另一个容器。

Kubernetes 为您提供了一个可弹性运行分布式系统的框架。Kubernetes 会满足您的扩展要求、故障转移、部署模式等。

二:kubernetes核心概念

1.kubernetes对象之pod

认识pod

Pod直译是豆荚，可以把容器想像成豆荚里的豆子，把一个或多个关系紧密的豆子包在一起就是豆荚（一个Pod）。在Kubernetes中我们不会直接操作容器，而是把容器包装成Pod再进行管理。

Pod是Kubernetes进行创建、调度和管理的最小单位

Pod运行于Node节点上，若干相关容器的组合

Pod内包含的容器运行在同一宿主机上，使用相同的网络命名空间、IP地址和端口，能够通过localhost进行通信

Pod可以指定一组共享存储。Volumes Pod中。Pod中的所有容器都可以访问共享卷，从而使这些容器可以共享数据

Pod 就是 k8s 世界里的"应用"；而一个应用，可以由多个容器组成。

注意:

重启 Pod 中的容器不应与重启 Pod 混淆。Pod 本身不运行，而是作为容器运行的环境，并且一直保持到被删除为止。

Pod本身无法自我修复。如果将Pod调度到发生故障的节点，或者调度操作本身失败，则将Pod删除；同样，由于缺乏资源或Node维护，Pod无法幸免。Kubernetes使用称为Controller的更高级别的抽象来处理管理相对易用的Pod实例的工作。因此，虽然可以直接使用Pod，但在Kubernetes中使用Controller管理Pod更为常见。

pause容器

作用：负责同一个pod的容器通信

每个Pod中都有一个pause容器，pause容器做为Pod的网络接入点，Pod中其他的容器会使用容器映射模式启动并接入到这个pause容器

属于同一个Pod的所有容器共享网络的namespace

一个Pod里的容器与另外主机上的Pod容器能够直接通信

Pods and Controllers

Controller可以为您创建和管理多个Pod，以处理复制和推出并在集群范围内提供自我修复功能。例如，如果某个节点发生故障，则控制器会将这个Node上的所有Pod重新调度到其他节点上。

Pod 模板

Pod 模板是包含在其他对象中的 Pod 规范，例如 Replication Controllers、 Jobs、和 DaemonSets。控制器使用 Pod 模板来制作实际使用的 Pod。下面的示例是一个简单的 Pod 清单，它包含一个打印消息的容器。

Pod 的终止

Pod 代表在集群中的节点上运行的进程,所以当不再需要这些进程时,允许这些进程优雅地终止是非常重要的,用户应该能够请求删除并且知道进程何时终止，但是也能够确保删除最终完成。当用户请求删除 Pod 时，系统会记录在允许强制删除 Pod 之前所期望的宽限期，并向每个容器中的主进程发送 TERM 信号。一旦过了宽限期，KILL 信号就发送到这些进程，然后就从 API 服务器上删除 Pod。如果 Kubelet 或容器管理器在等待进程终止时发生重启，则终止操作将以完整的宽限期进行重试。

终止流程：

１．用户发送命令删除 Pod，使用的是默认的宽限期（30秒）

２．API 服务器中的 Pod 会随着宽限期规定的时间进行更新，过了这个时间 Pod 就会被认为已 “死亡”。

３．当使用客户端命令查询 Pod 状态时，Pod 显示为 “Terminating”。

４．当 Kubelet 看到 Pod 由于步骤2中设置的时间而被标记为 terminating 状态时，它就开始执行关闭 Pod 流程。

５．给 Pod 内的进程发送 TERM 信号。

（和第3步同步进行）从服务的端点列表中删除 Pod，Pod也不再被视为副本控制器的运行状态的 Pod 集的一部分。当负载平衡器（如服务代理）将 Pod 从轮换中移除时，关闭迟缓的 Pod 将不能继续为流量服务。

６．当宽限期结束后，Pod 中运行的任何进程都将被用 SIGKILL 杀死。

７．Kubelet 将通过设置宽限期为0（立即删除）来完成删除 API 服务器上的 Pod。Pod 从 API 中消失，从客户端也不再可见。

注意：

默认情况下，所有删除在30秒内都是优雅的。kubectl delete 命令支持 --grace-period= 选项，允许用户覆盖默认值并声明他们自己的宽限期。设置为 ‘0’ 会强制删除 Pod。在 kubectl 1.5以后的版本（含1.5版本）中，为了执行强制删除，您还必须为 --grace-period=0 声明一个额外的 --force 标志。

2.kubernetes核心组件

Master 组件:

Master 组件提供集群的控制平面。Master 组件对集群进行全局决策（例如，调度），并检测和响应集群事件,Master组件可以在集群中的任何节点上运行

kube-apiserver:

主节点上负责提供 Kubernetes API 服务的组件；它是 Kubernetes 控制面的前端

etcd:

etcd 是兼具一致性和高可用性的键值数据库，可以作为保存 K8S所有集群数据的后台数据库

kube-scheduler:

主节点上的组件，该组件监视那些新创建的未指定运行节点的 Pod，并选择节点让 Pod 在上面运行

kube-controller-manager:

在主节点上运行控制器的组件,从逻辑上讲，每个控制器都是一个单独的进程，但是为了降低复杂性，它们都被编译到同一个可执行文件，并在一个进程中运行

节点控制器（Node Controller）: 负责在节点出现故障时进行通知和响应。

副本控制器（Replication Controller）: 负责为系统中的每个副本控制器对象维护正确数量的 Pod。

端点控制器（Endpoints Controller）: 填充端点(Endpoints)对象(即加入 Service 与 Pod)。

服务帐户和令牌控制器（Service Account & Token Controllers）: 为新的命名空间创建默认帐户和 API 访问令牌.

Node 组件:

节点组件在每个节点上运行，维护运行的 Pod 并提供 Kubernetes 运行环境。

kubelet:

一个在集群中每个节点上运行的代理。它保证容器都运行在 Pod 中

kube-proxy:

kube-proxy 是集群中每个节点上运行的网络代理,实现 Kubernetes Service 概念的一部分。

kube-proxy 维护节点上的网络规则。这些网络规则允许从集群内部或外部的网络会话与 Pod 进行网络通信。

如果有 kube-proxy 可用，它将使用操作系统数据包过滤层。否则，kube-proxy 会转发流量本身。

容器运行环境(Container Runtime)

容器运行环境是负责运行容器的软件。

Kubernetes 支持多个容器运行环境: Docker、 containerd、cri-o、 rktlet 以及任何实现 Kubernetes CRI (容器运行环境接口)。

3.kubernetes资源对象

Event

pod的状态实时信息是一个事件记录，记录了事件最早产生的时间、最后重复时间、重复次数、发起者、类型，以及导致此事件的原因等信息。Event通常关联到具体资源对象上，是排查故障的重要参考信息

Pod IP

Pod的IP地址，是Docker Engine根据docker0网桥的IP地址段进行分配的，通常是一个虚拟的二层网络，位于不同Node上的Pod能够彼此通信，需要通过Pod IP所在的虚拟二层网络进行通信，而真实的TCP流量则是通过Node IP所在的物理网卡流出的；

Namespace

命名空间将资源对象逻辑上分配到不同Namespace，可以是不同的项目、用户等区分管理，并设定控制策略，从而实现多租户。命名空间也称为虚拟集群。

Replica Set

真正实现保证副本数量一致性功能的一个组件，确保任何给定时间指定的Pod副本数量，并提供声明式更新等功能。

Deployment

用来管理副本

Deployment是一个更高层次的API对象，它管理ReplicaSets和Pod，并提供声明式更新等功能。官方建议使用Deployment管理ReplicaSets，而不是直接使用ReplicaSets，这就意味着可能永远不需要直接操作ReplicaSet对象，因此Deployment将会是使用最频繁的资源对象。

RC-Replication Controller

Replication Controller用来管理Pod的副本，保证集群中存在指定数量的Pod副本。集群中副本的数量大于指定数量，则会停止指定数量之外的多余pod数量，反之，则会启动少于指定数量个数的容器，保证数量不变。Replication Controller是实现弹性伸缩、动态扩容和滚动升级的核心。

部署和升级Pod，声明某种Pod的副本数量在任意时刻都符合某个预期值；

• Pod期待的副本数；

• 用于筛选目标Pod的Label Selector；

• 当Pod副本数量小于预期数量的时候，用于创建新Pod的Pod模板；

Service

给Pod提供统一的入口

Service定义了Pod的逻辑集合和访问该集合的策略，是真实服务的抽象。Service提供了一个统一的服务访问入口以及服务代理和发现机制，用户不需要了解后台Pod是如何运行。

一个service定义了访问pod的方式，就像单个固定的IP地址和与其相对应的DNS名之间的关系。

Service其实就是我们经常提起的微服务架构中的一个"微服务"，通过分析、识别并建模系统中的所有服务为微服务——Kubernetes Service，最终我们的系统由多个提供不同业务能力而又彼此独立的微服务单元所组成，服务之间通过TCP/IP进行通信，从而形成了我们强大而又灵活的弹性网络，拥有了强大的分布式能力、弹性扩展能力、容错能力；

每个Pod都提供了一个独立的Endpoint（Pod IP+ContainerPort）以被客户端访问，多个Pod副本组成了一个集群来提供服务，一般的做法是部署一个负载均衡器来访问它们，为这组Pod开启一个对外的服务端口如8000，并且将这些Pod的Endpoint列表加入8000端口的转发列表中，客户端可以通过负载均衡器的对外IP地址+服务端口来访问此服务。运行在Node上的kube-proxy其实就是一个智能的软件负载均衡器，它负责把对Service的请求转发到后端的某个Pod实例上，并且在内部实现服务的负载均衡与会话保持机制。Service不是共用一个负载均衡器的IP地址，而是每个Servcie分配一个全局唯一的虚拟IP地址，这个虚拟IP被称为Cluster IP。

Cluster IP

Service的IP地址,特性：

仅仅作用于Kubernetes Servcie这个对象，并由Kubernetes管理和分配IP地址；

无法被Ping，因为没有一个"实体网络对象"来响应；

只能结合Service Port组成一个具体的通信端口；

Node IP网、Pod IP网域Cluster IP网之间的通信，采用的是Kubernetes自己设计的一种编程方式的特殊的路由规则，与IP路由有很大的不同

Label

标签对K8s的资源做标记

Kubernetes中的任意API对象都是通过Label进行标识，Label的实质是一系列的K/V键值对。Label是Replication Controller和Service运行的基础，二者通过Label来进行关联Node上运行的Pod。一个label是一个被附加到资源上的键/值对，譬如附加到一个Pod上，为它传递一个用户自定义的并且可识别的属性.Label还可以被应用来组织和选择子网中的资源

selector

是一个通过匹配labels来定义资源之间关系得表达式，例如为一个负载均衡的service指定所目标Pod,Label可以附加到各种资源对象上，一个资源对象可以定义任意数量的Label。给某个资源定义一个Label，相当于给他打一个标签，随后可以通过Label Selector（标签选择器）查询和筛选拥有某些Label的资源对象。我们可以通过给指定的资源对象捆绑一个或多个Label来实现多维度的资源分组管理功能，以便于灵活、方便的进行资源分配、调度、配置、部署等管理工作；

Node

Node是Kubernetes集群架构中运行Pod的服务节点（亦叫agent或minion）。Node是Kubernetes集群操作的单元，用来承载被分配Pod的运行，是Pod运行的宿主机。

Endpoint（IP+Port）

标识服务进程的访问点；

注：Node、Pod、Replication Controller和Service等都可以看作是一种"资源对象"，几乎所有的资源对象都可以通过Kubernetes提供的kubectl工具执行增、删、改、查等操作并将其保存在etcd中持久化存储。

Volume

数据卷，挂载宿主机文件、目录或者外部存储到Pod中，为应用服务提供存储，也可以Pod中容器之间共享数据。

StatefulSet

StatefulSet主要用来部署有状态应用，能够保证 Pod 的每个副本在整个生命周期中名称是不变的。而其他 Controller 不提供这个功能，当某个 Pod 发生故障需要删除并重新启动时，Pod 的名称会发生变化。同时 StatefulSet 会保证副本按照固定的顺序启动、更新或者删除。

StatefulSet适合持久性的应用程序，有唯一的网络标识符（IP），持久存储，有序的部署、扩展、删除和滚动更新。

4.kubernetes镜像仓库

daocloud的docker镜像库:

daocloud.io/library

docker-hub的k8s镜像库：

mirrorgooglecontainers

aliyun的k8s镜像库：

registry.cn-hangzhou.aliyuncs.com/google-containers

aliyun的docker镜像库web页面：

https://cr.console.aliyun.com/cn-hangzhou/images

google的镜像库web页面：

https://console.cloud.google.com/gcr/images/google-containers?project=google-containers

5.kubernetes控制器

ReplicaSet

ReplicaSets 可以独立使用，但今天它主要被Deployments 用作协调 Pod 创建、删除和更新的机制。当您使用 Deployment 时，您不必担心还要管理它们创建的 ReplicaSet。Deployment 会拥有并管理它们的 ReplicaSet。

ReplicationController

当 pods 数量过多时，ReplicationController 会终止多余的 pods

当 pods 数量太少时，ReplicationController 将会启动新的 pods

与手动创建的 pod 不同，由 ReplicationController 创建的 pods 在失败、被删除或被终止时会被自动替换

注意：

ReplicaSet 是下一代 ReplicationController ，支持新的基于集合的标签选择器。它主要被 Deployment 用来作为一种编排 pod 创建、删除及更新的机制。请注意，我们推荐使用 Deployment 而不是直接使用 ReplicaSet，除非您需要自定义更新编排或根本不需要更新。

StatefulSets

StatefulSet 是用来管理有状态应用的工作负载 API 对象。

StatefulSet 用来管理 Deployment 和扩展一组 Pod，并且能为这些 Pod 提供序号和唯一性保证。

和 Deployment 相同的是，StatefulSet 管理了基于相同容器定义的一组 Pod。但和 Deployment不同的是，StatefulSet 为它们的每个 Pod 维护了一个固定的 ID。这些 Pod是基于相同的声明来创建的，但是不能相互替换：无论怎么调度，每个 Pod 都有一个永久不变的 ID。

特点：

稳定的、唯一的网络标识符。

稳定的、持久的存储。

有序的、优雅的部署和缩放。

有序的、自动的滚动更新。

缺点：

给定 Pod 的存储必须由 PersistentVolume 驱动基于所请求的 storage class来提供，或者由管理员预先提供。

删除和／或收缩 StatefulSet 并不会删除它关联的存储卷。这样做是为了保证数据安全，它通常比自动清除 StatefulSet所有相关的资源更有价值。

StatefulSet 当前需要 headless 服务来负责 Pod 的网络标识。您需要负责创建此服务。

当删除 StatefulSets 时，StatefulSet 不提供任何终止 Pod 的保证。为了实现StatefulSet 中的Pod 可以有序和优雅的终止，可以在删除之前将 StatefulSet 缩放为 0。

在默认 Pod 管理策略(OrderedReady) 时使用滚动更新，可能进入需要人工干预才能修复的损坏状态。