Kubernetes概念篇

最新推荐文章于 2024-04-24 16:28:44 发布

Will_Fighting

最新推荐文章于 2024-04-24 16:28:44 发布

阅读量116

点赞数

文章标签： kubernetes linux 运维

本文链接：https://blog.csdn.net/weixin_43938497/article/details/130545252

版权

Kubernetes概念篇

发展历程

在这里插入图片描述

传统单机部署 Traditional Deployment

早期服务的部署采用单机部署，在单个服务器上运行应用程序；虽然简单易用，但是由于无法限制在物理服务器中运行的应用程序的资源，如果硬件资源过剩就会造成浪费，并且如果部署多个应用程序，则可能会出现应用程序之间的版本、配置、一来等冲突，导致系统不稳定或无法运行；为了提高资源利用率和安全性，虚拟化部署应运而生。

虚拟化部署 Virtualized Deployment

虚拟化部署是用虚拟机技术（VM）将服务器划分为多个隔离的环境，每个环境可以运行多个不同的应用程序和操作系统，从而减少了硬件成本和空间占用，同时也隔离了不同应用程序之间的影响和风险。

但是同样也增加了管理复杂度和开销，需要使用专门的虚拟化软件和工具来创建、配置、监控和维护虚拟机，同时也会消耗一定的系统资源和性能。

容器化部署 Container Deployment

容器类似于VM，但是更轻便易于管理；相比于虚拟化部署，容器化部署具有以下诸多优点：

因此容器化部署已经逐渐替代了虚拟化部署，成为大型项目的主流部署方式。

虽然现在容器技术日益成熟，但是仍面临一些挑战，例如：

缺少体系化的容器安全能力建设：传统的企业应用安全模型基于内部架构不同的信任域来划分对应的安全边界，而上云后企业应用需要在不同的环境中部署和交互，需要构建零信任的网络安全模型和容器安全体系。
更多的攻击面：容器化应用程序可能受到内核系统漏洞、容器运行时组件和容器应用部署配置等多个维度的逃逸和越权攻击，需要及时修复漏洞和进行版本更新。
缺少应用侧全生命周期的安全防护手段：容器化应用程序的生命周期被大幅缩短，部署密度也越来越高，传统的面向虚机维度的安全防护策略和监控告警手段已经无法适应容器技术的需求，需要利用容器编排平台和云服务商提供的安全能力来保障应用制品、权限配置、数据加密、运行时监控等方面的安全性。
缺少对云上安全责任共担模型的理解：企业应用上云后的安全需要遵循责任共担模型，在企业应用架构云原生化的转型过程中，需要企业应用管理者和安全运维人员理解企业自身和云服务商之前的责任边界，并根据云服务商提供的最佳实践进行安全治理。

Kubernetes的出现及作用

Kubernetes（一下简称K8s）是一个开源的容器编排平台，可以在多个主机上部署和管理容器化应用程序。它最初是由Google开发的，后来捐赠给了云原生计算基金会（CNCF）在容器化部署中，k8s起到了以下作用：

提供跨主机的容器编排能力，实现容器的自动部署、扩缩容、迁移、负载均衡等功能。
提供声明式的配置管理，让用户可以定义应用程序的期望状态，而不需要关心具体的实现细节。
提供服务发现和路由机制，让用户可以通过服务名访问不同的容器，而不需要知道容器的具体位置。
提供存储卷和持久化存储的支持，让用户可以为有状态的应用程序提供可靠的数据服务。
提供资源监控和日志收集的能力，让用户可以了解容器的运行状况和性能指标。
提供安全和访问控制的机制，让用户可以对容器进行身份认证、授权和加密等操作。

k8s集群

k8s集群是有Master（主）节点和Worker（工作）节点集合而成的一个集群；

在这里插入图片描述

Master节点

Master节点负责集群的管理和控制，包括一下几个方面：

提供集群管理的API接口，接收用户和其他组件的请求，并处理或转发。
调度集群内部的资源，根据容器集的需求和节点的状况，选择合适的节点来部署容器集。
监控集群内部的状态，检测并恢复容器集的故障，保证集群的高可用性。
存储集群的配置数据和状态信息，作为集群的最终事实来源。

Master节点主要包括以下几个组件：

API Server：提供集群管理的API接口，是其他组件之间通信的枢纽。
Scheduler：负责节点资源管理，根据容器集的需求和节点的状况，选择合适的节点来部署容器集。
Controller Manager：负责集群内各种资源对象的管理，如节点、服务、卷、副本等，使它们维持在预期的状态。
etcd：分布式、容错的键值存储数据库，存储集群的配置数据和状态信息。

我们在K8s中所输入的所有命令都是通过master节点分发出去的，因为master节点上运行了API Server组件，它是集群管理的API接口，接收用户和其他组件的请求，并处理或转发。用户可以使用命令行工具kubectl或者Web UI来与API Server交互，发送各种命令，如创建、删除、更新、查询资源对象。API Server会将用户的命令转换为相应的API请求，写入到etcd中，然后由其他master节点上的组件（如Controller Manager和Scheduler）或者worker节点上的组件（如Kubelet和Kube-Proxy）来执行。

Worker节点

worker（工作）节点的作用是执行用户的容器化应用程序，提供计算、存储和网络资源。worker节点主要包括以下几个组件：

Kubelet：负责管理节点上的容器，与master节点通信，汇报节点和容器的状态，接收并执行master节点的指令。
Kube-Proxy：负责为Pod提供网络代理和负载均衡，维护网络规则和服务访问入口。
Container Runtime：负责为容器提供运行时环境，如Docker或containerd。
Logging Layer：负责采集节点上所有容器的日志和监控指标。
Add-Ons：负责提供一些额外的功能，如DNS、仪表盘、服务网格等。

Pod容器组

pod 和Woker的关系

在这里插入图片描述

上图是一个Worker Node（节点）上包含有4个Pod（容器组）

Pod是K8s中最小的可部署的计算单元，它包含一个或多个容器，这些容器共享存储、网络和运行配置。

在 k8s 集群中发布 Deployment 后，Deployment 将指示 k8s 如何创建和更新应用程序的实例，master 节点将应用程序实例调度到集群中的具体的节点上。

创建应用程序实例后，Kubernetes Deployment Controller 会持续监控这些实例。如果运行实例的 worker 节点关机或被删除，则 Kubernetes Deployment Controller 将在群集中资源最优的另一个 worker 节点上重新创建一个新的实例。这提供了一种自我修复机制来解决机器故障或维护问题。

在这里插入图片描述