seo优化
This commit is contained in:
huanqing.shao
@ -44,7 +44,7 @@ description: Kubernetes 免费中文教程
|
||||
* [Service 概述](/learning/k8s-intermediate/service/service.html)
|
||||
* [Service 详细描述](/learning/k8s-intermediate/service/service-details.html)
|
||||
* [Service 类型](/learning/k8s-intermediate/service/service-types.html)
|
||||
* [Service/Pod 的 DNS](/learning/k8s-intermediate/service/dns.html) <Badge text="正在撰写" type="warn"/>
|
||||
* [Service/Pod 的 DNS](/learning/k8s-intermediate/service/dns.html)
|
||||
* [Service 连接应用程序](/learning/k8s-intermediate/service/connecting.html) <Badge text="正在撰写" type="warn"/>
|
||||
* [Ingress 通过互联网访问您的应用](/learning/k8s-intermediate/service/ingress.html)
|
||||
* [如何选择网络插件](/learning/k8s-intermediate/service/cni.html)
|
||||
|
||||
@ -38,7 +38,7 @@ description: 本文详细讲解了 Kubernetes Deployment 的概念，并描述
|
||||
|
||||
## 在 Kubernetes 上部署第一个应用程序
|
||||
|
||||
|
||||
|
||||
|
||||
上图是在第一篇文章的基础上，添加上了Deployment、Pod和Container。
|
||||
|
||||
@ -135,13 +135,13 @@ kubectl get pods
|
||||
|
||||
**打开 Kuboard 集群概览界面**，如下图所示：
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**点击 default 名称空间**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -160,7 +160,7 @@ kubectl get pods
|
||||
| 镜像 | nginx:1.7.9 | |
|
||||
| 抓取策略 | Always | 每次创建 Pod 都尝试抓取镜像 |
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -19,7 +19,7 @@ description: 本文介绍了如何使用 kubectl / Kuboard 查看和浏览 Kuber
|
||||
|
||||
## Pods概述
|
||||
|
||||
<img src="./explore.assets/module_03_pods.svg" style="border: 1px solid #d7dae2; max-width: 800px;"></img>
|
||||
<img src="./explore.assets/module_03_pods.svg" style="border: 1px solid #d7dae2; max-width: 800px;" alt="Kubernetes教程：Pod概念"></img>
|
||||
|
||||
|
||||
**Pod 容器组** 是一个k8s中一个抽象的概念，用于存放一组 container（可包含一个或多个 container 容器，即图上正方体)，以及这些 container （容器）的一些共享资源。这些资源包括：
|
||||
@ -43,7 +43,7 @@ Pod（容器组）是 k8s 集群上的最基本的单元。当我们在 k8s 上
|
||||
|
||||
下图显示一个 Node（节点）上含有4个 Pod（容器组）
|
||||
|
||||
<img src="./explore.assets/module_03_nodes.svg" style="border: 1px solid #d7dae2; max-width: 600px;"></img>
|
||||
<img src="./explore.assets/module_03_nodes.svg" style="border: 1px solid #d7dae2; max-width: 600px;" alt="Kubernetes教程：Node概念"></img>
|
||||
|
||||
Pod（容器组）总是在 **Node（节点）** 上运行。Node（节点）是 kubernetes 集群中的计算机，可以是虚拟机或物理机。每个 Node（节点）都由 master 管理。一个 Node（节点）可以有多个Pod（容器组），kubernetes master 会根据每个 Node（节点）上可用资源的情况，自动调度 Pod（容器组）到最佳的 Node（节点）上。
|
||||
|
||||
@ -114,11 +114,11 @@ Pod（容器组）总是在 **Node（节点）** 上运行。Node（节点）是
|
||||
|
||||
**在名称空间中查看部署**
|
||||
|
||||
|
||||
|
||||
|
||||
**查看部署及其容器组**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -48,7 +48,7 @@ Service是一个抽象层，它通过 LabelSelector 选择了一组 Pod（容器
|
||||
Service A 将请求转发到 IP 为 10.10.10.1 的Pod上，
|
||||
Service B 将请求转发到 IP 为 10.10.10.2、10.10.10.3、10.10.10.4 的Pod上。
|
||||
|
||||
<img src="./expose.assets/module_04_services.svg" style="border: 1px solid #d7dae2; width: 600px;"></img>
|
||||
<img src="./expose.assets/module_04_services.svg" style="border: 1px solid #d7dae2; width: 600px;" alt="Kubernetes教程：服务和标签"></img>
|
||||
|
||||
|
||||
Service 将外部请求路由到一组 Pod 中，它提供了一个抽象层，使得 Kubernetes 可以在不影响服务调用者的情况下，动态调度容器组<font color="#AAAAAA">（在容器组失效后重新创建容器组，增加或者减少同一个 Deployment 对应容器组的数量等）</font>。
|
||||
@ -65,7 +65,7 @@ Service使用 [Labels、LabelSelector(标签和选择器)](https://kubernetes.io
|
||||
* 通过 Deployment B 创建的 Pod 包含标签为 app=B
|
||||
* Service B 通过标签选择器 app=B 选择可以路由的 Pod
|
||||
|
||||
<img src="./expose.assets/module_04_labels.svg" style="border: 1px solid #d7dae2; max-width: 600px;"></img>
|
||||
<img src="./expose.assets/module_04_labels.svg" style="border: 1px solid #d7dae2; max-width: 600px;" alt="Kubernetes教程：服务和标签"></img>
|
||||
|
||||
Labels（标签）可以在创建 Kubernetes 对象时附加上去，也可以在创建之后再附加上去。任何时候都可以修改一个 Kubernetes 对象的 Labels（标签）
|
||||
|
||||
@ -179,7 +179,7 @@ curl <任意节点的 IP>:32600
|
||||
|
||||
如下图所示：
|
||||
|
||||
|
||||
|
||||
|
||||
* 点击 **保存**
|
||||
|
||||
|
||||
@ -28,7 +28,7 @@ Kubernetes（k8s）是自动化容器操作的开源平台，这些操作包括
|
||||
|
||||
集群是一组节点，这些节点可以是物理服务器或者虚拟机，之上安装了Kubernetes平台。下图展示这样的集群。注意该图为了强调核心概念有所简化。这里可以看到一个典型的Kubernetes架构图。
|
||||
|
||||
|
||||
|
||||
|
||||
上图可以看到如下组件，使用特别的图标表示Service和Label：
|
||||
|
||||
@ -63,7 +63,7 @@ Kubernetes（k8s）是自动化容器操作的开源平台，这些操作包括
|
||||
|
||||
Replication Controller确保任意时间都有指定数量的Pod“副本”在运行。如果为某个Pod创建了Replication Controller并且指定3个副本，它会创建3个Pod，并且持续监控它们。如果某个Pod不响应，那么Replication Controller会替换它，保持总数为3.如下面的动画所示：
|
||||
|
||||
|
||||
|
||||
|
||||
如果之前不响应的Pod恢复了，现在就有4个Pod了，那么Replication Controller会将其中一个终止保持总数为3。如果在运行中将副本总数改为5，Replication Controller会立刻启动2个新Pod，保证总数为5。还可以按照这样的方式缩小Pod，这个特性在执行滚动 [升级](https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller/#rolling_updates) 时很有用。
|
||||
|
||||
@ -93,7 +93,7 @@ Replication Controller确保任意时间都有指定数量的Pod“副本”在
|
||||
|
||||
下述动画展示了Service的功能。注意该图作了很多简化。如果不进入网络配置，那么达到透明的负载均衡目标所涉及的底层网络和路由相对先进。如果有兴趣，有更深入的介绍。
|
||||
|
||||
|
||||
|
||||
|
||||
每个节点都运行如下Kubernetes关键组件：
|
||||
|
||||
|
||||
@ -34,11 +34,11 @@ description: 本文为初学者介绍了一套最合适的 Kubernetes 入门教
|
||||
|
||||
本篇中我们先从第一部分入手，对k8s集群有个整体上的把握。
|
||||
|
||||
<img src="./kubernetes-basics.assets/module_01.svg" style="border: 1px solid #d7dae2; max-width: 600px;"></img>
|
||||
<img src="./kubernetes-basics.assets/module_01.svg" style="border: 1px solid #d7dae2; max-width: 600px;" alt="Kubernetes教程：Kubernetes集群"></img>
|
||||
|
||||
上图描述的是拥有一个Master(主)节点和六个Worker(工作)节点的k8s集群
|
||||
|
||||
|
||||
|
||||
|
||||
**Master 负责管理集群** 负责协调集群中的所有活动，例如调度应用程序，维护应用程序的状态，扩展和更新应用程序。
|
||||
|
||||
|
||||
@ -26,11 +26,11 @@ spec:
|
||||
|
||||
下图中，Service A 只将访问流量转发到 IP 为 10.0.0.5 的Pod上
|
||||
|
||||
<img src="./scale.assets/module_05_scaling1.svg" style="border: 1px solid #d7dae2; max-width: 600px;"></img>
|
||||
<img src="./scale.assets/module_05_scaling1.svg" style="border: 1px solid #d7dae2; max-width: 600px;" alt="Kubernetes教程：伸缩"></img>
|
||||
|
||||
修改了 Deployment 的 replicas 为 4 后，Kubernetes 又为该 Deployment 创建了 3 新的 Pod，这 4 个 Pod 有相同的标签。因此Service A通过标签选择器与新的 Pod建立了对应关系，将访问流量通过负载均衡在 4 个 Pod 之间进行转发。
|
||||
|
||||
<img src="./scale.assets/module_05_scaling2.svg" style="border: 1px solid #d7dae2; max-width: 600px;"></img>
|
||||
<img src="./scale.assets/module_05_scaling2.svg" style="border: 1px solid #d7dae2; max-width: 600px;" alt="Kubernetes教程：伸缩"></img>
|
||||
|
||||
::: tip
|
||||
通过更改部署中的 replicas（副本数）来完成扩展
|
||||
@ -94,13 +94,13 @@ watch kubectl get pods -o wide
|
||||
|
||||
副本数： 4
|
||||
|
||||
|
||||
|
||||
|
||||
* 点击 ***确定*** 按钮
|
||||
|
||||
等待新增的容器组完成初始化，如下图所示：
|
||||
|
||||
|
||||
|
||||
|
||||
:::
|
||||
|
||||
|
||||
@ -23,21 +23,21 @@ description: 本文详细讲解了 Kubernetes Rolling Update 的概念，并描
|
||||
|
||||
1. 原本 Service A 将流量负载均衡到 4 个旧版本的 Pod （当中的容器为 绿色）上
|
||||
|
||||
<img src="./update.assets/module_06_rollingupdates1.svg" style="border: 1px solid #d7dae2; max-width: 600px;"></img>
|
||||
<img src="./update.assets/module_06_rollingupdates1.svg" style="border: 1px solid #d7dae2; max-width: 600px;" alt="Kubernetes教程：滚动更新1"></img>
|
||||
|
||||
2. 更新完 Deployment 部署文件中的镜像版本后，master 节点选择了一个 worker 节点，并根据新的镜像版本创建 Pod（紫色容器）。新 Pod 拥有唯一的新的 IP。同时，master 节点选择一个旧版本的 Pod 将其移除。
|
||||
|
||||
此时，Service A 将新 Pod 纳入到负载均衡中，将旧Pod移除
|
||||
|
||||
<img src="./update.assets/module_06_rollingupdates2.svg" style="border: 1px solid #d7dae2; max-width: 600px;"></img>
|
||||
<img src="./update.assets/module_06_rollingupdates2.svg" style="border: 1px solid #d7dae2; max-width: 600px;" alt="Kubernetes教程：滚动更新2"></img>
|
||||
|
||||
3. 同步骤2，再创建一个新的 Pod 替换一个原有的 Pod
|
||||
|
||||
<img src="./update.assets/module_06_rollingupdates3.svg" style="border: 1px solid #d7dae2; max-width: 600px;"></img>
|
||||
<img src="./update.assets/module_06_rollingupdates3.svg" style="border: 1px solid #d7dae2; max-width: 600px;" alt="Kubernetes教程：滚动更新3"></img>
|
||||
|
||||
4. 如此 Rolling Update 滚动更新，直到所有旧版本 Pod 均移除，新版本 Pod 也达到 Deployment 部署文件中定义的副本数，则滚动更新完成
|
||||
|
||||
<img src="./update.assets/module_06_rollingupdates4.svg" style="border: 1px solid #d7dae2; max-width: 600px;"></img>
|
||||
<img src="./update.assets/module_06_rollingupdates4.svg" style="border: 1px solid #d7dae2; max-width: 600px;" alt="Kubernetes教程：滚动更新4"></img>
|
||||
|
||||
滚动更新允许以下操作：
|
||||
|
||||
@ -106,7 +106,7 @@ watch kubectl get pods -l app=nginx
|
||||
|
||||
填写新的 nginx 版本号： 1.8， 如下图所示：
|
||||
|
||||
|
||||
|
||||
|
||||
* 点击 ***变更***
|
||||
|
||||
@ -116,7 +116,7 @@ watch kubectl get pods -l app=nginx
|
||||
|
||||
可观察到 Kubernetes 对 ***Nginx部署*** 执行滚动更新的过程，如下图所示
|
||||
|
||||
|
||||
|
||||
|
||||
:::
|
||||
|
||||
|
||||
@ -35,7 +35,7 @@ nodeName 是四种方法中最简单的一个，但是因为它的局限性，
|
||||
|
||||
您在 Kuboard 工作负载编辑器中，可以通过 ***指定节点*** --> ***选择节点*** 按钮，选择对应 nodeName 的取值。如下图所示：
|
||||
|
||||
|
||||
|
||||
|
||||
## 节点选择器 nodeSelector
|
||||
|
||||
@ -51,7 +51,7 @@ nodeSelector 是 PodSpec 中的一个字段。指定了一组名值对。节点
|
||||
|
||||
增加标签 disk:ssd，并保存，如下图所示：
|
||||
|
||||
|
||||
|
||||
|
||||
### 为工作负载选择节点
|
||||
|
||||
@ -65,7 +65,7 @@ nodeSelector 是 PodSpec 中的一个字段。指定了一组名值对。节点
|
||||
|
||||
选择 disk:ssd 标签，此时可以看到匹配的节点有刚才您添加标签的节点。点击 ***确定*** 按钮
|
||||
|
||||
|
||||
|
||||
|
||||
* 点击 ***保存*** 按钮
|
||||
|
||||
|
||||
@ -38,7 +38,7 @@ Kubernetes 中，可以为容器指定计算资源的请求数量 request 和限
|
||||
|
||||
在 Kuboard 的工作负载编辑器中编辑容器资源请求及限制的界面如下图所示：
|
||||
|
||||
|
||||
|
||||
|
||||
## 带有资源请求的容器组是如何调度的
|
||||
|
||||
|
||||
@ -26,13 +26,13 @@ Kubernetes 官网描述了多种 ConfigMap 的创建方法，本文不再复述
|
||||
|
||||
如下图所示：
|
||||
|
||||
|
||||
|
||||
|
||||
* 点击 **配置** --> **创建** 按钮
|
||||
|
||||
并填写表单，如下图所示：
|
||||
|
||||
|
||||
|
||||
|
||||
* 点击 **保存**
|
||||
|
||||
@ -59,9 +59,9 @@ Kubernetes 官网描述了多种 ConfigMap 的创建方法，本文不再复述
|
||||
|
||||
如下图所示：
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
* 点击 **保存**
|
||||
|
||||
@ -81,7 +81,7 @@ Kubernetes 官网描述了多种 ConfigMap 的创建方法，本文不再复述
|
||||
|
||||
可查看到 ENV_KEY_1='value-1' 已经注入到该容器的环境变量中，如下图所示：
|
||||
|
||||
|
||||
|
||||
|
||||
## ConfigMap --> 容器的环境变量（ConfigMap的所有名值对）
|
||||
|
||||
@ -104,7 +104,7 @@ Kubernetes 官网描述了多种 ConfigMap 的创建方法，本文不再复述
|
||||
|
||||
如下图所示：
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
* 点击 **保存**
|
||||
@ -133,7 +133,7 @@ Kubernetes 官网描述了多种 ConfigMap 的创建方法，本文不再复述
|
||||
|
||||
可查看到 `KEY_1` `KEY_2` `KEY_3` 已经注入到该容器的环境变量中，如下图所示：
|
||||
|
||||
|
||||
|
||||
|
||||
## ConfigMap --> Command 参数
|
||||
|
||||
@ -155,7 +155,7 @@ Kubernetes 官网描述了多种 ConfigMap 的创建方法，本文不再复述
|
||||
| 环境变量 | ENV_KEY_1 / ENV_KEY_3 | 选择 ConfigMap<br/> ConfigMap 填写 ***my-nginx-config*** <br/> Key 填写 ***KEY_1*** <br/> <br/> 同样的方法添加 ENV_KEY_3 |
|
||||
如下图所示：
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
* 点击 **保存**
|
||||
@ -172,7 +172,7 @@ Kubernetes 官网描述了多种 ConfigMap 的创建方法，本文不再复述
|
||||
|
||||
如下图所示
|
||||
|
||||
|
||||
|
||||
|
||||
## ConfigMap --> 数据卷
|
||||
|
||||
@ -207,7 +207,7 @@ Kubernetes 官网描述了多种 ConfigMap 的创建方法，本文不再复述
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
* 创建 nginx Deployment 如下图所示：
|
||||
|
||||
@ -233,7 +233,7 @@ Kubernetes 官网描述了多种 ConfigMap 的创建方法，本文不再复述
|
||||
| 挂载点：数据卷 | default-conf | 选择上面已经定义的数据卷 |
|
||||
| 挂载点：数据卷内子路径 | default.conf | 将数据卷内的 default.conf 映射到容器的 /etc/nginx/conf.d/default.conf |
|
||||
|
||||
|
||||
|
||||
|
||||
* 点击 **保存**
|
||||
|
||||
@ -254,7 +254,7 @@ Kubernetes 官网描述了多种 ConfigMap 的创建方法，本文不再复述
|
||||
cat /default.conf
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
::: tip
|
||||
|
||||
|
||||
@ -38,7 +38,7 @@ PersistentVolumeClaim（PVC 存储卷声明）代表用户使用存储的请求
|
||||
* PersistentVolumeClaim 是使用该资源的请求，通常由应用程序提出请求，并指定对应的 StorageClass 和需求的空间大小
|
||||
* PersistentVolumeClaim 可以做为数据卷的一种，被挂载到容器组/容器中使用
|
||||
|
||||
<img src="./pv.assets/image-20190906074512760.png" style="max-width: 450px;"/>
|
||||
<img src="./pv.assets/image-20190906074512760.png" style="max-width: 450px;" alt="Kubernetes教程：存储卷PersistentVolume"/>
|
||||
|
||||
PersistantVolume 和 PersistantVolumeClaim 的管理过程描述如下：
|
||||
|
||||
@ -136,7 +136,7 @@ Kubernetes 支持 20 种存储卷类型（可参考 [Types of Persistent Volumes
|
||||
|
||||
在 Kuboard 中查看 PersistentVolume 的界面如下图所示：
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
PersistentVolume 字段描述如下表所示：
|
||||
@ -156,7 +156,7 @@ PersistentVolume 字段描述如下表所示：
|
||||
|
||||
在 Kuboard 中查看存储卷声明的界面如下图所示：
|
||||
|
||||
|
||||
|
||||
|
||||
| 字段名称 | 可选项/备注 |
|
||||
| --------------------- | ------------------------------------------------------------ |
|
||||
@ -171,4 +171,4 @@ PersistentVolume 字段描述如下表所示：
|
||||
|
||||
在您完成存储卷声明的定义后，您可以在 Kuboard 工作复杂编辑器的 ***数据卷 Volume*** 区域引用该存储卷声明，如下图所示：
|
||||
|
||||
|
||||
|
||||
|
||||
@ -28,7 +28,7 @@ Kuboard 支持的存储类的种类如下：
|
||||
|
||||
在 Kuboard 中查看存储类，如下图所示：
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -27,7 +27,7 @@ Docker 里同样也存在一个 volume（数据卷）的概念，但是 docker
|
||||
* 一个容器通过挂载点决定某一个数据卷被挂载到容器中的什么路径
|
||||
* 不同类型的数据卷对应不同的存储介质（图中列出了 nfs、PVC、ConfigMap 三种存储介质，接下来将介绍更多）
|
||||
|
||||
<img src="./volume.assets/image-20190904201849792.png" style="max-width: 450px;"/>
|
||||
<img src="./volume.assets/image-20190904201849792.png" style="max-width: 450px;" alt="Kubernetes教程：数据卷"/>
|
||||
|
||||
## 在 Kuboard 中使用数据卷
|
||||
|
||||
@ -54,7 +54,7 @@ Docker 里同样也存在一个 volume（数据卷）的概念，但是 docker
|
||||
|
||||
:::
|
||||
|
||||
|
||||
|
||||
|
||||
## 数据卷的类型
|
||||
|
||||
|
||||
@ -62,7 +62,7 @@ docker pull my-registry.example.com:5000/example/web-example:v1.0.1
|
||||
|
||||
如下图所示
|
||||
|
||||
|
||||
|
||||
|
||||
* 点击 **保存** 按钮
|
||||
|
||||
@ -88,7 +88,7 @@ docker pull my-registry.example.com:5000/example/web-example:v1.0.1
|
||||
* 红色部分：image 名字
|
||||
* 棕色部分：image 标签
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -68,7 +68,7 @@ CNI的初衷是创建一个框架，用于在配置或销毁容器时动态配
|
||||
|
||||
**Flannel**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -88,7 +88,7 @@ Flannel有几种不同类型的后端可用于封装和路由。默认和推荐
|
||||
|
||||
**Calico**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -109,7 +109,7 @@ Calico是Kubernetes生态系统中另一种流行的网络选择。虽然Flannel
|
||||
|
||||
**Weave**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -1,8 +1,121 @@
|
||||
---
|
||||
layout: LearningLayout
|
||||
description: 本文介绍了 Kubernetes 中 DNS 的分配规则
|
||||
description: 本文介绍了 Kubernetes 中 Service 和 Pod 的 DNS 分配规则
|
||||
---
|
||||
|
||||
# Service/Pod 的 DNS
|
||||
|
||||
正在撰写...
|
||||
参考文档： Kubernetes 官网文档 [DNS for Services and Pods](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/)
|
||||
|
||||
本文介绍了 Kubernetes 中的 DNS 分配方式
|
||||
|
||||
## 概述
|
||||
|
||||
Kubernetes 集群中运行了一组 DNS Pod，配置了对应的 Service，并由 kubelete 将 DNS Service 的 IP 地址配置到节点上的容器中以便解析 DNS names。
|
||||
|
||||
集群中的每一个 Service（包括 DNS 服务本身）都将被分配一个 DNS name。默认情况下，客户端 Pod 的 DNS 搜索列表包括 Pod 所在的名称空间以及集群的默认域。例如：
|
||||
|
||||
假设名称空间 `bar` 中有一个 Service 名为 `foo`：
|
||||
* 名称空间 `bar` 中的 Pod 可以通过 `nslookup foo` 查找到该 Service
|
||||
* 名称空间 `quux` 中的 Pod 可以通过 `nslookup foo.bar` 查找到该 Service
|
||||
|
||||
本文后面的章节详细介绍了支持的 DNS 记录类型及格式。如果有任何其他类型的格式凑巧可以使用，这仅仅是实现上的细节，并且可能在将来的版本中失效。参考此文档可以查看最新的规范 [Kubernetes DNS-Based Service Discovery](https://github.com/kubernetes/dns/blob/master/docs/specification.md)
|
||||
|
||||
## Services
|
||||
|
||||
### A 记录
|
||||
|
||||
* Service（headless Service 除外）将被分配一个 DNS A 记录，格式为 `my-svc.my-namespace.svc.cluster-domain.example`。该 DNS 记录解析到 Service 的 ClusterIP。
|
||||
|
||||
* Headless Service（没有 ClusterIP）也将被分配一个 DNS A 记录，格式为 `my-svc.my-namespace.svc.cluster-domain.exmaple`。该 DNS 记录解析到 Service 所选中的一组 Pod 的 IP 地址的集合。调用者应该使用该 IP 地址集合，或者按照轮询（round-robin）的方式从集合中选择一个 IP 地址使用。
|
||||
|
||||
### SRV 记录
|
||||
|
||||
Service（含 headless Service）的命名端口（有 name 的端口）将被分配一个 SRV 记录，其格式为 `_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster-domain.example`：
|
||||
* 对于一个普通 Service（非 headless Service），该 SRV 记录解析到其端口号和域名 `my-svc.my-namespace.svc.cluster-domain.exmaple`
|
||||
* 对于一个 Headless Service，该 SRV 记录解析到多个结果：每一个结果都对应该 Service 的一个后端 Pod，包含其端口号和 Pod 的域名 `auto-generated-pod-name.my-svc.my-namespace.svc.cluster-domain.exmaple`
|
||||
|
||||
## Pods
|
||||
|
||||
### Pod 的 hostname / subdomain
|
||||
|
||||
Kubernetes 在创建 Pod 时，将 Pod 定义中的 `metadata.name` 的值作为 Pod 实例的 hostname。
|
||||
|
||||
Pod 定义中有一个可选字段 `spec.hostname` 可用来直接指定 Pod 的 hostname。例如，某 Pod 的 `spec.hostname` 字段被设置为 `my-host`，则该 Pod 创建后 hostname 将被设为 `my-host`
|
||||
|
||||
Pod 定义中还有一个可选字段 `spec.subdomain` 可用来指定 Pod 的 subdomain。例如，名称空间 `my-namespace` 中，某 Pod 的 hostname 为 `foo`，并且 subdomain 为 `bar`，则该 Pod 的完整域名（FQDN）为 `foo.bar.my-namespace.svc.cluster-domain.example`。
|
||||
|
||||
例子：
|
||||
|
||||
``` yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: default-subdomain
|
||||
spec:
|
||||
selector:
|
||||
name: busybox
|
||||
clusterIP: None
|
||||
ports:
|
||||
- name: foo # Actually, no port is needed.
|
||||
port: 1234
|
||||
targetPort: 1234
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: busybox1
|
||||
labels:
|
||||
name: busybox
|
||||
spec:
|
||||
hostname: busybox-1
|
||||
subdomain: default-subdomain
|
||||
containers:
|
||||
- image: busybox:1.28
|
||||
command:
|
||||
- sleep
|
||||
- "3600"
|
||||
name: busybox
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: busybox2
|
||||
labels:
|
||||
name: busybox
|
||||
spec:
|
||||
hostname: busybox-2
|
||||
subdomain: default-subdomain
|
||||
containers:
|
||||
- image: busybox:1.28
|
||||
command:
|
||||
- sleep
|
||||
- "3600"
|
||||
name: busybox
|
||||
```
|
||||
|
||||
如果 Pod 所在名称空间中存在一个 headless Service，其名称与 Pod 的 subdomain 相同，则集群的 KubeDNS 服务器仍将为 Pod 的完整域名（FQDN）返回一个 A 记录。例如，假设一个 Pod 的 hostname 为 `busybox-1` 且其 subdomain 为 `default-subdomain`，同名称空间下有一个 headless Service 的名字为 `default-subdomain`，此时，该 Pod 的完整域名（FQDN）为 `busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example`。DNS 服务将其解析到一个 A 记录，指向 Pod 的 IP 地址。上面 yaml 文件中的 Pod `busybox1` 和 `busybox2` 都将有各自的 A 记录
|
||||
|
||||
::: tip 备注
|
||||
* A 记录不是根据 Pod name 创建的，而是根据 hostname 创建的。如果一个 Pod 没有 hostname 只有 subdomain，则 Kubernetes 将只为其 headless Service 创建一个 A 记录 `default-subdomain.my-namespace.svc.cluster-domain.example`，该记录指向 Pod 的 IP 地址。
|
||||
* Pod 必须达到就绪状态才可以拥有 A 记录，除非 Service 的字段 `spec.publishNotReadyAddresses` 被设置为 `True`
|
||||
:::
|
||||
|
||||
<!-- The Endpoints object can specify the hostname for any endpoint addresses, along with its IP. -->
|
||||
|
||||
### Pod 的 DNS Policy
|
||||
|
||||
可以为每一个 Pod 设置其自己的 DNS Policy。Kubernetes 通过 Pod 定义中的 `spec.dnsPolicy` 字段设置 DNS Policy，可选的值有：
|
||||
|
||||
* **Default**： Pod 从其所在的节点继承域名解析配置。更多细节请参考 [Customizing DNS Service
|
||||
](https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/#inheriting-dns-from-the-node)
|
||||
|
||||
* **ClusterFirst**：任何与集群域名后缀（例如 `www.kubernetes.io`）不匹配的 DNS 查询，都将被转发到 Pod 所在节点的上游 DNS 服务。集群管理员可能配置了额外的 stub-domain 及上游 DNS 服务，更多细节请参考 [Customizing DNS Service
|
||||
](https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/#effects-on-pods)
|
||||
|
||||
* **ClusterFirstWithHostNet**： 对于运行在节点网络上的 Pod，其 dnsPolicy 必须指定为 `ClusterFirstWithHostNet`
|
||||
|
||||
*
|
||||
|
||||
“ClusterFirstWithHostNet“: For Pods running with hostNetwork, you should explicitly set its DNS policy “ClusterFirstWithHostNet”.
|
||||
“None“: It allows a Pod to ignore DNS settings from the Kubernetes environment. All DNS settings are supposed to be provided using the dnsConfig field in the Pod Spec. See Pod’s DNS config subsection below.
|
||||
|
||||
@ -28,7 +28,7 @@ Ingress Controller （通常需要负载均衡器配合）负责实现 Ingress A
|
||||
2. Ingress Controller 根据请求的域名 `a.kuboard.cn` 和路径 `abc` 匹配集群中所有的 Ingress 信息，并最终找到 `Ingress B` 中有这个配置，其对应的 Service 为 `Service B` 的 `9080` 端口
|
||||
3. Ingress Controller 通过 kube-proxy 将请求转发到 `Service B` 对应的任意一个 Pod 上 与 `Service B` 的 `9080` 端口对应的容器端口上。（从 Ingress Controller 到 Pod 的负载均衡由 kube-proxy + Service 实现）
|
||||
|
||||
<img src="./ingress.assets/image-20190910222649193.png" style="border: 1px solid #d7dae2; max-width: 720px;"></img>
|
||||
<img src="./ingress.assets/image-20190910222649193.png" style="border: 1px solid #d7dae2; max-width: 720px;" alt="Kubernetes教程：Ingress及其Controller"></img>
|
||||
|
||||
## Ingress Controller
|
||||
|
||||
@ -100,7 +100,7 @@ spec:
|
||||
|
||||
> 文档 [安装 Kubernetes 单Master节点](/install/install-k8s.html) 中使用的就是这种拓扑结构。这种方式下，Ingress Controller 存在单点故障的可能性。
|
||||
|
||||
|
||||
|
||||
|
||||
### 使用外部负载均衡器
|
||||
|
||||
@ -112,7 +112,7 @@ spec:
|
||||
|
||||
> 文档 [安装 Kubernetes 高可用](/install/install-kubernetes.html) 中使用的就是这种拓扑结构。
|
||||
|
||||
|
||||
|
||||
|
||||
## 实战：通过 Ingress 使您的应用程序在互联网可用
|
||||
|
||||
@ -249,7 +249,7 @@ curl a.demo.kuboard.cn
|
||||
|
||||
* **如下图所示：**
|
||||
|
||||
|
||||
|
||||
|
||||
::: tip
|
||||
Kuboard 工作负载编辑器将 kubernetes 中三个主要对象 Deployment/Service/Ingress 放在同一个编辑器界面中处理。
|
||||
|
||||
@ -126,7 +126,7 @@ Kubernetes 支持三种 proxy mode（代理模式），他们的版本兼容性
|
||||
如下图所示：
|
||||
|
||||
<p>
|
||||
<img src="./service-details.assets/services-userspace-overview.svg" style="max-width: 420px;"/>
|
||||
<img src="./service-details.assets/services-userspace-overview.svg" style="max-width: 420px;" alt="Kubernetes教程：Service user space"/>
|
||||
</p>
|
||||
|
||||
### Iptables 代理模式 <Badge text="默认模式" type="success"/>
|
||||
@ -141,7 +141,7 @@ Kubernetes 支持三种 proxy mode（代理模式），他们的版本兼容性
|
||||
|
||||
如下图所示：
|
||||
<p>
|
||||
<img src="./service-details.assets/services-iptables-overview.svg" style="max-width: 420px;"/>
|
||||
<img src="./service-details.assets/services-iptables-overview.svg" style="max-width: 420px;" alt="Kubernetes教程：Service iptables proxy"/>
|
||||
</p>
|
||||
|
||||
**iptables proxy mode 的优点：**
|
||||
@ -165,7 +165,7 @@ Kubernetes 支持三种 proxy mode（代理模式），他们的版本兼容性
|
||||
* 当访问一个 Service 时，IPVS 将请求重定向到后端 Pod
|
||||
|
||||
<p>
|
||||
<img src="./service-details.assets/services-ipvs-overview.svg" style="max-width: 420px;"/>
|
||||
<img src="./service-details.assets/services-ipvs-overview.svg" style="max-width: 420px;" alt="Kubernetes教程：Service IPVS proxy"/>
|
||||
</p>
|
||||
|
||||
**IPVS 模式的优点**
|
||||
|
||||
@ -35,7 +35,7 @@ Kubernetes 通过引入 Service 的概念，将前端与后端解耦。
|
||||
从 Kuboard 工作负载编辑器的视角来看，Service 与其他重要的 Kubernetes 对象之间的关系如下图所示：
|
||||
|
||||
<p>
|
||||
<img src="./service.assets/image-20190917210501081.png" style="max-width: 600px;"/>
|
||||
<img src="./service.assets/image-20190917210501081.png" style="max-width: 600px;" alt="Kubernetes教程：Service概念结构"/>
|
||||
</p>
|
||||
|
||||
图中，Service 先连线到 Controller，Controller 在连线到容器组，这种表示方式只是概念上的，期望用户在使用 Kubernetes 的时候总是通过 Controller 创建 Pod，然后再通过 Service 暴露为网络服务，通过 Ingress 对集群外提供互联网访问。
|
||||
@ -52,6 +52,6 @@ Kubernetes 通过引入 Service 的概念，将前端与后端解耦。
|
||||
|
||||
在 Kuboard 工作负载编辑器中，Service 如下图所示：
|
||||
|
||||
|
||||
|
||||
...
|
||||
|
||||
|
||||
|
||||
@ -58,7 +58,7 @@ Pod 可以包含多个工作容器，也可以包含一个或多个初始化容
|
||||
|
||||
Kuboard 工作负载编辑器中支持定义初始化容器，如下图所示，左下角可 ***添加初始化容器*** 初始化容器按照添加的顺序显示在容器组中，且始终显示在工作容器的前面。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## 初始化容器的行为
|
||||
|
||||
@ -27,7 +27,7 @@ phase 的可能取值有：
|
||||
|
||||
每一个 Pod 都有一个数组描述其是否达到某些指定的条件。Pod condition 数组在 Kuboard 中的显示如下图所示：
|
||||
|
||||
|
||||
|
||||
|
||||
该数组的每一行可能有六个字段：
|
||||
|
||||
@ -79,7 +79,7 @@ Kubelet 可以在两种情况下对运行中的容器执行 Probe：
|
||||
|
||||
Kuboard 可以在工作负载编辑器中配置健康检查/就绪检查，界面如下所示：
|
||||
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
$$ Pod and Container status
|
||||
@ -95,7 +95,7 @@ $$ Pod and Container status
|
||||
|
||||
在 Kuboard 的工作负载查看界面中可查看到容器的状态如下图所示：
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- $$ Pod readiness gate
|
||||
Kuboard 暂不支持 -->
|
||||
|
||||
@ -49,7 +49,7 @@ Pod 的设计目的是用来支持多个互相协同的容器，是的他们形
|
||||
::: tip 提示
|
||||
将多个容器运行于同一个容器组中是一种相对高级复杂的使用方法。只有在您的容器相互之间紧密耦合是，您才应该使用这种方式。例如：您可能有一个容器是 web server，用来将共享数据卷中的文件作为网站发布出去，同时您有另一个 "sidecar" 容器从远程抓取并更新这些文件。如下图所示：
|
||||
|
||||
<img src="./pod.assets/pod.svg" style="max-width: 360px;"></img>
|
||||
<img src="./pod.assets/pod.svg" style="max-width: 360px;" alt="Kubernetes教程：Pod中的多个容器"></img>
|
||||
|
||||
:::
|
||||
|
||||
|
||||
@ -51,9 +51,9 @@ Kubernetes 通过引入 Controller（控制器）的概念来管理 Pod 实例
|
||||
|
||||
在 Kuboard 工作负载编辑器中，控制器的概念如下图所示：
|
||||
|
||||
<img src="./workload.assets/image-20190910232615991.png" style="border: 1px solid #d7dae2; max-width: 600px;"></img>
|
||||
<img src="./workload.assets/image-20190910232615991.png" style="border: 1px solid #d7dae2; max-width: 600px;" alt="Kubernetes教程：控制器概念结构"></img>
|
||||
|
||||
|
||||
**界面如下图所示：**
|
||||
|
||||
|
||||
|
||||
|
||||
@ -16,7 +16,7 @@ description: 本文描述了一个经典微服务参考架构，并且通过三
|
||||
|
||||
作者在落地 Spring Cloud 微服务的过程中，设计了如下图所示的微服务参考架构：
|
||||
|
||||
|
||||
|
||||
|
||||
该图的左侧是 DevOps 平台，涵盖构建、测试、包管理、部署及运维、监控及评估。右侧是运行时平台，分成互联网层、展现层、微服务层、数据层。
|
||||
|
||||
@ -54,7 +54,7 @@ description: 本文描述了一个经典微服务参考架构，并且通过三
|
||||
|
||||
在解决这些问题的过程中，最终摸索出了一套以 Kubernetes 为关键环节的微服务 DevOps 平台。
|
||||
|
||||
|
||||
|
||||
|
||||
如上图所示，假设有20+ 开发人员，
|
||||
|
||||
@ -88,7 +88,7 @@ Kuboard 诞生于 Spring Cloud 微服务落地的实践过程中，他在管理
|
||||
|
||||
如下图所示：***Kuboard 集群概览界面***
|
||||
|
||||
|
||||
|
||||
|
||||
Kuboard 集群概览视角，映射了 Kubernetes 中的如下几个重要概念：
|
||||
|
||||
@ -112,7 +112,7 @@ Kuboard 集群概览视角，映射了 Kubernetes 中的如下几个重要概念
|
||||
|
||||
如下图所示：***Kuboard名称空间截图***
|
||||
|
||||
|
||||
|
||||
|
||||
Kuboard 名称空间视角，映射了 Kubernetes 中的如下几个重要概念：
|
||||
|
||||
@ -140,7 +140,7 @@ Kuboard 名称空间界面中，还为典型的运维场景提供了便捷的操
|
||||
|
||||
Kubernetes 中，与 Workload 相关的概念非常多，Kuboard 从微服务部署的实际需要出发，按照下图所示的方式理解这些相关概念：
|
||||
|
||||
|
||||
|
||||
|
||||
Kuboard 工作负载视图中，关联的 Kubernetes 中如下几个重要的概念：
|
||||
|
||||
@ -155,7 +155,7 @@ Kuboard 工作负载视图中，关联的 Kubernetes 中如下几个重要的概
|
||||
|
||||
Kuboard 认为，掌握这些概念并正确理解这些概念的关系之后，就可以胜任使用 Kubernetes 部署微服务的工作，为了使事情变得更简单，避免编写冗长的 YAML 文件，Kuboard 以此概念为基础，设计了 Kuboard 工作负载编辑器，如下图所示：
|
||||
|
||||
|
||||
|
||||
|
||||
## 微服务 + 监控/评估
|
||||
|
||||
@ -172,7 +172,7 @@ Kuboard 认为，掌握这些概念并正确理解这些概念的关系之后，
|
||||
|
||||
Kuboard 认为，应该以微服务视角的视角快速查看到该无服务在不同层面的监控结果。因此，在 Kuboard 的工作负载（微服务）查看界面中，可以直接点击进入不同监控系统对应的监控结果，无需再监控系统内反复查找。如一下截图所示：
|
||||
|
||||
|
||||
|
||||
|
||||
点击图中 ***Nginx 监控***、 ***容器组监控***、 ***所在节点监控*** 等按钮，可以直接打开该容器组对应的监控界面。因为篇幅的限制，此处不再展开描述，请点击 <a target="_blank" :href="`http://demo.kuboard.cn/#/dashboard?k8sToken=${$site.themeConfig.kuboardToken}`">
|
||||
Kuboard 在线体验
|
||||
|
||||
@ -32,7 +32,7 @@ description: 微服务参考架构：包含微服务运行时、构建及测试
|
||||
|
||||
展现层、网关层、服务层、中间件层以及监控层，都运行于 Kubernetes 之上，由 Kuboard 管理。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -40,7 +40,7 @@ Spring Cloud on Kubernetes 并不对 Spring Cloud 架构、组件等做过多解
|
||||
|
||||
为了更好地阐述此主题，作者准备了一个最简单的微服务 example 作为例子，该 example 只实现了对一张简单数据库表执行 CRUD 操作的功能，该 example 的部署架构如下图所示，源代码请参考 [kuboard-example](https://github.com/eip-work/kuboard-example)，您也可以直接通过 Kuboard [导入 example 微服务](/guide/example/import.html)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user