1 K8S概述
1.1 K8S的诞生背景
1.2 K8S的特点
2 K8s的工作原理
2.1 运行架构
2.2 核心概念
Container
- 一般地，1个container只应包含1个应用进程
因为：这样能更好的监控container的状态
可理解为k8s监控的最小粒度是container
Pod
- pod ＝ 0..N 个 container
- 一般地，1个pod中只会有1个container
- 1个pod会包含1或多个紧密相关的container
- 1个pod下的container会部署一个物理节点
意味着：1个pod下不同container的交互可通过localhost进行
- 同一pod存在多个container的情况一般是：
- 1个为主container
- 其他container负责做一些辅助任务
如：log agent负责上报主container生产的日志
Labels
- 所有k8s的资源都可以被打上标
比如pod、node
-
label为kv形式，且一个资源上能打上多种标签。
-
打完标签后，可通过label selectors来筛选出打上特定label的资源。
-
【案例】
可将不同版本的pod通过label打上不同的标签： version=v1/v2/…；
然后，利用label selectors就可将version=v1的pod全部取出。
- 【案例】label还可标示node资源
举个例子：
如果某些node底层是gpu，
可将这些nodes搭上label：gpu=true，
然后，在部署需要在gpu上运行的服务时，便可通过label selectors来指定特定的pods需要部署在gpu=true的nodes上。
namespace
1个pod可能会有多个label，但只会有1个namespace。
namespace的概念可类比于【租户】，通过namespace可指定到不同的租户的命名空间。
但需注意的是，namespace仅仅是个逻辑上的分类，在你指定了某个namespace后，你只能看到对应namespace的pod，但并不作其他方面的区分。
比如，不同namespace的pod仍可以互相调用。
service
service可理解为就是psm，提供了一类服务的入口。
本质上，replicaSets等负责管理pod，而service负责pod与内外部服务的交互。
在service定义时需要定义port和targetport，port代表service正在监听的端口，收到请求后，service会将请求转发到对应pod的targetport上。