mirror of
https://github.com/yeasy/docker_practice.git
synced 2026-03-10 20:04:36 +00:00
Use a better structure
This commit is contained in:
@@ -1,4 +1,4 @@
|
||||
# Kubernetes
|
||||
## Kubernetes
|
||||
|
||||
`Kubernetes` 是 Google 团队发起并维护的基于 Docker 的开源容器集群管理系统,它不仅支持常见的云平台,而且支持内部数据中心。
|
||||
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# Kubernetes 高级特性
|
||||
## Kubernetes 高级特性
|
||||
|
||||
掌握了 Kubernetes 的核心概念(Pod, Service, Deployment)后,我们需要了解更多高级特性以构建生产级应用。
|
||||
|
||||
## Helm - 包管理工具
|
||||
### Helm - 包管理工具
|
||||
|
||||
[Helm](https://helm.sh/) 被称为 Kubernetes 的包管理器(类似于 Linux 的 apt/yum)。它将一组 Kubernetes 资源定义文件打包为一个 **Chart**。
|
||||
|
||||
@@ -10,7 +10,7 @@
|
||||
* **版本管理**:轻松回滚应用的发布版本。
|
||||
* **模板化**:支持复杂的应用部署逻辑配置。
|
||||
|
||||
## Ingress - 服务的入口
|
||||
### Ingress - 服务的入口
|
||||
|
||||
Service 虽然提供了负载均衡,但通常是 4 层(TCP/UDP)。**Ingress** 提供了 7 层(HTTP/HTTPS)路由能力,充当集群的网关。
|
||||
|
||||
@@ -20,7 +20,7 @@ Service 虽然提供了负载均衡,但通常是 4 层(TCP/UDP)。**Ingres
|
||||
|
||||
常见的 Ingress Controller有 Nginx Ingress Controller, Traefik, Istio Gateway 等。
|
||||
|
||||
## Persistent Volume (PV) 与 StorageClass
|
||||
### Persistent Volume (PV) 与 StorageClass
|
||||
|
||||
容器内的文件是临时的。对于有状态应用(如数据库),需要持久化存储。
|
||||
|
||||
@@ -28,7 +28,7 @@ Service 虽然提供了负载均衡,但通常是 4 层(TCP/UDP)。**Ingres
|
||||
* **PV (Persistent Volume)**:实际的存储资源(NFS, AWS EBS, Ceph 等)。
|
||||
* **StorageClass**:定义存储类,支持动态创建 PV。
|
||||
|
||||
## Horizontal Pod Autoscaling (HPA)
|
||||
### Horizontal Pod Autoscaling (HPA)
|
||||
|
||||
HPA 根据 CPU 利用率或其他指标(如内存、自定义指标)自动扩缩 Deployment 或 ReplicaSet 中的 Pod 数量。
|
||||
|
||||
@@ -53,7 +53,7 @@ spec:
|
||||
averageUtilization: 50
|
||||
```
|
||||
|
||||
## ConfigMap 与 Secret
|
||||
### ConfigMap 与 Secret
|
||||
|
||||
* **ConfigMap**:存储非机密的配置数据(配置文件、环境变量)。
|
||||
* **Secret**:存储机密数据(密码、Token、证书),在 Etcd 中加密存储。
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# 基本概念
|
||||
## 基本概念
|
||||
|
||||

|
||||
|
||||
@@ -13,27 +13,27 @@
|
||||
* web 界面(`ux`):用户可以通过 web 界面操作 Kubernetes。
|
||||
* 命令行操作(`cli`):`kubectl`命令。
|
||||
|
||||
## 节点
|
||||
### 节点
|
||||
|
||||
在 `Kubernetes` 中,节点是实际工作的点,节点可以是虚拟机或者物理机器,依赖于一个集群环境。每个节点都有一些必要的服务以运行容器组,并且它们都可以通过主节点来管理。必要服务包括 Docker,kubelet 和代理服务。
|
||||
|
||||
### 容器状态
|
||||
#### 容器状态
|
||||
|
||||
容器状态用来描述节点的当前状态。现在,其中包含三个信息:
|
||||
|
||||
#### 主机IP
|
||||
##### 主机IP
|
||||
|
||||
主机 IP 需要云平台来查询,`Kubernetes` 把它作为状态的一部分来保存。如果 `Kubernetes` 没有运行在云平台上,节点 ID 就是必需的。IP 地址可以变化,并且可以包含多种类型的 IP 地址,如公共 IP,私有 IP,动态 IP,ipv6 等等。
|
||||
|
||||
#### 节点周期
|
||||
##### 节点周期
|
||||
|
||||
通常来说节点有 `Pending`,`Running`,`Terminated` 三个周期,如果 Kubernetes 发现了一个节点并且其可用,那么 Kubernetes 就把它标记为 `Pending`。然后在某个时刻,Kubernetes 将会标记其为 `Running`。节点的结束周期称为 `Terminated`。一个已经 `Terminated` 的节点不会接受和调度任何请求,并且已经在其上运行的容器组也会删除。
|
||||
|
||||
#### 节点状态
|
||||
##### 节点状态
|
||||
|
||||
节点的状态主要是用来描述处于 `Running` 的节点。当前可用的有 `NodeReachable` 和 `NodeReady`。以后可能会增加其他状态。`NodeReachable` 表示集群可达。`NodeReady` 表示 kubelet 返回 Status Ok 并且 HTTP 状态检查健康。
|
||||
|
||||
### 节点管理
|
||||
#### 节点管理
|
||||
|
||||
节点并非 Kubernetes 创建,而是由云平台创建,或者就是物理机器、虚拟机。在 Kubernetes 中,节点仅仅是一条记录,节点创建之后,Kubernetes 会检查其是否可用。在 Kubernetes 中,节点用如下结构保存:
|
||||
|
||||
@@ -56,7 +56,7 @@
|
||||
|
||||
Kubernetes 校验节点可用依赖于 ID。在当前的版本中,有两个接口可以用来管理节点:节点控制和 Kube 管理。
|
||||
|
||||
### 节点控制
|
||||
#### 节点控制
|
||||
|
||||
在 Kubernetes 主节点中,节点控制器是用来管理节点的组件。主要包含:
|
||||
|
||||
@@ -65,15 +65,15 @@ Kubernetes 校验节点可用依赖于 ID。在当前的版本中,有两个接
|
||||
|
||||
节点控制有一个同步轮询,主要监听所有云平台的虚拟实例,会根据节点状态创建和删除。可以通过 `--node_sync_period`标志来控制该轮询。如果一个实例已经创建,节点控制将会为其创建一个结构。同样的,如果一个节点被删除,节点控制也会删除该结构。在 Kubernetes 启动时可用通过 `--machines`标记来显示指定节点。同样可以使用 `kubectl` 来一条一条的添加节点,两者是相同的。通过设置 `--sync_nodes=false`标记来禁止集群之间的节点同步,你也可以使用 api/kubectl 命令行来增删节点。
|
||||
|
||||
## 容器组
|
||||
### 容器组
|
||||
|
||||
在 Kubernetes 中,使用的最小单位是容器组,容器组是创建,调度,管理的最小单位。 一个容器组使用相同的 Docker 容器并共享卷(挂载点)。一个容器组是一个特定应用的打包集合,包含一个或多个容器。
|
||||
|
||||
和运行的容器类似,一个容器组被认为只有很短的运行周期。容器组被调度到一组节点运行,直到容器的生命周期结束或者其被删除。如果节点死掉,运行在其上的容器组将会被删除而不是重新调度。(也许在将来的版本中会添加容器组的移动)。
|
||||
|
||||
### 容器组设计的初衷
|
||||
#### 容器组设计的初衷
|
||||
|
||||
### 资源共享和通信
|
||||
#### 资源共享和通信
|
||||
|
||||
容器组主要是为了数据共享和它们之间的通信。
|
||||
|
||||
@@ -81,11 +81,11 @@ Kubernetes 校验节点可用依赖于 ID。在当前的版本中,有两个接
|
||||
|
||||
容器组有一组存储卷(挂载点),主要是为了让容器在重启之后可以不丢失数据。
|
||||
|
||||
### 容器组管理
|
||||
#### 容器组管理
|
||||
|
||||
容器组是一个应用管理和部署的高层次抽象,同时也是一组容器的接口。容器组是部署、水平放缩的最小单位。
|
||||
|
||||
### 容器组的使用
|
||||
#### 容器组的使用
|
||||
|
||||
容器组可以通过组合来构建复杂的应用,其本来的意义包含:
|
||||
|
||||
@@ -95,7 +95,7 @@ Kubernetes 校验节点可用依赖于 ID。在当前的版本中,有两个接
|
||||
* 代理,网桥
|
||||
* 控制器,管理,配置以及更新
|
||||
|
||||
### 替代方案
|
||||
#### 替代方案
|
||||
|
||||
为什么不在一个单一的容器里运行多个程序?
|
||||
|
||||
@@ -104,27 +104,27 @@ Kubernetes 校验节点可用依赖于 ID。在当前的版本中,有两个接
|
||||
* 3.方便使用。用户不必运行独立的程序管理,也不用担心每个应用程序的退出状态。
|
||||
* 4.高效。考虑到基础设施有更多的职责,容器必须要轻量化。
|
||||
|
||||
### 容器组的生命状态
|
||||
#### 容器组的生命状态
|
||||
|
||||
包括若干状态值:`pending`、`running`、`succeeded`、`failed`。
|
||||
|
||||
#### pending
|
||||
##### pending
|
||||
|
||||
容器组已经被节点接受,但有一个或多个容器还没有运行起来。这将包含某些节点正在下载镜像的时间,这种情形会依赖于网络情况。
|
||||
|
||||
#### running
|
||||
##### running
|
||||
|
||||
容器组已经被调度到节点,并且所有的容器都已经启动。至少有一个容器处于运行状态(或者处于重启状态)。
|
||||
|
||||
#### succeeded
|
||||
##### succeeded
|
||||
|
||||
所有的容器都正常退出。
|
||||
|
||||
#### failed
|
||||
##### failed
|
||||
|
||||
容器组中所有容器都意外中断了。
|
||||
|
||||
### 容器组生命周期
|
||||
#### 容器组生命周期
|
||||
|
||||
通常来说,如果容器组被创建了就不会自动销毁,除非被某种行为触发,而触发此种情况可能是人为,或者复制控制器所为。唯一例外的是容器组由 succeeded 状态成功退出,或者在一定时间内重试多次依然失败。
|
||||
|
||||
@@ -173,16 +173,16 @@ Kubernetes 校验节点可用依赖于 ID。在当前的版本中,有两个接
|
||||
* 节点控制器标记容器组 `failed`
|
||||
* 如果容器组运行在一个控制器下,容器组将会在其他地方重新创建
|
||||
|
||||
## Replication Controllers
|
||||
### Replication Controllers
|
||||
|
||||
## 服务
|
||||
### 服务
|
||||
|
||||
## 卷
|
||||
### 卷
|
||||
|
||||
## 标签
|
||||
### 标签
|
||||
|
||||
## 接口权限
|
||||
### 接口权限
|
||||
|
||||
## web界面
|
||||
### web界面
|
||||
|
||||
## 命令行操作
|
||||
### 命令行操作
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# 架构设计
|
||||
## 架构设计
|
||||
|
||||
任何优秀的项目都离不开优秀的架构设计。本小节将介绍 Kubernetes 在架构方面的设计考虑。
|
||||
|
||||
## 基本考虑
|
||||
### 基本考虑
|
||||
|
||||
如果让我们自己从头设计一套容器管理平台,有如下几个方面是很容易想到的:
|
||||
|
||||
@@ -11,7 +11,7 @@
|
||||
* 一套资源调度系统,管理哪个容器该分配到哪个节点上;
|
||||
* 一套对容器内服务进行抽象和 HA 的系统。
|
||||
|
||||
## 运行原理
|
||||
### 运行原理
|
||||
|
||||
下面这张图完整展示了 Kubernetes 的运行原理。
|
||||
|
||||
@@ -23,9 +23,9 @@
|
||||
|
||||
从这张图上,我们没有能发现 Kubernetes 中对于控制平面的分布式实现,但是由于数据后端自身就是一套分布式的数据库 Etcd,因此可以很容易扩展到分布式实现。
|
||||
|
||||
## 控制平面
|
||||
### 控制平面
|
||||
|
||||
### 主节点服务
|
||||
#### 主节点服务
|
||||
|
||||
主节点上需要提供如下的管理服务:
|
||||
|
||||
@@ -33,7 +33,7 @@
|
||||
* `scheduler` 负责对资源进行调度,分配某个 pod 到某个节点上。是 pluggable 的,意味着很容易选择其它实现方式;
|
||||
* `controller-manager` 负责管理控制器,包括 endpoint-controller(刷新服务和 pod 的关联信息)和 replication-controller(维护某个 pod 的复制为配置的数值)。
|
||||
|
||||
### Etcd
|
||||
#### Etcd
|
||||
|
||||
这里 Etcd 即作为数据后端,又作为消息中间件。
|
||||
|
||||
@@ -41,7 +41,7 @@
|
||||
|
||||
组件可以自动的去侦测 Etcd 中的数值变化来获得通知,并且获得更新后的数据来执行相应的操作。
|
||||
|
||||
## 工作节点
|
||||
### 工作节点
|
||||
|
||||
* kubelet 是工作节点执行操作的 agent,负责具体的容器生命周期管理,根据从数据库中获取的信息来管理容器,并上报 pod 运行状态等;
|
||||
* kube-proxy 是一个简单的网络访问代理,同时也是一个 Load Balancer。它负责将访问到某个服务的请求具体分配给工作节点上的 Pod(同一类标签)。
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# Kubernetes 简介
|
||||
## Kubernetes 简介
|
||||
|
||||

|
||||
|
||||
## 什么是 Kubernetes
|
||||
### 什么是 Kubernetes
|
||||
|
||||
Kubernetes(常简称为 K8s)是 Google 开源的容器编排引擎。如果说 Docker 解决了"如何打包和运送集装箱"的问题,那么 Kubernetes 解决的就是"如何管理海量集装箱的调度、运行和维护"的问题。
|
||||
|
||||
@@ -12,7 +12,7 @@ Kubernetes(常简称为 K8s)是 Google 开源的容器编排引擎。如果
|
||||
|
||||
---
|
||||
|
||||
## 为什么需要 Kubernetes
|
||||
### 为什么需要 Kubernetes
|
||||
|
||||
当我们在单机运行几个容器时,Docker Compose 就足够了。但在生产环境中,我们需要面对:
|
||||
|
||||
@@ -26,26 +26,26 @@ Kubernetes 完美解决了这些问题。
|
||||
|
||||
---
|
||||
|
||||
## 核心概念
|
||||
### 核心概念
|
||||
|
||||
### Pod (豆荚)
|
||||
#### Pod (豆荚)
|
||||
Kubernetes 的最小调度单位。一个 Pod 可以包含一个或多个紧密协作的容器(共享网络和存储)。就像豌豆荚里的豌豆一样。
|
||||
|
||||
### Node (节点)
|
||||
#### Node (节点)
|
||||
运行 Pod 的物理机或虚拟机。
|
||||
|
||||
### Deployment (部署)
|
||||
#### Deployment (部署)
|
||||
定义应用的期望状态(如:需要 3 个副本,镜像版本为 v1)。K8s 会持续确保当前状态符合期望状态。
|
||||
|
||||
### Service (服务)
|
||||
#### Service (服务)
|
||||
定义一组 Pod 的访问策略。提供稳定的 Cluster IP 和 DNS 名称,负责负载均衡。
|
||||
|
||||
### Namespace (命名空间)
|
||||
#### Namespace (命名空间)
|
||||
用于多租户资源隔离。
|
||||
|
||||
---
|
||||
|
||||
## Docker 用户如何过渡
|
||||
### Docker 用户如何过渡
|
||||
|
||||
如果你已经熟悉 Docker,学习 K8s 会很容易:
|
||||
|
||||
@@ -58,7 +58,7 @@ Kubernetes 的最小调度单位。一个 Pod 可以包含一个或多个紧密
|
||||
|
||||
---
|
||||
|
||||
## 架构
|
||||
### 架构
|
||||
|
||||
Kubernetes 也是 C/S 架构,由 **Master (控制平面)** 和 **Worker (工作节点)** 组成:
|
||||
|
||||
@@ -67,7 +67,7 @@ Kubernetes 也是 C/S 架构,由 **Master (控制平面)** 和 **Worker (工
|
||||
|
||||
---
|
||||
|
||||
## 学习建议
|
||||
### 学习建议
|
||||
|
||||
Kubernetes 的学习曲线较陡峭。建议的学习路径:
|
||||
1. **理解基本概念**:Pod, Deployment, Service
|
||||
@@ -77,7 +77,7 @@ Kubernetes 的学习曲线较陡峭。建议的学习路径:
|
||||
|
||||
---
|
||||
|
||||
## 延伸阅读
|
||||
### 延伸阅读
|
||||
|
||||
- [Minikube 安装](../kubernetes/setup/README.md):本地体验 K8s
|
||||
- [Kubernetes 官网](https://kubernetes.io/):官方文档
|
||||
|
||||
@@ -1,14 +1,14 @@
|
||||
# Kubernetes 实战练习
|
||||
## Kubernetes 实战练习
|
||||
|
||||
本章将通过一个具体的案例:部署一个 Nginx 网站,并为其配置 Service 和 Ingress,来串联前面学到的知识。
|
||||
|
||||
## 目标
|
||||
### 目标
|
||||
|
||||
1. 部署一个 Nginx Deployment。
|
||||
2. 创建一个 Service 暴露 Nginx。
|
||||
3. (可选)通过 Ingress 访问服务。
|
||||
|
||||
## 步骤 1:创建 Deployment
|
||||
### 步骤 1:创建 Deployment
|
||||
|
||||
创建一个名为 `nginx-deployment.yaml` 的文件:
|
||||
|
||||
@@ -42,7 +42,7 @@ spec:
|
||||
kubectl apply -f nginx-deployment.yaml
|
||||
```
|
||||
|
||||
## 步骤 2:创建 Service
|
||||
### 步骤 2:创建 Service
|
||||
|
||||
创建一个名为 `nginx-service.yaml` 的文件:
|
||||
|
||||
@@ -75,7 +75,7 @@ kubectl get svc nginx-service
|
||||
|
||||
如果输出端口是 `80:30080/TCP`,你可以通过 `http://<NodeIP>:30080` 访问 Nginx。
|
||||
|
||||
## 步骤 3:模拟滚动更新 (Rolling Update)
|
||||
### 步骤 3:模拟滚动更新 (Rolling Update)
|
||||
|
||||
修改 `nginx-deployment.yaml`,将镜像版本改为 `nginx:latest`。
|
||||
|
||||
@@ -89,7 +89,7 @@ kubectl apply -f nginx-deployment.yaml
|
||||
kubectl rollout status deployment/nginx-deployment
|
||||
```
|
||||
|
||||
## 步骤 4:清理资源
|
||||
### 步骤 4:清理资源
|
||||
|
||||
练习结束后,记得清理资源:
|
||||
|
||||
|
||||
Reference in New Issue
Block a user