seo优化

2019-09-21 00:42:52 +08:00
parent 20d15a141c
commit affcfef338
62 changed files with 412 additions and 301 deletions
--- a/learning/k8s-intermediate/service/cni.md
+++ b/learning/k8s-intermediate/service/cni.md
@ -68,7 +68,7 @@ CNI的初衷是创建一个框架，用于在配置或销毁容器时动态配

 **Flannel**

-![kubernetes网络插件对比分析（flannel、calico、weave）](./cni.assets/04c2db500e1b4b5dae3be817bfe6d673.jpeg)
+![Kubernetes教程：kubernetes网络插件对比分析（flannel、calico、weave）](./cni.assets/04c2db500e1b4b5dae3be817bfe6d673.jpeg)



@ -88,7 +88,7 @@ Flannel有几种不同类型的后端可用于封装和路由。默认和推荐

 **Calico**

-![kubernetes网络插件对比分析（flannel、calico、weave）](./cni.assets/79fa00ed4bcb4d9b94aee1d02b3c5c8c.jpeg)
+![Kubernetes教程：kubernetes网络插件对比分析（flannel、calico、weave）](./cni.assets/79fa00ed4bcb4d9b94aee1d02b3c5c8c.jpeg)



@ -109,7 +109,7 @@ Calico是Kubernetes生态系统中另一种流行的网络选择。虽然Flannel

 **Weave**

-![kubernetes网络插件对比分析（flannel、calico、weave）](./cni.assets/67b4097c58df478cb348ad50ea752f12.jpeg)
+![Kubernetes教程：kubernetes网络插件对比分析（flannel、calico、weave）](./cni.assets/67b4097c58df478cb348ad50ea752f12.jpeg)



--- a/learning/k8s-intermediate/service/dns.md
+++ b/learning/k8s-intermediate/service/dns.md
@ -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.
--- a/learning/k8s-intermediate/service/ingress.md
+++ b/learning/k8s-intermediate/service/ingress.md
@ -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 存在单点故障的可能性。

-![单IngressController节点](/images/topology/k8s.png)
+![Kubernetes教程：单IngressController节点](/images/topology/k8s.png)

 ### 使用外部负载均衡器

@ -112,7 +112,7 @@ spec:

 > 文档 [安装 Kubernetes 高可用](/install/install-kubernetes.html) 中使用的就是这种拓扑结构。

-![LoadBalancer](/images/topology/kubernetes.png)
+![Kubernetes教程：LoadBalancer](/images/topology/kubernetes.png)

 ## 实战：通过 Ingress 使您的应用程序在互联网可用

@ -249,7 +249,7 @@ curl a.demo.kuboard.cn

 * **如下图所示：**

-![image-20190910225225179](./ingress.assets/image-20190910225225179.png)
+![Kubernetes教程：创建工作负载并配置Ingress](./ingress.assets/image-20190910225225179.png)

 ::: tip
 Kuboard 工作负载编辑器将 kubernetes 中三个主要对象 Deployment/Service/Ingress 放在同一个编辑器界面中处理。
--- a/learning/k8s-intermediate/service/service-details.md
+++ b/learning/k8s-intermediate/service/service-details.md
@ -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 模式的优点**
--- a/learning/k8s-intermediate/service/service.md
+++ b/learning/k8s-intermediate/service/service.md
@ -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 如下图所示：

-![image-20190917213132221](./service.assets/image-20190917213132221.png)
+![Kubernetes教程：Service概述](./service.assets/image-20190917213132221.png)
 ...
-![image-20190917213206652](./service.assets/image-20190917213206652.png)
+![Kubernetes教程：Service概述](./service.assets/image-20190917213206652.png)