Kubernetes-基本使用
Kubernetes 官网
Kubernetes 官方文档
Kubernetes 官方中文文档
介绍
Kubernetes (K8S) 是一个开源的容器编排和管理平台. 用于管理多部主机上的容器. (使用容器, 虚拟机部署的好处在于环境隔离)
Kubernetes 一词源于希腊语, 意为 “舵手”, 这从其 logo 就能看出
和 Kubernetes 类似功能的应用还有:
- Apache Mesos
- Docker Swarm
相关概念
Cluster
Control Plane 加上所有的控制节点即 Cluster. 其代表了 K8S 所管理的全部主机节点.
Control Plane
Control Plane (控制平面), 通过专有的 API 与各个节点进行通信.
它会实时监测节点的网络状态来平衡服务器的负载, 或者临时下发指令来应对突发的情况.
Control Plane 中有 Controller (有很多类型, 如 Deployment, 可滚动升级, 平滑扩缩容, 可回滚; Stateful, 控制有状态服务; DeamonSet, 为每一个 “匹配” 的 Node 部署守护进程进行日志收集等; Job, CronJob 等), 一种抽象概念, 而不是实体. 它们是一组特殊的进程, 运行在 Kubernetes Master 节点上, 负责维护集群的期望状态
控制器与 Pod 的关系是管理和维护. 例如, Deployment 控制器会管理一组具有相同应用的 Pod. 如果某个 Pod 失败, 控制器会创建一个新的 Pod 来替换它, 以保持集群的稳定.
Node
Node (节点), 为 K8S 管理的主机.
Pod
Pod 是 K8S 中可以部署的最小执行单元, 是每个 Node 下运行的相互独立的程序. (一个或者多个容器的集合)
在同一个 Pod 中的所有容器共享同一个网络命名空间, 包括 IP 地址和端口范围 (也就是一个 pod 一个唯一的 IP 地址), 这使得它们可以通过 localhost 相互通信. 此外, 这些容器还可以共享存储卷.
Pause 容器
在 Kubernetes 的 Pod 中, 除了用户创建的应用容器外, 还有一个特殊的容器被称为 “Pause” 容器, 或者叫 “Infra” 容器.
Pause 容器是 Pod 中的第一个启动的容器, 它的主要职责是为 Pod 中的其他容器提供共享的 Linux Namespace. 这意味着所有在同一个 Pod 中的容器都会共享同一个网络和 UTS (Unix Timesharing System) 命名空间, 这使得它们可以通过 localhost 相互通信, 并共享同一个主机名.
Pause 容器的另一个重要作用是保持 PID (Process ID) 命名空间的持续运行. 这是因为在 Linux 中, 如果父进程退出, 其子进程会被 init 进程接管, 这可能会导致一些不可预期的行为. 而 Pause 容器作为 Pod 中所有其他容器的父进程, 可以保证在其它容器运行期间一直存活, 从而避免这种问题.
Pause 容器本身并不运行任何实际的应用, 它只执行一个简单的程序(通常是一个无限循环), 主要目的是为 Pod 中的其他容器提供一个稳定的运行环境.
Replica Set
Replica Set (副本集合), 用于替换无法工作的 pod. (可用于扩容和缩容)
可以用 selector 选择对哪些 pod 生效. (基于 label 标识)
REST
REST, REpresentational State Transfer (代表性状态转移), 是一种设计模式, 强调易于理解和使用.
Kubernetes API 采用了 RESTful 设计. 这意味着你可以通过 HTTP 请求对 Kubernetes API 服务器执行 CRUD (创建, 读取, 更新, 删除) 操作. 这些操作可以用来管理 Kubernetes 中的资源对象.
例如, 可以发送一个 HTTP GET 请求来读取某个资源的状态, 或者发送一个 HTTP POST 请求来创建一个新的资源. 同样, 可以发送一个 HTTP PUT 请求来更新一个资源, 或者发送一个 HTTP DELETE 请求来删除一个资源.
有状态与无状态应用
有状态应用指: 会对本地环境产生依赖 (需要存储客户端状态信息), 如存储数据到本地磁盘. (数据库)
无状态应用指: 不会对本地环境产生任何依赖 (不需要存储客户端状态信息), 如不存储数据到本地磁盘. (如 Nginx)
K8S 架构
如下:
分层架构如:
相关组件
Control Plane 中各组件的关系大致为:
(最重要的是 api-server, 不管是 kubectl 还是 Dashboard 操作都需要先经过 api-server)
这里的 etcd (名称源自 Unix 中 /etc 目录) 是一个开源的, 高可用的分布式键值存储系统, 它可以用于配置共享和服务发现.
Node 中各组件的关系又大致为:
资源和对象
在 Kubernetes 中, 所有的内容都被抽象为 “Resource (资源)”< 如 Pod, Service, Node 都是 Resource.
而 Object (对象), 是 Resource 的 Instance (实例), 比如某个具体的 Pod, 某个具体的 Node 等. (Kubernetes 用这些 Object 表示整个集群的状态)
Object 的创建, 删除, 修改都是通过 API Server 提供的接口. (一般用 kubectl)
Object 的 Spec 和 Status
在 Kubernetes 中, 许多 API 对象 (例如 Pod, Service, Deployment 等) 都包含 “spec” 和 “status” 这两个字段.
Spec, 指规格, 这是由用户创建或修改 Kubernetes 对象时提供的字段. 它描述了用户期望的系统状态, 也就是用户想要的对象的特性. 例如, 对于一个 Pod 对象, spec 可能会包含应运行的容器, 容器的镜像, 端口映射等.
Status, 指状态, 这是 Kubernetes 系统观察到的对象的当前状态. Kubernetes 系统通过控制循环不断地使对象的实际状态接近用户在 spec 中指定的期望状态. 例如, Pod 的 status 字段可能会包含当前的运行状态, 容器状态, Pod IP 地址等.
Resource 的简单分类
- Meta-resources, 元数据型资源, 这些资源并不对应于具体的 Kubernetes 对象, 而是提供 API 的一些额外功能 (如 Horizontal Pod Autoscaler, PodTemplate, LimitRange)
- Cluster-level resources, 集群级资源, 这些资源在整个 Kubernetes 集群中是全局的, 不属于任何特定的命名空间 (如 Namespace, Node, ClusterRole, ClusterRoleBinding)
- Namespace-level resources, 命名空间级资源, 这些资源属于特定的命名空间, 只能在其所属的命名空间内部被访问和操作. 例如, Pod, Service, ReplicaSet, Deployment 等都是命名空间级资源
Ingress 对象
Ingress 对象, 管理外部访问到集群内部服务的路由. 其还可以提供 HTTP 和 HTTPS 路由到集群内部服务, 且可以基于主机名和 URL 路径进行路由.
minikube 方式搭建
kubeadm 方式搭建
这里用 3 台虚拟机搭建集群:
- k8s-master: 192.168.177.1
- k8s-node1: 192.168.177.20
- k8s-node2: 192.168.177.25
1 | |