容器管理/虚拟机管理

kubernetes (k8s) 与 Docker 关系

Docker就像飞机,而Kubernetes就像飞机场。

  • Docker: 是一个开源的应用容器引擎,开发者可以打包他们的应用及依赖到一个可移植的容器中,发布到流行的Linux机器上,也可实现虚拟化。
  • kubernetes: 是一个开源的容器集群管理系统,可以实现容器集群的自动化部署、自动扩缩容、维护等功能。
# Kubernetes 的 11 个部分

1. Pod Pod 是 Kubernetes 中最小的可互动单元。一个 Pod 可以由多个容器组成,这些容器共同部署在单个节点上形成一个单元。一个 Pod 具有一个 IP,该 IP 在其容器之间共享。

在微服务世界中,一个 Pod 可以是执行后台工作或服务请求的微服务的单个实例。

2. Node(节点) Node 是机器。它们是 Kubernetes 用于部署 Pod 的“裸机”(或虚拟机)。Node 为 Kubernetes 提供可用的集群资源用于以保持数据、运行作业、维护工作负载、创建网络路由等。

3. Label(标签)与 Annotation(注解) Label 是 Kubernetes 及其最终用户用于过滤系统中相似资源的方式,也是资源与资源相互“访问”或关联的粘合剂。比如说,为 Deployment 打开端口的 Service。不论是监控、日志、调试或是测试,任何 Kubernetes 资源都应打上标签以供后续查验。例如,给系统中所有 Worker Pod 打上标签:app=worker,之后即可在 kubectl 或 Kubernetes API 中使用 --selector 字段对其进行选择。

Annotation 与 Label 非常相似,但通常用于以自由的字符串形式保存不同对象的元数据,例如“更改原因: 安全补丁升级”。

4. Service Discovery(服务发现) 作为编排系统,Kubernetes 控制着不同工作负载的众多资源,负责管理 Pod、作业及所有需要通信的物理资源的网络。为此,Kubernetes 使用了 ETCD。

ETCD 是 Kubernetes 的“内部”数据库,Master 通过它来获取所有资源的位置。Kubernetes 还为服务提供了实际的“服务发现”——所有 Pod 使用了一个自定义的 DNS 服务器,通过解析其他服务的名称以获取其 IP 地址和端口。它在 Kubernetes 集群中“开箱即用”,无须进行设置。

5. ReplicaSet(副本集) 虽然 Pod 是一个物理性的运行任务,但通常使用单个实例是不够的。为了冗余并处理负载,出于某种原因(比如“伸缩”)需要对 Pod 进行复制。为了实现负责扩展和复制的层,Kubernetes 使用了 ReplicaSet。这个层以副本的数量表示系统的期望状态,并在任意给定时刻保持该系统的当前状态。

这也是配置自动伸缩的所在,在系统高负载时创建额外的副本,并在不再需要这些资源来支撑所运行的工作负载时进行缩容。

6. DaemonSet(守护进程集) 有时候,应用程序每个节点需要的实例不超过一个。比如 FileBeat 这类日志收集器就是个很好的例子。为了从各个节点收集日志,其代理需要运行在所有节点上,但每个节点只需要一个实例。Kubernetes 的 DaemonSet 即可用于创建这样的工作负载。

7. StatefulSet(有状态集) 尽管多数微服务涉及的都是不可变的无状态应用程序,但也有例外。有状态的工作负载有赖于磁盘卷的可靠支持。虽然应用程序容器本身可以是不可变的,可以使用更新的版本或更健康的实例来替代,但是所有副本还是需要数据的持久化。

StatefulSet 即是用于这类需要在整个生命周期内使用同一节点的应用程序的部署。它还保留了它的“名称”:容器内的 hostname 以及整个集群中服务发现的名称。3 个 ZooKeeper 构成的 StatefulSet 可以被命名 zk-1、zk-2 及 zk-3,也可以扩展到更多的成员 zk-4、zk-5 等等…… StatefulSets 还负责管理 PersistentVolumeClaim(Pod 上连接的磁盘)。

8. Job(任务) Kubernetes 核心团队考虑了大部分使用编排系统的应用程序。虽然多数应用程序要求持续运行以同时处理服务器请求(比如 Web 服务器),但有时还是需要生成一批作业并在其完成后进行清理。比如,一个迷你的无服务器环境。为了在 Kubernetes 中实现这一点,可以使用 Job 资源。

正如其名,Job 的工作是生成容器来完成特定的工作,并在成功完成时销毁。举个例子,一组 Worker 从待处理和存储的数据队列中读取作业。一旦队列空了,就不再需要这些 Worker 了,直到下个批次准备好。

9. ConfigMap(配置映射)及 Secret(机密配置) 如果你还不熟悉十二要素应用清单,请先行了解。现代应用程序的一个关键概念是无环境,并可通过注入的环境变量进行配置。应用程序应与其位置完全无关。为了在 Kubernetes 中实现这个重要的概念,就有了 ConfigMap。实际上这是一个环境变量键值列表,它们会被传递给正在运行的工作负载以确定不同的运行时行为。在同样的范畴下,Secret 与正常的配置条目类似,只是会进行加密以防类似密钥、密码、证书等敏感信息的泄漏。

我个人认为 Hashicorp 的 Vault 是使用机密配置的最佳方案

10. Deployment(部署) 一切看起来都很美好,Pod 可以正常运行,如果上层有 ReplicaSet,还可以根据负载进行伸缩。不过,大家蜂拥而来,为的是能用新版本快速替换应用程序。我们想小规模地进行构建、测试和发布,以缩短反馈周期。使用 Deployments 即可持续地部署新软件,这是一组描述特定运行工作负载新需求的元数据。举个例子,发布新版本、错误修复,甚至是回滚(这是 Kubernetes 的另一个内部选项)。

在 Kubernetes 中部署软件可使用 2 个主要策略:

  • 替换——正如其名,使用新需求替换全部负载,自然会强制停机。对于快速替换非生产环境的资源,这很有帮助。
  • 滚动升级——通过监听两个特定配置慢慢地将容器替换成新的:
  • a. MaxAvailable——设置在部署新版本时可用的工作负载比例(或具体数量),100% 表示“我有 2 个容器,在部署时要保持 2 个存活以服务请求”;
  • b. MaxSurge——设置在当前存活容器的基础上部署的工作负载比例(或数量),100% 表示“我有 X个容器,部署另外 X 个容器,然后开始滚动移除旧容器”。

11. Storage(存储) Kubernetes 在存储之上添加了一层抽象。工作负载可以为不同任务请求特定存储,甚至可以管理超过 Pod 生命周期的持久化。

https://blog.csdn.net/zf_yusen/article/details/104118839/

https://developer.aliyun.com/live/2603?utm_content=g_1000112014