Skip to content

Commit cdc6b77

Browse files
dunwudunwu
committed
update docs
1 parent 6ab987a commit cdc6b77

6 files changed

Lines changed: 165 additions & 288 deletions

File tree

‎README.md‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -80,6 +80,7 @@
8080
- [Docker 快速入门](docs/docker/docker-quickstart.md)
8181
- [Dockerfile 最佳实践](docs/docker/docker-dockerfile.md)
8282
- [Docker Cheat Sheet](docs/docker/docker-cheat-sheet.md)
83+
- [Kubernetes 应用指南](docs/docker/kubernetes.md)
8384
- [一篇文章让你彻底掌握 Python](https://github.com/dunwu/blog/blob/master/source/_posts/coding/python.md)
8485
- [一篇文章让你彻底掌握 Shell](https://github.com/dunwu/blog/blob/master/source/_posts/coding/shell.md)
8586
- [Git 从入门到精通](https://github.com/dunwu/blog/blob/master/source/_posts/tools/git.md)

‎docs/docker/docker-cheat-sheet.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -114,7 +114,7 @@ sudo systemctl restart docker
114114
- [`docker rm`](https://docs.docker.com/engine/reference/commandline/rm) 删除容器。
115115
- 如果要删除一个运行中的容器，可以添加 `-f` 参数。Docker 会发送 `SIGKILL` 信号给容器。
116116
- [`docker update`](https://docs.docker.com/engine/reference/commandline/update/) 调整容器的资源限制。
117-
- `docker container prune` 清理掉所有处于终止状态的容器。
117+
- 清理掉所有处于终止状态的容器。
118118

119119
通常情况下，不使用任何命令行选项启动一个容器，该容器将会立即启动并停止。若需保持其运行，你可以使用 `docker run -td container_id` 命令。选项 `-t` 表示分配一个 pseudo-TTY 会话，`-d` 表示自动将容器与终端分离（也就是说在后台运行容器，并输出容器 ID）。
120120

‎docs/docker/docker-dockerfile.md‎

Lines changed: 52 additions & 35 deletions
Original file line numberDiff line numberDiff line change
@@ -2,31 +2,30 @@
22

33
<!-- TOC depthFrom:2 depthTo:3 -->
44

5-
- [Dockerfile 指令](#dockerfile-指令)
6-
- [FROM(指定基础镜像)](#from指定基础镜像)
7-
- [RUN(执行命令)](#run执行命令)
8-
- [COPY(复制文件)](#copy复制文件)
9-
- [ADD(更高级的复制文件)](#add更高级的复制文件)
10-
- [CMD(容器启动命令)](#cmd容器启动命令)
11-
- [ENTRYPOINT(入口点)](#entrypoint入口点)
12-
- [ENV(设置环境变量)](#env设置环境变量)
13-
- [ARG(构建参数)](#arg构建参数)
14-
- [VOLUME(定义匿名卷)](#volume定义匿名卷)
15-
- [EXPOSE(暴露端口)](#expose暴露端口)
16-
- [WORKDIR(指定工作目录)](#workdir指定工作目录)
17-
- [USER(指定当前用户)](#user指定当前用户)
18-
- [HEALTHCHECK(健康检查)](#healthcheck健康检查)
19-
- [ONBUILD(为他人作嫁衣裳)](#onbuild为他人作嫁衣裳)
20-
- [引用和引申](#引用和引申)
5+
- [一、Dockerfile 指令](#一dockerfile-指令)
6+
- [FROM(指定基础镜像)](#from指定基础镜像)
7+
- [RUN(执行命令)](#run执行命令)
8+
- [COPY(复制文件)](#copy复制文件)
9+
- [ADD(更高级的复制文件)](#add更高级的复制文件)
10+
- [CMD(容器启动命令)](#cmd容器启动命令)
11+
- [ENTRYPOINT(入口点)](#entrypoint入口点)
12+
- [ENV(设置环境变量)](#env设置环境变量)
13+
- [ARG(构建参数)](#arg构建参数)
14+
- [VOLUME(定义匿名卷)](#volume定义匿名卷)
15+
- [EXPOSE(暴露端口)](#expose暴露端口)
16+
- [WORKDIR(指定工作目录)](#workdir指定工作目录)
17+
- [USER(指定当前用户)](#user指定当前用户)
18+
- [HEALTHCHECK(健康检查)](#healthcheck健康检查)
19+
- [ONBUILD(为他人作嫁衣裳)](#onbuild为他人作嫁衣裳)
20+
- [参考资料](#参考资料)
2121

2222
<!-- /TOC -->
2323

24-
## Dockerfile 指令
24+
## 一、Dockerfile 指令
2525

2626
### FROM(指定基础镜像)
2727

2828
> 作用：**`FROM` 指令用于指定基础镜像**。
29-
>
3029
3130
所谓定制镜像，那一定是以一个镜像为基础，在其上进行定制。就像我们之前运行了一个 `nginx` 镜像的容器，再进行修改一样，基础镜像是必须指定的。而 `FROM` 就是指定**基础镜像**，因此一个 `Dockerfile` 中 `FROM` 是必备的指令，并且必须是第一条指令。
3231

@@ -56,7 +55,6 @@ FROM scratch
5655
> ```
5756
>
5857
> - _exec_ 格式：`RUN ["可执行文件", "参数1", "参数2"]`，这更像是函数调用中的格式。
59-
>
6058
6159
既然 `RUN` 就像 Shell 脚本一样可以执行命令，那么我们是否就可以像 Shell 脚本一样把每个命令对应一个 RUN 呢？比如这样：
6260
@@ -107,8 +105,6 @@ RUN buildDeps='gcc libc6-dev make' \
107105

108106
### COPY(复制文件)
109107

110-
> 作用：
111-
>
112108
> **`COPY` 指令将从构建上下文目录中 `<源路径>` 的文件/目录复制到新的一层的镜像内的 `<目标路径>` 位置。**
113109
114110
格式：
@@ -144,8 +140,6 @@ COPY --chown=10:11 files* /mydir/
144140

145141
### ADD(更高级的复制文件)
146142

147-
> 作用：
148-
>
149143
> `ADD` 指令和 `COPY` 的格式和性质基本一致。但是在 `COPY` 基础上增加了一些功能。
150144
>
151145
> 比如 `<源路径>` 可以是一个 `URL`，这种情况下，Docker 引擎会试图去下载这个链接的文件放到 `<目标路径>`去。下载后的文件权限自动设置为 `600`，如果这并不是想要的权限，那么还需要增加额外的一层 `RUN` 进行权限调整，另外，如果下载的是个压缩包，需要解压缩，也一样还需要额外的一层 `RUN` 指令进行解压缩。所以不如直接使用 `RUN` 指令，然后使用 `wget` 或者 `curl` 工具下载，处理权限、解压缩、然后清理无用文件更合理。因此，这个功能其实并不实用，而且不推荐使用。
@@ -179,8 +173,6 @@ ADD --chown=10:11 files* /mydir/
179173

180174
### CMD(容器启动命令)
181175

182-
> 作用：
183-
>
184176
> 之前介绍容器的时候曾经说过，Docker 不是虚拟机，容器就是进程。既然是进程，那么在启动容器的时候，需要指定所运行的程序及参数。`CMD` 指令就是用于指定默认的容器主进程的启动命令的。
185177
186178
`CMD` 指令的格式和 `RUN` 相似，也是两种格式：
@@ -356,7 +348,7 @@ uid=0(root) gid=0(root) groups=0(root)
356348

357349
### ENV(设置环境变量)
358350

359-
> 作用：`ENV` 指令用于设置环境变量。无论是后面的其它指令，如 `RUN`，还是运行时的应用，都可以直接使用这里定义的环境变量。
351+
> `ENV` 指令用于设置环境变量。无论是后面的其它指令，如 `RUN`，还是运行时的应用，都可以直接使用这里定义的环境变量。
360352
361353
格式：
362354

@@ -396,8 +388,6 @@ RUN curl -SLO "https://nodejs.org/dist/v$NODE_VERSION/node-v$NODE_VERSION-linux-
396388

397389
### ARG(构建参数)
398390

399-
> 作用：
400-
>
401391
> `Dockerfile` 中的 `ARG` 指令是定义参数名称，以及定义其默认值。该默认值可以在构建命令 `docker build` 中用 `--build-arg <参数名>=<值>` 来覆盖。
402392
>
403393
> 构建参数和 `ENV` 的效果一样，都是设置环境变量。所不同的是，`ARG` 所设置的构建环境的环境变量，在将来容器运行时是不会存在这些环境变量的。但是不要因此就使用 `ARG` 保存密码之类的信息，因为 `docker history` 还是可以看到所有值的。
@@ -429,8 +419,6 @@ docker run -d -v mydata:/data xxxx
429419

430420
### EXPOSE(暴露端口)
431421

432-
> 作用：
433-
>
434422
> `EXPOSE` 指令是声明运行时容器提供服务端口，这只是一个声明，在运行时并不会因为这个声明应用就会开启这个端口的服务。在 Dockerfile 中写入这样的声明有两个好处，一个是帮助镜像使用者理解这个镜像服务的守护端口，以方便配置映射；另一个用处则是在运行时使用随机端口映射时，也就是 `docker run -P` 时，会自动随机映射 `EXPOSE` 的端口。
435423
>
436424
> 要将 `EXPOSE` 和在运行时使用 `-p <宿主端口>:<容器端口>` 区分开来。`-p`，是映射宿主端口和容器端口，换句话说，就是将容器的对应端口服务公开给外界访问，而 `EXPOSE` 仅仅是声明容器打算使用什么端口而已，并不会自动在宿主进行端口映射。
@@ -439,8 +427,6 @@ docker run -d -v mydata:/data xxxx
439427

440428
### WORKDIR(指定工作目录)
441429

442-
> 作用：
443-
>
444430
> 使用 `WORKDIR` 指令可以来指定工作目录（或者称为当前目录），以后各层的当前目录就被改为指定的目录，如该目录不存在，`WORKDIR` 会帮你建立目录。
445431
446432
格式：`WORKDIR <工作目录路径>`。
@@ -460,10 +446,41 @@ RUN echo "hello" > world.txt
460446

461447
因此如果需要改变以后各层的工作目录的位置，那么应该使用 `WORKDIR` 指令。
462448

449+
### LABEL
450+
451+
`LABEL`用于为镜像添加元数据，元数以键值对的形式指定：
452+
453+
```
454+
LABEL <key>=<value> <key>=<value> <key>=<value> ...
455+
```
456+
457+
使用`LABEL`指定元数据时，一条`LABEL`指定可以指定一或多条元数据，指定多条元数据时不同元数据之间通过空格分隔。推荐将所有的元数据通过一条`LABEL`指令指定，以免生成过多的中间镜像。
458+
459+
如，通过`LABEL`指定一些元数据：
460+
461+
```
462+
LABEL version="1.0" description="这是一个Web服务器" by="IT笔录"
463+
```
464+
465+
指定后可以通过`docker inspect`查看：
466+
467+
```
468+
$sudo docker inspect itbilu/test
469+
"Labels": {
470+
"version": "1.0",
471+
"description": "这是一个Web服务器",
472+
"by": "IT笔录"
473+
},
474+
```
475+
476+
*注意；*`Dockerfile`中还有个`MAINTAINER`命令，该命令用于指定镜像作者。但`MAINTAINER`并不推荐使用，更推荐使用`LABEL`来指定镜像作者。如：
477+
478+
```
479+
LABEL maintainer="itbilu.com"
480+
```
481+
463482
### USER(指定当前用户)
464483

465-
> 作用：
466-
>
467484
> `USER` 指令和 `WORKDIR` 相似，都是改变环境状态并影响以后的层。`WORKDIR` 是改变工作目录，`USER` 则是改变之后层的执行 `RUN`, `CMD` 以及 `ENTRYPOINT` 这类命令的身份。
468485
>
469486
> 当然，和 `WORKDIR` 一样，`USER` 只是帮助你切换到指定用户而已，这个用户必须是事先建立好的，否则无法切换。
@@ -597,7 +614,7 @@ CMD [ "npm", "start" ]
597614

598615
把这个 `Dockerfile` 放到 Node.js 项目的根目录，构建好镜像后，就可以直接拿来启动容器运行。但是如果我们还有第二个 Node.js 项目也差不多呢？好吧，那就再把这个 `Dockerfile` 复制到第二个项目里。那如果有第三个项目呢？再复制么？文件的副本越多，版本控制就越困难，让我们继续看这样的场景维护的问题。
599616

600-
如果第一个 Node.js 项目在开发过程中，发现这个 `Dockerfile` 里存在问题，比如敲错字了、或者需要安装额外的包，然后开发人员修复了这个 `Dockerfile`，再次构建，问题解决。� 第一个项目没问题了，但是第二个项目呢？虽然最初 `Dockerfile` 是复制、粘贴自第一个项目的，但是并不会因为第一个项目修复了他们的 `Dockerfile`，而第二个项目的 `Dockerfile` 就会被自动修复。
617+
如果第一个 Node.js 项目在开发过程中，发现这个 `Dockerfile` 里存在问题，比如敲错字了、或者需要安装额外的包，然后开发人员修复了这个 `Dockerfile`，再次构建，问题解决。第一个项目没问题了，但是第二个项目呢？虽然最初 `Dockerfile` 是复制、粘贴自第一个项目的，但是并不会因为第一个项目修复了他们的 `Dockerfile`，而第二个项目的 `Dockerfile` 就会被自动修复。
601618

602619
那么我们可不可以做一个基础镜像，然后各个项目使用这个基础镜像呢？这样基础镜像更新，各个项目不用同步 `Dockerfile`的变化，重新构建后就继承了基础镜像的更新？好吧，可以，让我们看看这样的结果。那么上面的这个 `Dockerfile` 就会变为：
603620

‎docs/docker/kubernetes.md‎

Lines changed: 45 additions & 41 deletions
Original file line numberDiff line numberDiff line change
@@ -1,21 +1,27 @@
1-
# Kubernetes
1+
# Kubernetes 应用指南
22

3-
> Kubernetes 是用于自动部署，扩展和管理 Docker 应用程序的开源系统。简称 K8S
3+
> Kubernetes 是谷歌开源的容器集群管理系统 是用于自动部署，扩展和管理 Docker 应用程序的开源系统，简称 K8S。
44
>
55
> 关键词： `docker`
66
77
<!-- TOC depthFrom:2 depthTo:2 -->
88

9-
- [功能](#功能)
10-
- [简介](#简介)
11-
- [基础](#基础)
12-
- [进阶](#进阶)
13-
- [命令](#命令)
14-
- [引用和引申](#引用和引申)
9+
- [一、K8S 简介](#一k8s-简介)
10+
- [二、K8S 命令](#二k8s-命令)
11+
- [参考资料](#参考资料)
1512

1613
<!-- /TOC -->
1714

18-
## 功能
15+
## 一、K8S 简介
16+
17+
K8S 主控组件（Master） 包含三个进程，都运行在集群中的某个节上，通常这个节点被称为 master 节点。这些进程包括：`kube-apiserver`、`kube-controller-manager` 和 `kube-scheduler`。
18+
19+
集群中的每个非 master 节点都运行两个进程：
20+
21+
- kubelet，和 master 节点进行通信。
22+
- kube-proxy，一种网络代理，将 Kubernetes 的网络服务代理到每个节点上。
23+
24+
### K8S 功能
1925

2026
- 基于容器的应用部署、维护和滚动升级
2127
- 负载均衡和服务发现
@@ -25,40 +31,37 @@
2531
- 广泛的 Volume 支持
2632
- 插件机制保证扩展性
2733

28-
## 简介
34+
### K8S 核心组件
2935

30-
Kubernetes 主控组件（Master） 包含三个进程，都运行在集群中的某个节上，通常这个节点被称为 master 节点。这些进程包括：`kube-apiserver`、`kube-controller-manager` 和 `kube-scheduler`。
36+
Kubernetes 主要由以下几个核心组件组成：
3137

32-
集群中的每个非 master 节点都运行两个进程：
38+
- etcd 保存了整个集群的状态；
39+
- apiserver 提供了资源操作的唯一入口，并提供认证、授权、访问控制、API 注册和发现等机制；
40+
- controller manager 负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；
41+
- scheduler 负责资源的调度，按照预定的调度策略将 Pod 调度到相应的机器上；
42+
- kubelet 负责维护容器的生命周期，同时也负责 Volume（CVI）和网络（CNI）的管理；
43+
- Container runtime 负责镜像管理以及 Pod 和容器的真正运行（CRI）；
44+
- kube-proxy 负责为 Service 提供 cluster 内部的服务发现和负载均衡
3345

34-
- kubelet，和 master 节点进行通信。
35-
- kube-proxy，一种网络代理，将 Kubernetes 的网络服务代理到每个节点上。
36-
37-
### Kubernetes 对象
38-
39-
Kubernetes 包含若干抽象用来表示系统状态，包括：已部署的容器化应用和负载、与它们相关的网络和磁盘资源以及有关集群正在运行的其他操作的信息。
46+
![img](https://blobscdn.gitbook.com/v0/b/gitbook-28427.appspot.com/o/assets%2F-LDAOok5ngY4pc1lEDes%2F-LpOIkR-zouVcB8QsFj_%2F-LpOIpZIYxaDoF-FJMZk%2Farchitecture.png?generation=1569161437087842&alt=media)
4047

48+
### K8S 核心概念
4149

42-
- Pod - kubernetes 对象模型中最小的单元，它代表集群中一个正在运行的进程。
43-
- Service
44-
- Volume
45-
- Namespace
50+
K8S 包含若干抽象用来表示系统状态，包括：已部署的容器化应用和负载、与它们相关的网络和磁盘资源以及有关集群正在运行的其他操作的信息。
4651

4752
<br>![img](http://dunwu.test.upcdn.net/cs/os/kubernetes/pod.svg!zp)<br>
4853

49-
高级对象
50-
51-
- ReplicaSet
52-
- Deployment
53-
- StatefulSet
54-
- DaemonSet
55-
- Job
56-
57-
## 基础
58-
59-
## 进阶
54+
- `Pod` - K8S 使用 Pod 来管理容器，每个 Pod 可以包含一个或多个紧密关联的容器。Pod 是一组紧密关联的容器集合，它们共享 PID、IPC、Network 和 UTS namespace，是 K8S 调度的基本单位。Pod 内的多个容器共享网络和文件系统，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。
55+
- `Node` - Node 是 Pod 真正运行的主机，可以是物理机，也可以是虚拟机。为了管理 Pod，每个 Node 节点上至少要运行 container runtime（比如 docker 或者 rkt）、`kubelet` 和 `kube-proxy` 服务。
56+
- `Namespace` - Namespace 是对一组资源和对象的抽象集合，比如可以用来将系统内部的对象划分为不同的项目组或用户组。常见的 pods, services, replication controllers 和 deployments 等都是属于某一个 namespace 的（默认是 default），而 node, persistentVolumes 等则不属于任何 namespace。
57+
- `Service` - Service 是应用服务的抽象，通过 labels 为应用提供负载均衡和服务发现。匹配 labels 的 Pod IP 和端口列表组成 endpoints，由 kube-proxy 负责将服务 IP 负载均衡到这些 endpoints 上。每个 Service 都会自动分配一个 cluster IP（仅在集群内部可访问的虚拟地址）和 DNS 名，其他容器可以通过该地址或 DNS 来访问服务，而不需要了解后端容器的运行。
58+
- `Label` - Label 是识别 K8S 对象的标签，以 key/value 的方式附加到对象上（key 最长不能超过 63 字节，value 可以为空，也可以是不超过 253 字节的字符串）。Label 不提供唯一性，并且实际上经常是很多对象（如 Pods）都使用相同的 label 来标志具体的应用。Label 定义好后其他对象可以使用 Label Selector 来选择一组相同 label 的对象（比如 ReplicaSet 和 Service 用 label 来选择一组 Pod）。Label Selector 支持以下几种方式：
59+
- 等式，如 `app=nginx` 和 `env!=production`
60+
- 集合，如 `env in (production, qa)`
61+
- 多个 label（它们之间是 AND 关系），如 `app=nginx,env=test`
62+
- `Annotations` - Annotations 是 key/value 形式附加于对象的注解。不同于 Labels 用于标志和选择对象，Annotations 则是用来记录一些附加信息，用来辅助应用部署、安全策略以及调度策略等。比如 deployment 使用 annotations 来记录 rolling update 的状态。
6063

61-
## 命令
64+
## 二、K8S 命令
6265

6366
### 客户端配置
6467

@@ -163,14 +166,15 @@ kubectl logs pod_name
163166
kubectl logs -f pod_name -c my-container
164167
```
165168

166-
## 引用和引申
169+
## 参考资料
167170

168-
- 官方
169-
- [Github](https://github.com/kubernetes/kubernetes)
170-
- [官网](https://kubernetes.io/)
171-
- 教程
171+
- **官方**
172+
- [Kubernetes Github](https://github.com/kubernetes/kubernetes)
173+
- [Kubernetes 官网](https://kubernetes.io/)
174+
- **教程**
172175
- [Kubernetes 中文指南](https://jimmysong.io/kubernetes-handbook/)
173-
- 文章
176+
- [kubernetes-handbook](https://github.com/rootsongjc/kubernetes-handbook)
177+
- **文章**
174178
- https://github.com/LeCoupa/awesome-cheatsheets/blob/master/tools/kubernetes.sh
175-
- 更多资源
179+
- **更多资源**
176180
- [awesome-kubernetes](https://github.com/ramitsurana/awesome-kubernetes)

0 commit comments

Comments
 (0)