Kubernetes

珍珠是蚌的眼泪

已于 2024-08-26 22:27:23 修改

阅读量962

点赞数 7

分类专栏：云原生文章标签： kubernetes POD container node k8s 容器

于 2024-08-21 22:44:32 首次发布

本文链接：https://blog.csdn.net/qq_43563660/article/details/141404233

版权

云原生专栏收录该内容

2 篇文章 0 订阅

订阅专栏

参见尚硅谷视频，有配合pdf文档。

一、 k8s概述

1.1 k8s基本介绍

Kubernetes 简称 k8s，是支持云原生部署的一个平台，起源于谷歌。谷歌早在十几年之前就对其应用，通过容器方式进行部署。k8s 本质上就是用来简化微服务的开发和部署的，关注点包括自愈和自动伸缩、调度和发布、调用链监控、配置管理、Metrics 监控、日志监控、弹性和容错、API 管理、服务安全等，k8s 将这些微服务的公共关注点以组件形式封装打包到 k8s 这个大平台中，让开发人员在开发微服务时专注于业务逻辑的实现，而不需要去特别关注微服务底层的这些公共关注点，大大简化了微服务应用的开发和部署，提高了开发效率。
在 Kubernetes 中，我们可以创建多个容器，每个容器里面运行一个应用实例，然后通过内置的负载均衡策略，实现对这一组应用实例的管理、发现、访问，而这些细节都不需要运维人员去进行复杂的手工配置和处理。

1.2 k8s集群架构

在这里插入图片描述
master 节点由以下组件组成:

API server，以restful方式对外提供操作和获取 k8s 集群资源的的 API，是唯一操作 etcd 的组件，其他的组件包括管理员操作都是通过 API server 进行交互的，可以将它理解成 etcd 的 “代理人”。
scheduler，在 k8s 集群中做调动决策，负责资源的调度，按照预定的调度策略将 Pod 调度到相应的机器上。
controller-manager，相当于集群状态的协调者，观察着集群的实际状态，与 etcd 中的预期状态进行对比，如果不一致则对资源进行协调操作让实际状态和预期状态达到最终的一致，维护集群的状态，比如故障检测、自动扩展、滚动更新等。
etcd，一种分布式存储机制，底层采用 Raft 协议，k8s 集群的状态数据包括配置、节点等都存储于 etcd 中，它保存了整个集群的状态。

Worker 节点由以下组件组成:

Controller Runtime，下载镜像和运行容器的组件，负责镜像管理以及 Pod 和容器的真正运行（CRI）。
Pod，k8s 中特有的一个概念，可以理解为对容器的包装，是 k8s 的基本调度单位，实际的容器是运行在 Pod 中的，一个节点可以启动一个或多个 Pod。
kubelet，负责管理 worker 节点上的组件，与 master 节点上的 API server 节点进行交互，接受指令执行操作。
kube-proxy，负责对 Pod 进行寻址和负载均衡

用户操作 k8s 集群一般是通过 kubectl 命令行工具或者 dashboard；Pod 之间进行通讯是通过集群内部的覆盖网络 Overlay Network，外部流量想要进入集群访问 Pod 则是通过负载均衡 Load Balander 设备进行。

二、 k8s核心概念

在这里插入图片描述

2.1 集群 Cluster

集群由多个节点组成且可以按需添加节点（物理机/虚拟机），每一个节点都包含一定数量的 CPU 和内存 RAM。

2.2 容器 Container

k8s 本身是一个容器调度平台，从宿主机操作系统来看，容器就是一个一个的进程。从容器内部来看容器就是一个操作系统，它有着自己的网络、CPU、文件系统等资源。
在这里插入图片描述

2.3 pod

2.3.1 pod基本概念

k8s 不是直接调度容器的，而是将其封装成了一个个 POD，POD 才是 k8s 的基本调度单位。每个 POD 中可以运行一个或多个容器，共享 POD 的文件系统、IP 和网络等资源，每一个 POD 只有一个 IP，它的生命周期是短暂的（服务重启后的pod是新的）。

2.3.2 pod存在意义

我们使用docker创建容器，一个docker对应一个容器，一个容器有一个进程，一个容器运行一个应用实例，当然一个容器也可以运行多个，但是不方便管理，所以docker采用单进程设计。
pod是多进程设计，可以运行多个应用实例，一个pod有多个容器，一个容器里面运行一个应用程序。
pod的存在是为了亲密性应用（两个应用之间可以进行交互，或是两个应用之间需要频繁性交互）。

2.3.3 pod的实现机制

2.3.3.1 共享网络

pod里面有多个docker，而docker之间是隔离的。所以一个pod首先会创建一个pause容器（根容器，info容器），然后再创建业务容器，并加入到pause中。pause会有独立的ip、mac、port和namespace等，所以相当于一个pod中的容器共享一个namespace，在一个namespace下的容器可以实现网络共享。

2.3.3.2 共享存储

引入了volumn(数据卷)，做持久化存储。假设有多个node，其中一个node宕机了，需要将这个node的pod移到其他node上，但是又想使用原来的数据，就需要对数据做持久化存储。下图是一个共享存储示例yaml文件demo。
在这里插入图片描述

2.3.4 pod的资源限制

requests是node中的调度请求的资源大小，limits是最大请求资源大小。
在这里插入图片描述

2.3.5 pod的重启策略

在这里插入图片描述

2.3.6 pod的健康检查

在这里插入图片描述

2.4 controller

2.4.1 什么是controller

Replication Controller(RC)是 Kubernetes 系统中核心概念之一，当我们定义了一个 RC并提交到 Kubernetes 集群中以后，Master 节点上的 Controller Manager 组件就得到通知，定期检查系统中存活的 Pod,并确保目标 Pod 实例的数量刚好等于 RC 的预期值，如果有过多或过少的 Pod 运行，系统就会停掉或创建一些 Pod.此外我们也可以通过修改 RC 的副本数量，来实现 Pod 的动态缩放功能。总结：在集群上管理和运行容器的对象。

2.4.2 controller和pod的关系

pod是通过controller实现应用的运维，比如伸缩、滚动升级等。pod和controller之间通过lable(标签)和selector(选择器)建立关系的。下图展示的是一个最简单的应用发布yaml:
在这里插入图片描述

2.5 service

2.5.1 什么是service

POD 在 k8s 中是不固定的，可能会挂起或者重启，且挂起重启都是不可预期的，那么这就会导致服务的 IP 也随着不停的变化，给用户的寻址造成一定的困难。而 service 就是用来解决这个问题的，它屏蔽了应用的 IP 寻址和负载均衡，消费方可直接通过服务名来访问目标服务，寻址和负载均衡均由 service 底层进行。

2.5.2 service存在的意义

防止pod失联（服务发现）
当发生升级、回滚等事件时，pod的IP地址也随之变化，如果采用外部应用直接访问pod时，就会导致访问不到。采用service后，每当pod的IP地址发生变化时，pod会将新IP注册到service，然后外部访问之前，会先去service拿IP后再访问。
定义了一组pod的访问策略（负载均衡）。