Skip to content

Commit e0f0f77

Browse files
chua-nchua-n
committed
新增 k8s
1 parent 0d03f66 commit e0f0f77

File tree

8 files changed

+391
-3
lines changed

8 files changed

+391
-3
lines changed

‎book/.vuepress/sidebar/otherTech.ts‎

Lines changed: 13 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -36,6 +36,18 @@ export default arraySidebar([
3636
buildSimpleNavObj("五、Git分支"),
3737
]
3838
},
39-
buildSimpleNavObj("Docker", "docker"),
4039
buildSimpleNavObj("Nginx", "nginx"),
40+
buildSimpleNavObj("Docker", "docker"),
41+
{
42+
text: "Kubernetes",
43+
prefix: "Kubernetes/",
44+
collapsible: true,
45+
icon: "k8s",
46+
children: [
47+
buildSimpleNavObj("概述"),
48+
buildSimpleNavObj("kubernetes对象"),
49+
buildSimpleNavObj("kubernetes资源"),
50+
buildSimpleNavObj("kubectl命令"),
51+
]
52+
},
4153
]);

‎book/.vuepress/theme.ts‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -16,7 +16,7 @@ export default hopeTheme(
1616
darkmode: "switch",
1717
fullscreen: false,
1818
// pure: true,
19-
iconAssets: "//at.alicdn.com/t/c/font_4437669_ss389g6d0t.css",
19+
iconAssets: "//at.alicdn.com/t/c/font_4437669_jvfuh8sn5ha.css",
2020
// iconPrefix: ???
2121
logo: "https://figure-bed.chua-n.com/logo/荒流.png",
2222
favicon: "https://figure-bed.chua-n.com/logo/川.ico",

‎book/杂技/Kubernetes/README.md‎

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,3 @@
1+
---
2+
title: Kubernetes
3+
---

‎book/杂技/Kubernetes/kubectl命令.md‎

Lines changed: 14 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,14 @@
1+
---
2+
title: kubectl 命令
3+
---
4+
5+
## kubectl 命令
6+
7+
常见操作：
8+
9+
- `kubectl get`：列出资源
10+
- `kubectl describe`：显示有关资源的详细信息
11+
- `kubectl logs`：打印 Pod 中容器的日志
12+
- `kubectl exec`：在 Pod 中的容器上执行命令
13+
- `kubectl proxy`
14+

‎book/杂技/Kubernetes/kubernetes对象.md‎

Lines changed: 75 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,75 @@
1+
---
2+
title: Kubernetes 对象
3+
---
4+
5+
## 释义
6+
7+
Kubernetes 对象是 Kubernetes 系统中的持久性实体。 Kubernetes 使用这些实体表示你的集群状态。具体而言，它们描述了如下信息：
8+
9+
- 哪些容器化应用正在运行（以及在哪些节点上运行）
10+
- 可以被应用使用的资源
11+
- 关于应用运行时行为的策略，比如重启策略、升级策略以及容错策略
12+
13+
关于 Kubernetes 对象，官方有下面一段描述：
14+
15+
> A Kubernetes object is a "record of intent"--once you create the object, the Kubernetes system will constantly work to ensure that the object exists. By creating an object, you're effectively telling the Kubernetes system what you want your cluster's workload to look like; this is your cluster's *desired state*.
16+
17+
操作 Kubernetes 对象（无论是创建、修改或者删除）需要使用 [Kubernetes API](https://kubernetes.io/zh-cn/docs/concepts/overview/kubernetes-api)。
18+
19+
- 比如，当使用 `kubectl` 命令行接口（CLI）时，CLI 会调用必要的 Kubernetes API；
20+
- 也可以在程序中使用[客户端库](https://kubernetes.io/zh-cn/docs/reference/using-api/client-libraries/)， 来直接调用 Kubernetes API。
21+
22+
## 对象的规约与状态
23+
24+
几乎每个 Kubernetes 对象包含两个嵌套的对象字段，它们负责管理对象的配置——对象规约（`spec`）和对象状态（`status`）：
25+
26+
- `spec`：对于具有 `spec` 的 Kubernetes 对象，你必须在创建对象时就设置 `spec` 的内容，它们描述了你希望这个 Kubernetes 对象所具有的特征，即**期望状态（Desired State）**。
27+
- `status`：`status` 描述了对象的**当前状态（Current State）**，它是由 Kubernetes 系统和组件来设置并更新的。在任何时刻，Kubernetes [控制平面](https://kubernetes.io/zh-cn/docs/reference/glossary/?all=true#term-control-plane) 都一直在积极地管理着对象的实际状态，以使之达成期望状态。
28+
29+
例如，Kubernetes 中的 Deployment 对象能够表示运行在集群中的应用。当创建 Deployment 时，你可能会设置 Deployment 的 `spec`，指定该应用要有 3 个副本运行。Kubernetes 系统读取 Deployment 的 `spec`， 并启动我们所期望的应用的 3 个实例——更新状态以与规约相匹配。 如果这些实例中有的失效了，Kubernetes 系统会通过执行修正操作来响应 `spec` 和 `status` 间的不一致——意味着它会启动一个新的实例来替换。
30+
31+
## 描述对象
32+
33+
创建 Kubernetes 对象时，必须提供对象的 `spec`，以及关于对象的一些基本信息（例如名称）。 当使用 Kubernetes API 创建对象时（直接创建或经由 `kubectl` 创建），API 请求必须在请求主体中包含 JSON 格式的信息。
34+
35+
实际使用过程中，通常通过 **清单（Manifest）** 文件为 `kubectl` 提供对象的这些描述信息。按照惯例，这个清单使用 YAML 格式（当然也可以使用 JSON）。像 `kubectl` 这样的工具在通过 HTTP 进行 API 请求时， 会将清单中的信息转换为 JSON 或其他受支持的序列化格式。
36+
37+
### 必需字段
38+
39+
在想要创建的 Kubernetes 对象所对应的清单中，必须要配置的字段如下：
40+
41+
- `apiVersion`：创建该对象所使用的 Kubernetes API 的版本
42+
- `kind`：想要创建的对象的类别
43+
- `metadata`：帮助唯一标识对象的一些数据，包括一个 `name` 字符串、`UID` 和可选的 `namespace`
44+
- `spec`：你所期望的该对象的状态
45+
46+
对每个 Kubernetes 对象而言，其 `spec` 之精确格式都是不同的，不同的类型可能包含不同的嵌套字段（详见 [Kubernetes API 参考](https://kubernetes.io/zh-cn/docs/reference/kubernetes-api/)）。
47+
48+
例如，对于每个 Pod，其 `.spec` 字段设置了 Pod 及其期望状态（例如 Pod 中每个容器的容器镜像名称）。对于 StatefulSet 而言，其 `.spec` 字段设置了 StatefulSet 及其期望状态。在 StatefulSet 的 `.spec` 内，有一个为 Pod 对象提供的模板，该模板描述了 StatefulSet 控制器为了满足 StatefulSet 规约而要创建的 Pod。
49+
50+
### 示例
51+
52+
例如，以下是一个清单示例文件，展示了 Kubernetes Deployment 的必需字段和对象 `spec`：
53+
54+
```yaml
55+
apiVersion: apps/v1
56+
kind: Deployment
57+
metadata:
58+
name: nginx-deployment
59+
spec:
60+
selector:
61+
matchLabels:
62+
app: nginx
63+
replicas: 2 # 告知 Deployment 运行 2 个与该模板匹配的 Pod
64+
template:
65+
metadata:
66+
labels:
67+
app: nginx
68+
spec:
69+
containers:
70+
- name: nginx
71+
image: nginx:1.14.2
72+
ports:
73+
- containerPort: 80
74+
```
75+

‎book/杂技/Kubernetes/kubernetes资源.md‎

Lines changed: 172 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,172 @@
1+
---
2+
title: 资源
3+
---
4+
5+
## ~~资源和对象~~
6+
7+
类似于 Linux 中一切皆文件的理念，在 k8s 中，可以认为一切皆资源。
8+
9+
- 资源：k8s 中的所有内容都被抽象为“资源”，如 Pod、Service、Node 等都是资源。
10+
- 对象：而“对象”就是资源的实例，是持久化的实体，如某个具体的 Node，k8s 使用这些实体去表示整个集群的状态。
11+
12+
## ~~资源的分类~~
13+
14+
> 讲师自己搞的分类，不一定正确。
15+
16+
- 元数据级
17+
- Horizontal Pod Autoscaler（HPA，水平伸缩）
18+
- PodTemplate
19+
- LimitRange
20+
- 集群级
21+
- Namespace
22+
- Node
23+
- ClusterRole
24+
- ClusterRoleBinding
25+
- 命名空间级
26+
- 工作负载型
27+
- Pod
28+
- 服务发现
29+
- Service：实现 k8s 内部网络调用、负载均衡
30+
- Ingress：将 k8s 内部服务暴露给外网访问的
31+
- 存储
32+
- Volume
33+
- CSI
34+
- 特殊类型配置
35+
- ConfigMap
36+
- Secret
37+
- DownwardAPI
38+
- 其他
39+
- Role
40+
- RoleBinding
41+
42+
## Pod
43+
44+
Pod 是 Kubernetes 抽象出来的，表示一组（一个或多个）应用容器（如 Docker），以及这些容器的一些共享资源。这些资源包括：
45+
46+
- 共享存储，当作卷
47+
- 网络，作为唯一的集群 IP 地址
48+
- 有关每个容器如何运行的信息，例如容器镜像版本或要使用的特定端口
49+
50+
Pod 为特定于应用的“逻辑主机”建模，并且可以包含相对紧耦合的不同应用容器。例如，Pod 可能既包含带有 Node.js 应用的容器，也包含另一个不同的容器，用于提供 Node.js 网络服务器要发布的数据。Pod 中的容器共享 IP 地址和端口，始终位于同一位置并且共同调度，并在同一节点上的共享上下文中运行。
51+
52+
*Pod 是 Kubernetes 平台上的原子单元*。当我们在 Kubernetes 上创建 Deployment 时，该 Deployment 会在其中创建包含容器的 Pod（而不是直接创建容器）。每个 Pod 都与调度它的节点绑定，并保持在那里直到终止（根据重启策略）或删除。如果节点发生故障，则会在集群中的其他可用节点上调度相同的 Pod。
53+
54+
![](https://figure-bed.chua-n.com/杂技/Kubernetes/module_03_pods.svg)
55+
56+
Kubernetes 集群中的每个 Pod 都有一个唯一的 IP 地址，即使是在同一个 Node 上的 Pod 也是如此。
57+
58+
## 副本
59+
60+
一个 Pod 可以被复制成多份，每一份可被称之为一个副本（replica），这些“副本”除了一些描述性的信息（Pod 的名字、uid 等）不一样以外，其它信息都是一样的。
61+
62+
Pod 的*控制器*通常包含一个名为 `replicas` 的属性，`replicas` 属性则指定了特定 Pod 的副本的数量，当当前集群中该 Pod 的数量与该属性指定的值不一致时，k8s 会采取一些策略去使得当前状态满足配置的要求。
63+
64+
## 控制器
65+
66+
### ReplicaSet 与 Deployment
67+
68+
ReplicaSet 与 Deployment 是两个适用无状态应用的控制器：
69+
70+
- **ReplicaSet**：RS 用来确保容器应用的副本数始终与用户定义的数量相同。即，如果有容器异常退出，会自动创建新的 Pod 来替代；而如果异常多出来的容器也会自动回收。
71+
72+
> 其与原来的 RC（ReplicationController，已废弃）没有本质的区别，只是 RS 支持使用 Label 与 Selector 来对 Pod 进行筛选。
73+
74+
- **Deployment**：针对 RS 的更高层次的封装，提供了更丰富的部署相关的功能。
75+
76+
- 创建 ReplicaSet/Pod
77+
- 滚动升级/回滚
78+
- 平滑扩容/缩容
79+
- 暂停/恢复 Deployment 机制
80+
81+
### StatefulSet
82+
83+
StatefulSet 适用有状态应用的控制器。
84+
85+
- 特性：
86+
- 稳定的网络标识：StatefulSet 使用 *Headless Service* 使得每个 Pod 都有一个唯一的 DNS 名称，格式为 `(statefulset name)-(ordinal)`，例如 web-0、web-1 等。
87+
- 持久化存储：StatefulSet 可以通过 *volumeClaimTemplates* 自动为每个 Pod 创建 PersistentVolumeClaim，确保每个 Pod 拥有独立的存储卷。
88+
- 有序部署和扩缩：Pod 会按照顺序创建和删除，确保在创建下一个 Pod 之前，所有前面的 Pod 都处于 Running 和 Ready 状态。
89+
- 有序滚动更新：在更新过程中，Pod 会按照逆序进行更新，确保系统的稳定性。
90+
- 使用场景：
91+
- 需要稳定的持久化存储的应用（如数据库）
92+
- 需要稳定的网络标识的应用（如分布式系统）
93+
- 需要有序部署和扩缩的应用
94+
- 限制：
95+
- StatefulSet 需要配合 Headless Service 使用，以提供 Pod 的网络标识
96+
- 删除 StatefulSet 时，关联的 PersistentVolume 不会被自动删除，以确保数据安全
97+
98+
### DaemonSet
99+
100+
DaemonSet 是一种守护进程的作用，其确保在集群中的每个 Node 上运行一个 Pod 的实例（除了那些明确指定不希望运行该 Pod 实例的节点）。这通常用于在每个节点上运行系统服务，如日志收集、监控代理或存储服务等。其主要特点是：
101+
102+
- 全局性：DaemonSet 确保在集群的每个节点上都运行一个 Pod 实例，无论节点的数量如何变化。
103+
- 自动部署：当新的节点加入集群时，DaemonSet 会自动在新节点上创建 Pod 实例。
104+
- 隔离性：DaemonSet 允许你指定某些节点不运行其 Pod 实例，这是通过节点选择器（Node Selector）或节点亲和性（Node Affinity）来实现的。
105+
- 自动重启：如果 Pod 由于任何原因终止，DaemonSet 会负责重启该 Pod。
106+
- 更新管理：DaemonSet 允许你更新 Pod 模板，它会确保所有节点上的 Pod 实例都更新到新版本。
107+
- 资源竞争：DaemonSet 通常用于运行系统级别的守护进程，这些守护进程需要与节点上的其他 Pod 隔离开来，以避免资源竞争。
108+
109+
### Job
110+
111+
Job 具体可分为任务/定时任务：
112+
113+
- **Job**：一次性任务，运行完成后 Pod 销毁，不再重新启动新容器。
114+
- **CronJob**：在 Job 的基础上增加了定时执行功能。
115+
116+
## Service
117+
118+
Pod 不能直接提供给外网访问，而是应该使用 Service，后者才是真正的“服务”。
119+
120+
Service 是 Kubernetes 中的一种抽象，它定义了一种访问 Pod 组的方法。Service 为一组具有相同功能的 Pod 提供一个单一的入口地址，无论这些 Pod 在集群中的哪个节点上运行。
121+
122+
通过设置 Service 的 `spec` 中的 `type`，你可以用不同的方式公开 Service：
123+
124+
- *ClusterIP*（默认）：在集群的内部 IP 上公开 Service。这种类型使得 Service 只能从集群内访问。
125+
- *NodePort*：使用 NAT 在集群中每个选定 Node 的相同端口上公开 Service 。使用`<NodeIP>:<NodePort>` 从集群外部访问 Service，是 ClusterIP 的超集。
126+
- *LoadBalancer*：在当前云中创建一个外部负载均衡器（如果支持的话），并为 Service 分配一个固定的外部IP，是 NodePort 的超集。
127+
- *ExternalName*：将 Service 映射到 `externalName` 字段的内容（例如 `foo.bar.example.com`），通过返回带有该名称的 `CNAME` 记录实现。不设置任何类型的代理。这种类型需要 `kube-dns` 的 v1.7 或更高版本，或者 CoreDNS 的 0.8 或更高版本。
128+
129+
Service 通常与 Label Selector 配合使用，Label Selector 用于指定 Service 应该路由到哪些 Pod。
130+
131+
## Ingress
132+
133+
Ingress 允许你通过定义规则来控制如何将外部网络请求路由到集群内的 Service。
134+
135+
Ingress 是管理外部访问应用的规则集，它提供了 URL 路由、负载均衡、SSL 终端等功能。Ingress 通常依赖于 Ingress 控制器来实现，不同的云服务提供商或 Kubernetes 安装可能使用不同的 Ingress 控制器。
136+
137+
Service 与 Ingress 的区别：
138+
139+
- 访问级别：Service 通常用于集群内部的 Pod 访问，而 Ingress 用于管理集群外部到 Service 的 HTTP 和 HTTPS 访问。
140+
- 功能：Service 提供稳定的网络访问，而 Ingress 提供了更复杂的路由和流量管理功能。
141+
- 配置：Service 通过 Kubernetes API 直接创建，而 Ingress 需要额外的配置和可能的 Ingress 控制器支持。
142+
- 使用场景：Service 适合集群内部的微服务之间的通信，Ingress 适合公网访问的应用，如网站或 API 端点。
143+
144+
## 存储
145+
146+
*Volume*：数据卷，共享 Pod 中容器使用的数据。用来放持久化的数据，比如数据库数据。
147+
148+
*CSI*：CSI（Container Storage Interface）是由来自 Kubernetes、Mesos、Docker 等社区成员联合制定的一个行业标准接口规范，旨在将任意存储系统暴露给容器化应用程序。CSI 规范定义了存储提供商实现 CSI 兼容的 Volume Plugin 的最小操作集和部署建议。CSI 规范的主要焦点是声明 Volume Plugin 必须实现的接口。
149+
150+
## 配置
151+
152+
- ConfigMap：一种 API 对象，用来将非机密性的数据保存到键值对中。使用时，Pod 可以将其用作环境变量、命令行参数或者存储卷中的配置文件。ConfigMap 将你的环境配置信息和容器镜像解耦，便于应用配置的修改。
153+
- Secret：同 ConfigMap，但使用非明文存储，用于存储敏感信息，如密码、OAuth 令牌、SSH 密钥等。
154+
- DownwardAPI：使得 Pod 内部的容器可以访问 Pod 自身的某些信息，如 CPU 和内存请求、Pod 的名称、所在的节点等。这些信息可以通过环境变量或文件的形式提供给容器。
155+
156+
## 权限
157+
158+
在 Kubernetes 中，Role 和 RoleBinding 是基于角色的访问控制（RBAC）的一部分，用于定义和限制用户或服务账户对 Kubernetes 资源的访问权限。
159+
160+
### Role
161+
162+
Role 是一种 Kubernetes 资源，它定义了一组权限，这些权限可以授予尝试执行特定操作的用户或服务账户。Role 通常与特定的命名空间相关联，这意味着它的作用域限定在该命名空间内。
163+
164+
Role 中定义的权限包括对资源的 CRUD（创建、读取、更新、删除）操作，例如：
165+
166+
- `pods`：允许用户对 Pod 进行 CRUD 操作。
167+
- `services`：允许用户对 Service 进行 CRUD 操作。
168+
- `configmaps`：允许用户对 ConfigMap 进行 CRUD 操作。
169+
170+
### RoleBinding
171+
172+
RoleBinding 将 Role 分配给用户或组，从而授予他们 Role 中定义的权限。RoleBinding 也与特定的命名空间相关联，这意味着它的作用域限定在该命名空间内。

0 commit comments

Comments
 (0)