K8S简介

最新推荐文章于 2024-06-26 16:43:14 发布

zhaokuner

最新推荐文章于 2024-06-26 16:43:14 发布

阅读量1w

点赞数 4

分类专栏： K8S

本文链接：https://blog.csdn.net/zhaokuner/article/details/115402310

版权

K8S 专栏收录该内容

1 篇文章 1 订阅

订阅专栏

k8s的前世今生

k8s = kubernetes
i18n = internationalization

云服务

Infrastructure As a Service（iaas）：基础设施即服务，典型厂商《阿里云》《AWS》。
Platform As a Service（paas）：平台即服务，典型厂商《新浪云》。
Software As a Service（saas）：软件设施及服务，典型厂商《office365》。

PAAS

是一套可以直接提供出来的运行环境

最初服务器（+虚拟机）：手动+脚本（下图一）

之后容器化：docker (下图二)

图一

图二

带来的问题：容器增加，带来了混乱，典型的如端口占用。

资源管理器

集群管理化方案

Apache MESOS

Apache下的开源分布式资源管理框架，它被称为是分布式系统的内核。

最初是由加州大学伯克利分校的AMPLab开发的，后在Twitter得到广泛使用，直到2019年5月，弃坑，转k8s。

Apache Mesos是一个通用的集群管理器，起源于 Google 的数据中心资源管理系统Borg。

Docker SWARM [swɔːm]

Docker 的集群管理工具。

它将 Docker 主机池转变为单个虚拟 Docker 主机。

Docker Swarm 提供了标准的 Docker API，所有任何已经与 Docker 守护程序通信的工具都可以使用 Swarm 轻松地扩展到多个主机。

集成docker方便且轻量，但功能少，切仅支持docker。

2019年7月，阿里云，弃坑，仅支持k8s。

Kubernetes

Google，10年+的容器化积累，脱胎于Google Borg系统。

Borg是Google的内部系统，害怕无法领跑该领域，根据Borg，用go，重写出k8s开源项目

Kubernetes是Google开源的一个容器编排引擎，它支持自动化部署、大规模可伸缩、应用容器化管理
在Kubernetes中，我们可以创建多个容器，每个容器里面运行一个应用实例，然后通过内置的负载均衡策略，实现对这一组应用实例的管理、发现、访问，而这些是全自动的。

特点

轻量级：使用GO语言开发，GO为解释性语言，系统资源占用小。
开源
弹性伸缩
负载均衡：使用IPVS（中国老大哥开发的）

适合人群

软件工程师
测试工程师
运维工程师
软件架构师
项目经理

k8s中文社区

K8S概述

结构

Node是Pod真正运行的主机，可以物理机，也可以是虚拟机。为了管理Pod，每个Node节点上至少要运行container runtime（比如docker或者rkt）、kubelet和kube-proxy服务。

四组基本概念

POD/POD控制器
Name/Namespace
Label/Label选择器
Service/Ingress

POD

Pod是K8S里能够被运行的最小的逻辑单元(原子单元)
1个Pod里面可以运行多个容器，它们共享UTS+NET+IPC名称空间
- UTS命名空间用于设置主机名和对该命名空间中正在运行的进程可见的域
- NET 网络
- IPC（POSIX / SysV IPC）命名空间提供命名的共享内存段，信号量和消息队列的分离。
  共享内存段用来加速内部进程以内存速度通信，而不是通过管道或网络。共享内存通常由数据库和定制（通常是C / OpenMPI，C ++ /使用boost库）的高性能应用程序用于科学计算和金融服务行业。如果这些类型的应用程序分成多个容器，可能需要共享容器的IPC机制。

POD控制器

Pod控制器是Pod启动的一种模板，用来保证在K8S里启动的Pod应始终按照人们的预期运行（副本数、生命周期、健康状态检查…)
K8S内提供了众多的Pod控制器，常用的有以下几种:
1. Deployment
  - 创建Pod和ReplicaSet，并提供对pod的声明性更新以及许多其他的功能
  - 滚动升级和回滚应用
  - 扩容和缩容
  - 暂停和继续Deployment
2. DaemonSet
  - 确保全部(或者一些) Node 上运行1个Pod的副本。当有Node加入集群时，也会为他们新增一个Pod。当有Node从集群移除时，这些Pod也会被回收。删除DaemonSet将会删除它创建的所有
    Pod
  - 保证在每个Node上都运行一个容器副本，常用来部署一些集群的日志、监控或者其他系统管理应用
  - 日志收集，比如fluentd，logstash等
  - 系统监控，比如Prometheus Node Exporter，collectd，New Relic agent，Ganglia gmond等
  - 系统程序，比如kube-proxy, kube-dns, glusterd, ceph等
3. ReplicaSet
  - ReplicaSet是复本控制器，保证所有时间内，都有特定数量的Pod副本正在运行（创建、杀死）
  - 监管着不同node上的多个pod
  - 可独立使用，但主要被Deployment作为协调pod创建，删除和更新的机制
  - Deployments拥有并管理其ReplicaSets。
  - Replication Controller 的替代品，因为更NB，不解释
  - Deployments和ReplicaSets是为无状态服务而设计
4. StatefulSet
  - 有状态服务
  - 稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现
  - 稳定的网络标志，即Pod重新调度后其PodName和HostName不变，基于Headless Service（即没有Cluster IP的Service）来实现
  - 有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次依次进行（即从0到N-1，在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态），基于init containers来实现
  - 有序收缩，有序删除（即从N-1到0）
5. Job
  - 负责批量处理短暂的一次性任务 (short lived one-off tasks)，即仅执行一次的任务，它保证批处理任务的一个或多个Pod成功结束。
6. Cronjob
  - 定时任务，类似于Linux系统的crontab，在指定的时间周期运行指定的任务

Name

由于K8S内部，使用“资源”来定义每一种逻辑概念（功能）故每种“资源”，都应该有自己的“名称”
“资源”有api版本( apiVersion)、类别( kind )、元数据( metadata )、定义清单( spec )、状态( status )等配置信息
“名称”通常定义在“资源”的“元数据”信息里

Namespace

随着项目增多、人员增加、集群规模的扩大，需要一种能够隔离K8S内各种“资源”的方法，这就是名称空间
名称空间可以理解为K8S内部的虚拟集群组
不同名称空间内的“资源”，名称可以相同，相同名称空间内的同种“资源”，“名称”不能相同
合理的使用K8S的名称空间，使得集群管理员能够更好的对交付到K8S里的服务进行分类管理和浏览
K8S里默认存在的名称空间有:default、kube-system、kube-public
查询K8S里特定“资源”要带上相应的名称空间

Label

标签是k8s特色的管理方式，便于分类管理资源对象。
一个标签可以对应多个资源，一个资源也可以有多个标签，它们是多对多的关系。
一个资源拥有多个标签，可以实现不同维度的管理。标签的组成:key=value
与标签类似的，还有一种“注解”( annotations )

Label选择器

给资源打上标签后，可以使用标签选择器过滤指定的标签
标签选择器目前有两个:基于等值关系（等于、不等于)和基于集合关系（属于、不属于、存在)
许多资源支持内嵌标签选择器字段
- matchLabels
- matchExpressions

Service

在K8S的世界里，虽然每个Pod都会被分配一个单独的IP地址，但这个IP地址会随着Pod的销毁而消失
Service(服务）就是用来解决这个问题的核心概念
一个Service可以看作一组提供相同服务的Pod的对外访问接口Service，作用于哪些Pod是通过标签选择器来定义的

Ingress

Ingress是K8S集群里工作在OSI网络参考模型下，第7层的应用，对外暴露的接口
Service只能进行L4流量调度，表现形式是ip+port
Ingress则可以调度不同业务域、不同URL访问路径的业务流量

组件

核心组件

配置存储中心->etcd服务，保存了整个集群的状态
主控节点（master）
- kube-apiservice服务
  - 提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制
  - 提供了集群管理的RESTAPI接口(包括鉴权、数据校验及集群状态变更)
  - 负责其他模块之间的数据交互，承担通信枢纽功能
  - 是资源配额控制的入口
  - 提供完备的集群安全机制
- kube-controller-manager服务
  - 由一系列控制器组成，通过apiserver监控整个集群的状态，并确保集群处于预期的工作状态
  - 管理控制器的控制器
    - Node Controller
    - Deployment Controller
    - Service Controller
    - Volume Controller
    - Endpoint Controller
    - Garbage Controller
    - Namespace Controller
    - Job Controller
    - Resource quta Controller
    - 等等
- kube-scheduler服务
  - 负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上；
  - 预算策略( predict )
  - 优选策略( priorities )
运算节点（node）
- kube-kubelet服务
  - 负责维护容器的生命周期，同时也负责Volume（CVI）和网络（CNI）的管理；
  - 简单地说，kubelet的主要功能就是定时从某个地方获取节点上pod的期望状态（运行什么容器、运行的副本数量、网络或者存储如何配置等等），并调用对应的容器平台接口达到这个状态
  - 定时汇报当前节点的状态给apiserver，以供调度的时候使用
  - 镜像和容器的清理工作，保证节点上镜像不会占满磁盘空间，退出的容器不会占用太多资源
- kube-proxy服务
  - 是K8S在每个节点上运行网络代理，负责为Service提供cluster内部的服务发现和负载均衡
  - 建立了pod网络和集群网络的关系( clusterip→podip )
  - 常用三种流量调度模式：Userspace(废弃)，Iptables(濒临废弃)，Ipvs（推荐)
  - 负责建立和删除包括更新调度规则、通知apiserver自己的更新，或者从apiserver哪里获取其他kube-proxy的调度规则变化来更新自己的
- Volumes服务
  - 与所在的Pod的生命周期相同
  - 独立与任何容器，与Pod相关，数据在容器（docker）重启的过程中会保留
- Persistent Volume（PV）与Persistent Volume Claim(PVC)
  - PV相对独立于Pods,单独创建
  - PV相当于存储的代理服务，其对具体的存储进行配置和分配，Pods等则可以使用其抽象出来的存储资源，不需要知道集群的存储细节
  - PVC定义出需要的存储标准，然后从现有的PV中绑定合适的资源
  - Pods使用的是PVC而非PV。