diff --git a/.vuepress/components/AdSensePageTop.vue b/.vuepress/components/AdSensePageTop.vue
index 0fe5fd2..d04351e 100644
--- a/.vuepress/components/AdSensePageTop.vue
+++ b/.vuepress/components/AdSensePageTop.vue
@@ -1,16 +1,17 @@
-
+ data-ad-slot="6238375600"
+ data-ad-format="auto"
+ data-full-width-responsive="true">
-->
-
+
+
@@ -32,10 +33,9 @@ export default {
diff --git a/.vuepress/components/AdSenseTitle.vue b/.vuepress/components/AdSenseTitle.vue
index d69f65c..a142b53 100644
--- a/.vuepress/components/AdSenseTitle.vue
+++ b/.vuepress/components/AdSenseTitle.vue
@@ -4,7 +4,7 @@
群号: 808894550 在线答疑，也可以扫描本文末尾的二维码加群
-
+
-
+ -->
diff --git a/.vuepress/config.js b/.vuepress/config.js
index 2cc8d24..b0dcd87 100644
--- a/.vuepress/config.js
+++ b/.vuepress/config.js
@@ -279,6 +279,16 @@ module.exports = {
'k8s-bg/architecture/controller',
]
},
+ {
+ title: '操作Kubernetes',
+ collapsable: true,
+ children: [
+ 'k8s-intermediate/obj/k8s-object',
+ 'k8s-intermediate/obj/manage',
+ 'k8s-intermediate/obj/names',
+ 'k8s-intermediate/obj/namespaces',
+ ]
+ },
{
title: '容器',
collapsable: true,
diff --git a/.vuepress/public/statics/learning/obj/deployment.yaml b/.vuepress/public/statics/learning/obj/deployment.yaml
new file mode 100644
index 0000000..30c73b6
--- /dev/null
+++ b/.vuepress/public/statics/learning/obj/deployment.yaml
@@ -0,0 +1,19 @@
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+ name: nginx-deployment
+spec:
+ selector:
+ matchLabels:
+ app: nginx
+ replicas: 2 # 运行 2 个容器化应用程序副本
+ template:
+ metadata:
+ labels:
+ app: nginx
+ spec:
+ containers:
+ - name: nginx
+ image: nginx:1.7.9
+ ports:
+ - containerPort: 80
diff --git a/.vuepress/theme/components/Navbar.vue b/.vuepress/theme/components/Navbar.vue
index ab01ca9..6a053d1 100644
--- a/.vuepress/theme/components/Navbar.vue
+++ b/.vuepress/theme/components/Navbar.vue
@@ -24,6 +24,9 @@
提供K8S免费教程
+
+
+
+
diff --git a/learning/k8s-advanced/policy/rq.md b/learning/k8s-advanced/policy/rq.md
new file mode 100644
index 0000000..b92f28a
--- /dev/null
+++ b/learning/k8s-advanced/policy/rq.md
@@ -0,0 +1,15 @@
+---
+# vssueId: 135
+layout: LearningLayout
+description: Kubernetes教程_
+meta:
+ - name: keywords
+ content: Kubernetes
+---
+
+# Resource Quotas
+
+
+
+
+正在撰写 ...
diff --git a/learning/k8s-intermediate/obj/k8s-object.md b/learning/k8s-intermediate/obj/k8s-object.md
new file mode 100644
index 0000000..4a5f70a
--- /dev/null
+++ b/learning/k8s-intermediate/obj/k8s-object.md
@@ -0,0 +1,82 @@
+---
+vssueId: 133
+layout: LearningLayout
+description: Kubernetes教程_本文描述了Kubernetes对象与Kubernetes_API的关系_以及您如何在.yaml格式的文件中定义Kubernetes对象
+meta:
+ - name: keywords
+ content: Kubernetes对象,Kubernetes Object
+---
+
+# 什么是Kubernetes对象
+
+
+
+> 参考文档： [Understanding Kubernetes Objects](https://kubernetes.io/docs/concepts/overview/working-with-objects/kubernetes-objects/)
+
+本文描述了Kubernetes对象与Kubernetes API的关系，以及您如何在 `.yaml` 格式的文件中定义Kubernetes对象。
+
+
+
+Kubernetes对象指的是Kubernetes系统的持久化实体，所有这些对象合起来，代表了你集群的实际情况。常规的应用里，我们把应用程序的数据存储在数据库中，Kubernetes将其数据以Kubernetes对象的形式通过 api server存储在 etcd 中。具体来说，这些数据（Kubernetes对象）描述了：
+* 集群中运行了哪些容器化应用程序（以及在哪个节点上运行）
+* 集群中对应用程序可用的资源
+* 应用程序相关的策略定义，例如，重启策略、升级策略、容错策略
+* 其他Kubernetes管理应用程序时所需要的信息
+
+一个Kubernetes对象代表着用户的一个意图（a record of intent），一旦您创建了一个Kubernetes对象，Kubernetes将持续工作，以尽量实现此用户的意图。创建一个 Kubernetes对象，就是告诉Kubernetes，您需要的集群中的工作负载是什么（集群的 **目标状态**）。请参考 [控制器](/learning/k8s-bg/architecture/controller.html)、[声明式配置](/learning/k8s-intermediate/workload/wl-deployment/#deployment-概述)
+
+操作 Kubernetes 对象（创建、修改、删除）的方法主要有：
+* [kubectl](/install/install-kubectl.html) 命令行工具
+* [kuboard](/install/install-k8s-dashboard.html) 图形界面工具
+
+kubectl、kuboard 最终都通过调用 [kubernetes API](https://kubernetes.io/docs/concepts/overview/kubernetes-api/) 来实现对 Kubernetes 对象的操作。您也可以直接在自己的程序中调用 Kubernetes API，此时您可能要有用到 [Client Libraries](https://kubernetes.io/docs/reference/using-api/client-libraries/)
+
+## 对象的spec和status
+
+每一个 Kubernetes 对象都包含了两个重要的字段：
+* `spec` 必须由您来提供，描述了您对该对象所期望的 **目标状态**
+* `status` 只能由 Kubernetes 系统来修改，描述了该对象在 Kubernetes 系统中的 **实际状态**
+
+Kubernetes通过对应的[控制器](/learning/k8s-bg/architecture/controller.html)，不断地使实际状态趋向于您期望的目标状态。
+
+例如，一个 Kubernetes Deployment 对象可以代表一个应用程序在集群中的运行状态。当您创建 Deployment 对象时，您可以通过 Deployment 的 spec 字段指定需要运行应用程序副本数（假设为3）。Kubernetes 从 Deployment 的 spec 中读取这些信息，并为您创建指定容器化应用程序的 3 个副本，再将实际的状态更新到 Deployment 的 status 字段。Kubernetes 系统将不断地比较 **实际状态** staus 和 **目标状态** spec 之间的差异，并根据差异做出对应的调整。例如，如果任何一个副本运行失败了，Kubernetes 将启动一个新的副本，以替代失败的副本。
+
+## 描述Kubernetes对象
+
+当您在 Kubernetes 中创建一个对象时，您必须提供
+* 该对象的 spec 字段，通过该字段描述您期望的 **目标状态**
+* 该对象的一些基本信息，例如名字
+
+如果使用 kubectl 创建对象，您必须编写 `.yaml` 格式的文件，如果通过 Kuboard 图形化工具创建，则在Kuboard 对应的界面功能中完成表单填写即可。
+
+下面是一个 kubectl 可以使用的 `.yaml` 文件：
+
+<<< @/.vuepress/public/statics/learning/obj/deployment.yaml
+
+使用 kube apply 命令可以创建该 `.yaml` 文件中的 Deployment 对象：
+
+``` sh
+kubectl apply -f https://kuboard.cn/statics/learning/obj/deployment.yaml
+```
+
+输出结果如下所示：
+```
+deployment.apps/nginx-deployment created
+```
+
+使用 kubectl delete 命令可以删除该 `.yaml` 文件中的 Deployment 对象：
+
+``` sh
+kubectl delete -f https://kuboard.cn/statics/learning/obj/deployment.yaml
+```
+
+## 必填字段
+
+在上述的 `.yaml` 文件中，如下字段是必须填写的：
+
+* **apiVersion** 用来创建对象时所使用的Kubernetes API版本
+* **kind** 被创建对象的类型
+* **metadata** 用于唯一确定该对象的元数据：包括 `name` 和 `namespace`，如果 `namespace` 为空，则默认值为 `default`
+* **spec** 描述您对该对象的期望状态
+
+不同类型的 Kubernetes，其 `spec` 对象的格式不同（含有不同的内嵌字段），通过 [API 手册](https://kubernetes.io/docs/reference/#api-reference) 可以查看 Kubernetes 对象的字段和描述。例如，假设您想了解 Pod 的 `spec` 定义，可以在 [这里](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.16/#podspec-v1-core)找到，Deployment 的 `spec` 定义可以在 [这里](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.16/#deploymentspec-v1-apps) 找到。
diff --git a/learning/k8s-intermediate/obj/labels.md b/learning/k8s-intermediate/obj/labels.md
new file mode 100644
index 0000000..325b5ff
--- /dev/null
+++ b/learning/k8s-intermediate/obj/labels.md
@@ -0,0 +1,14 @@
+---
+# vssueId: 133
+layout: LearningLayout
+description: Kubernetes教程_本文描述了Kubernetes对象与Kubernetes_API的关系_以及您如何在.yaml格式的文件中定义Kubernetes对象
+meta:
+ - name: keywords
+ content: Kubernetes对象,Kubernetes Object
+---
+
+# Labels and Selectors
+
+
+
+正在撰写 ...
diff --git a/learning/k8s-intermediate/obj/manage.md b/learning/k8s-intermediate/obj/manage.md
new file mode 100644
index 0000000..d9c0dc1
--- /dev/null
+++ b/learning/k8s-intermediate/obj/manage.md
@@ -0,0 +1,169 @@
+---
+vssueId: 134
+layout: LearningLayout
+description: Kubernetes教程_kubectl_命令行工具支持多种途径以创建和管理Kubernetes对象_本文档描述了3种不同的方式
+meta:
+ - name: keywords
+ content: Kubernetes对象,管理Kubernetes对象,Kubernetes Object
+---
+
+# 管理Kubernetes对象
+
+
+
+> 参考文档： [Kubernetes Object Management](https://kubernetes.io/docs/concepts/overview/working-with-objects/object-management/)
+
+kubectl 命令行工具支持多种途径以创建和管理 Kubernetes 对象。本文档描述了3种不同的方式。更多的细节，请参考 [Kubectl book](https://kubectl.docs.kubernetes.io/)
+
+
+
+
+
+## 管理方式
+
+| 管理方式 | 操作对象 | 推荐的环境 | 参与编辑的人数 | 学习曲线 |
+| ---------------- | ---------------------------- | ---------- | -------------- | -------- |
+| 指令性的命令行 | Kubernetes对象 | 开发环境 | 1+ | 最低 |
+| 指令性的对象配置 | 单个 yaml 文件 | 生产环境 | 1 | 适中 |
+| 声明式的对象配置 | 包含多个 yaml 文件的多个目录 | 生产环境 | 1+ | 最高 |
+
+::: danger
+
+同一个Kubernetes对象应该只使用一种方式管理，否则可能会出现不可预期的结果
+
+:::
+
+
+
+::: tip Kuboard
+
+* kubectl 是 Kubernetes 官方的管理工具，由于命令行 + yaml 文件这个特性，其操作难度和学习曲线都是很高的，作为 Kubernetes 的资深用户，是需要学会如何使用 kubectl 的。在实际生产环境的使用中，作者推荐大家使用 Kuboard，Kuboard 是一款免费的基于Kubernetes的微服务管理界面，已经在许多的生产环境中得到了检验。
+* Kuboard 可以和 kubectl 配合使用，但是您必须对两者都有所了解。
+
+:::
+
+## 指令性的命令行
+
+当使用指令性的命令行（imperative commands）时，用户通过向 `kubectl` 命令提供参数的方式，直接操作集群中的 Kubernetes 对象。此时，用户无需编写或修改 `.yaml` 文件。
+
+这是在 Kubernetes 集群中执行一次性任务的一个简便的办法。由于这种方式直接修改 Kubernetes 对象，也就无法提供历史配置查看的功能。
+
+### 例子
+
+创建一个 Deployment 对象，以运行一个 nginx 实例：
+
+``` sh
+kubectl run nginx --image nginx
+```
+下面的命令完成了相同的任务，但是命令格式不同：
+``` sh
+kubectl create deployment nginx --image nginx
+```
+
+### 优缺点
+
+与编写 `.yaml` 文件进行配置的方式相比的优势：
+* 命令简单，易学易记
+* 只需要一个步骤，就可以对集群执行变更
+
+缺点：
+* 使用命令，无法进行变更review的管理
+* 不提供日志审计
+* 没有创建新对象的模板
+
+## 指令性的对象配置
+
+使用指令性的对象配置（imperative object configuration）时，需要向 kubectl 命令指定具体的操作（create,replace,apply,delete等），可选参数以及至少一个配置文件的名字。配置文件中必须包括一个完整的对象的定义，可以是 yaml 格式，也可以是 json 格式。
+
+::: warning
+`replace` 指令将直接使用对象中新的 spec 内容替换原有的 spec 内容，如果原有spec中存在配置文件中没有定义的字段，都将被丢弃。这种方法不能够应用在那些 spec 对象独立于配置文件进行更新的情况。例如 `LoadBalancer` 类型的 Service，其 spec 中的 `externalIPs` 字段由集群更新。
+:::
+
+### 例子
+
+通过配置文件创建对象
+
+``` sh
+kubectl create -f nginx.yaml
+```
+
+删除两个配置文件中的对象
+
+``` sh
+kubectl delete -f nginx.yaml -f redis.yaml
+```
+
+直接使用配置文件中的对象定义，替换Kubernetes中对应的对象：
+
+``` sh
+kubectl replace -f nginx.yaml
+```
+
+### 优缺点
+
+与指令性命令行相比的优点：
+* 对象配置文件可以存储在源代码管理系统中，例如 git
+* 对象配置文件可以整合进团队的变更管理流程，并进行审计和复核
+* 对象配置文件可以作为一个模板，直接用来创建新的对象
+
+与指令性命令行相比的缺点：
+* 需要理解对象配置文件的基本格式
+* 需要额外编写 yaml 文件
+
+与声明式的对象配置相比的优点：
+* 指令性的对象配置更简单更易于理解
+* 指令性的对象配置更成熟
+
+与声明式的对象配置相比的缺点：
+* 指令性的对象配置基于文件进行工作，而不是目录
+* 如果直接更新 Kubernetes 中对象，最好也同时修改配置文件，否则在下一次替换时，这些更新将丢失
+
+## 声明式的对象配置
+
+当使用声明式的对象配置时，用户操作本地存储的Kubernetes对象配置文件，然而，在将文件传递给 kubectl 命令时，并不指定具体的操作，由 kubectl 自动检查每一个对象的状态并自行决定是创建、更新、还是删除该对象。使用这种方法时，可以直接针对一个或多个文件目录进行操作（对不同的对象可能需要执行不同的操作）。
+
+::: tip
+声明式对象配置将保留其他用户对Kubernetes对象的更新，即使这些更新没有合并到对象配置文件中。因为当Kubernetes中已经存在该对象时，声明式对象配置使用 `patch` API接口，此时会把变化的内容更新进去，而不是使用 `replace` API接口，该接口替换整个 spec 信息。
+:::
+
+### 例子
+
+处理 `configs` 目录中所有配置文件中的Kubernetes对象，根据情况创建对象、或更新Kubernetes中已经存在的对象。可以先执行 `diff` 指令查看具体的变更，然后执行 `apply` 指令执行变更：
+
+``` sh
+kubectl diff -f configs/
+kubectl apply -f configs/
+```
+
+递归处理目录中的内容：
+
+``` sh
+kubectl diff -R -f configs/
+kubectl apply -R -f configs/
+```
+
+### 优缺点
+
+与指令性的对象配置相比，优点有：
+* 直接针对Kubernetes已有对象的修改将被保留，即使这些信息没有合并到配置文件中。（译者注：也许这是一个缺点？因为我不敢相信我的配置文件了，或者我要禁止使用其他手段修改Kubernetes中已有的对象）
+* 声明式的对象配置可以支持多文件目录的处理，可以自动探测应该对具体每一个对象执行什么操作（创建、更新、删除）
+
+缺点：
+* 声明式的对象配置复杂度更高，Debug更困难
+* 部分更新对象时，带来复杂的合并操作
+
+## 延伸阅读
+
+* [Managing Kubernetes Objects Using Imperative Commands](https://kubernetes.io/docs/tasks/manage-kubernetes-objects/imperative-command/)
+* [Managing Kubernetes Objects Using Object Configuration (Imperative)](https://kubernetes.io/docs/tasks/manage-kubernetes-objects/imperative-config/)
+* [Managing Kubernetes Objects Using Object Configuration (Declarative)](https://kubernetes.io/docs/tasks/manage-kubernetes-objects/declarative-config/)
+* [Managing Kubernetes Objects Using Kustomize (Declarative)](https://kubernetes.io/docs/tasks/manage-kubernetes-objects/kustomization/)
+* [Kubectl Command Reference](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands/)
+* [Kubectl Book](https://kubectl.docs.kubernetes.io/)
+* [Kubernetes API Reference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.16/)
+
+::: tip
+作者在实际部署一个 30+ 微服务部署单元的 Spring Cloud 应用时，编写了 40 多个 YAML 文件，每个 YAML 文件多达 100-500 行配置。为了使同一套 YAML 文件能够适应开发、测试、生产环境，将其分成 base、dev、test、staging、prod 等目录，使用 [kustomize](https://github.com/kubernetes-sigs/kustomize) 将公共部分提取到 base 中。在经历了如此这般的痛苦之后，编写了 Kuboard。
+
+从更好地学习和理解 Kubernetes 的角度来说，是一定要学会如何使用 kubectl 的，实际在 Kubernetes 上部署微服务应用时，您会发现 Kuboard 用起来更顺手。
+:::
diff --git a/learning/k8s-intermediate/obj/names.md b/learning/k8s-intermediate/obj/names.md
new file mode 100644
index 0000000..07952f8
--- /dev/null
+++ b/learning/k8s-intermediate/obj/names.md
@@ -0,0 +1,55 @@
+---
+vssueId: 135
+layout: LearningLayout
+description: Kubernetes教程_Kubernetes_REST_API中_所有的对象都是通过_name_和_UID_唯一性确定
+meta:
+ - name: keywords
+ content: Kubernetes 对象,管理Kubernetes对象,Kubernetes Object
+---
+
+# 名称
+
+
+
+Kubernetes REST API 中，所有的对象都是通过 `name` 和 `UID` 唯一性确定。查看文档 [identifiers design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/identifiers.md) 可了解更多关于 `name` 和 `UID` 的规则。
+
+* [Names](#Names)
+* [UIDs](#UIDs)
+
+
+
+## Names
+
+可以通过 `namespace` + `name` 唯一性地确定一个 RESTFUL 对象，例如：
+
+`/api/v1/namespaces/{namespace}/pods/{name}`
+
+参考 [名称空间](./namespaces.html)
+
+同一个名称空间下，同一个类型的对象，可以通过 `name` 唯一性确定。如果删除该对象之后，可以再重新创建一个同名对象。
+
+依据命名规则，Kubernetes对象的名字应该：
+* 最长不超过 253个字符
+* 必须由小写字母、数字、减号 `-`、小数点 `.` 组成
+* 某些资源类型有更具体的要求
+
+例如，下面的配置文件定义了一个 name 为 `nginx-demo` 的 Pod，该 Pod 包含一个 name 为 `nginx` 的容器：
+
+``` yaml {4,7}
+apiVersion: v1
+kind: Pod
+metadata:
+ name: nginx-demo
+spec:
+ containers:
+ - name: nginx
+ image: nginx:1.7.9
+ ports:
+ - containerPort: 80
+```
+
+## UIDs
+
+UID 是由 Kubernetes 系统生成的，唯一标识某个 Kubernetes 对象的字符串。
+
+Kubernetes集群中，没创建一个对象，都有一个唯一的 UID。用于区分多次创建的同名对象（如前所述，按照名字删除对象后，重新再创建同名对象时，两次创建的对象 name 相同，但是 UID 不同。）
diff --git a/learning/k8s-intermediate/obj/namespace-op.md b/learning/k8s-intermediate/obj/namespace-op.md
new file mode 100644
index 0000000..c3b5be1
--- /dev/null
+++ b/learning/k8s-intermediate/obj/namespace-op.md
@@ -0,0 +1,14 @@
+---
+# vssueId: 133
+layout: LearningLayout
+description: Kubernetes教程_本文描述了Kubernetes对象与Kubernetes_API的关系_以及您如何在.yaml格式的文件中定义Kubernetes对象
+meta:
+ - name: keywords
+ content: Kubernetes对象,Kubernetes Object
+---
+
+# Share a Cluster with Namespaces
+
+
+
+正在撰写 ...
diff --git a/learning/k8s-intermediate/obj/namespaces.md b/learning/k8s-intermediate/obj/namespaces.md
new file mode 100644
index 0000000..39ccf4a
--- /dev/null
+++ b/learning/k8s-intermediate/obj/namespaces.md
@@ -0,0 +1,97 @@
+---
+vssueId: 136
+layout: LearningLayout
+description: Kubernetes教程_Kubernetes通过名称空间（namespace）在同一个物理集群上支持多个虚拟集群。
+meta:
+ - name: keywords
+ content: Kubernetes Ingress,Ingress
+---
+
+# 名称空间
+
+
+
+> 参考文档：
+
+Kubernetes通过名称空间（namespace）在同一个物理集群上支持多个虚拟集群。
+
+* [何时使用名称空间](#何时使用名称空间)
+* [如何使用名称空间](#如何使用名称空间)
+* [名称空间与DNS](#名称空间与DNS)
+* [并非所有对象都在名称空间里](#并非所有对象都在名称空间里)
+
+
+
+
+## 何时使用名称空间
+
+名称空间的用途是，为不同团队的用户（或项目）提供虚拟的集群空间，也可以用来区分开发环境/测试环境、准上线环境/生产环境。
+
+名称空间为 [名称](./names.html) 提供了作用域。名称空间内部的同类型对象不能重名，但是跨名称空间可以有同名同类型对象。名称空间不可以嵌套，任何一个Kubernetes对象只能在一个名称空间中。
+
+名称空间可以用来在不同的团队（用户）之间划分集群的资源，参考 [resource quota](/learning/k8s-advanced/policy/rq.html)
+
+在 Kubernetes 将来的版本中，同名称空间下的对象将默认使用相同的访问控制策略。
+
+当KUbernetes对象之间的差异不大时，无需使用名称空间来区分，例如，同一个软件的不同版本，只需要使用 [labels](./labels.html) 来区分即可。
+
+## 如何使用名称空间
+
+参考 [管理名称空间](./namespace-op.html) 了解如何创建和删除名称空间。
+
+### 查看名称空间
+
+执行命令 `kubectl get namespaces` 可以查看名称空间，输出结果如下所示：
+
+```
+NAME STATUS AGE
+default Active 1d
+kube-system Active 1d
+kube-public Active 1d
+```
+
+::: tip
+Kuboard 中，登录以后，集群概览页的上方就是名称空间，请参考 [名称空间管理](/guide/cluster/namespace.html)
+:::
+
+Kubernetes 安装成功后，默认有初始化了三个名称空间：
+* **default** 默认名称空间，如果 Kubernetes 对象中不定义 `metadata.namespace` 字段，该对象将放在此名称空间下
+* **kube-system** Kubernetes系统创建的对象放在此名称空间下
+* **kube-public** 此名称空间自动在安装集群是自动创建，并且所有用户都是可以读取的（即使是那些未登录的用户）。主要是为集群预留的，例如，某些情况下，某些Kubernetes对象应该被所有集群用户看到。
+
+### 在执行请求时设定namespace
+
+执行 kubectl 命令时，可以使用 `--namespace` 参数指定名称空间，例如：
+
+``` sh
+kubectl run nginx --image=nginx --namespace=<您的名称空间>
+kubectl get pods --namespace=<您的名称空间>
+```
+
+### 设置名称空间偏好
+
+可以通过 `set-context` 命令改变当前 [kubectl 上下文](/install/config-kubectl.html#切换当前访问的集群) 的名称空间，后续所有命令都默认在此名称空间下执行。
+
+``` sh
+kubectl config set-context --current --namespace=<您的名称空间>
+# 验证结果
+kubectl config view --minify | grep namespace:
+```
+
+## 名称空间与DNS
+
+当您创建一个 Service 时，Kubernetes 为其创建一个对应的 [DNS 条目](/learning/k8s-intermediate/service/dns.html)。该 DNS 记录的格式为 `..svc.cluster.local`，也就是说，如果在容器中只使用 ``，其DNS将解析到同名称空间下的 Service。这个特点在多环境的情况下非常有用，例如将开发环境、测试换寂静、生产环境部署在不同的名称空间下，应用程序只需要使用 `` 即可进行服务发现，无需为不同的环境修改配置。如果您想跨名称空间访问服务，则必须使用完整的域名（fully qualified domain name，FQDN）。
+
+## 并非所有对象都在名称空间里
+
+大部分的 Kubernetes 对象（例如，Pod、Service、Deployment、StatefulSet等）都必须在名称空间里。但是某些更低层级的对象，是不在任何名称空间中的，例如 [nodes](/learning/k8s-bg/architecture/nodes.html)、[persistentVolumes](/learning/k8s-intermediate/persistent/pv.html)、[storageClass](/learning/k8s-intermediate/persistent/storage-class.html) 等
+
+执行一下命令可查看哪些 Kubernetes 对象在名称空间里，哪些不在：
+
+``` sh
+# 在名称空间里
+kubectl api-resources --namespaced=true
+
+# 不在名称空间里
+kubectl api-resources --namespaced=false
+```
diff --git a/learning/k8s-intermediate/service/host-alias.md b/learning/k8s-intermediate/service/host-alias.md
index e0a5939..72acfc7 100644
--- a/learning/k8s-intermediate/service/host-alias.md
+++ b/learning/k8s-intermediate/service/host-alias.md
@@ -1,5 +1,5 @@
---
-vssueId: 132=
+vssueId: 132
layout: LearningLayout
description: Kubernetes教程_某些情况下_DNS或者其他的域名解析方法可能不太适用_您需要配置_/etc/hosts文件_在Linux下是比较容易做到的_在Kubernetes中_可以通过Pod定义中的_`hostAliases`_字段向Pod的/etc/hosts添加条目。
meta:
@@ -111,7 +111,9 @@ fe00::2 ip6-allrouters
Kubelet [管理](https://github.com/kubernetes/kubernetes/issues/14633) `hosts` Pod 中每个容器的 hosts 文件，以便可以阻止 Docker 在容器启动以后 [修改](https://github.com/moby/moby/issues/17190) 该文件。
细节情况请参考两个 github issue：
+
[https://github.com/kubernetes/kubernetes/issues/14633](https://github.com/kubernetes/kubernetes/issues/14633)
+
[https://github.com/moby/moby/issues/17190](https://github.com/moby/moby/issues/17190)
由于该文件已经被 Kubelet 管理起来，任何对该文件手工修改的内容，都将在 Kubelet 重启容器或者 Pod 重新调度时被覆盖。因此，最好是通过 `hostAliases` 修改 Pod 的 /etc/hosts 文件，而不是手工修改。