diff --git a/.vuepress/components/StarGazer.vue b/.vuepress/components/StarGazer.vue
index 38998a7..a940369 100644
--- a/.vuepress/components/StarGazer.vue
+++ b/.vuepress/components/StarGazer.vue
@@ -58,7 +58,7 @@ export default {
localStorage.setItem('FIRST_ACCESS', new Date())
} else {
// console.log('differenceInMinutes', differenceInMinutes(new Date(), new Date(firstAccess)))
- if (differenceInMinutes(new Date(), new Date(firstAccess)) >= 12 && !this.dialogVisible) {
+ if (differenceInMinutes(new Date(), new Date(firstAccess)) >= 15 && !this.dialogVisible) {
this.show()
}
}
diff --git a/.vuepress/config.js b/.vuepress/config.js
index 2ae0f36..45d48d8 100644
--- a/.vuepress/config.js
+++ b/.vuepress/config.js
@@ -1,7 +1,7 @@
let dateFns = require('date-fns')
module.exports = {
- title: 'Kuboard - Kubernetes k8s 国内安装/部署/入门/免费中文教程/实践/微服务管理界面',
+ title: 'Kuboard - Kubernetes 微服务管理界面',
description: '一个非常 cool 的 Kubernetes Dashboard，简化 Kubernetes 的学习和使用，帮助您快速落地 Kubernetes；提供 Kubernetes 免费中文教程、国内安装文档',
head: [
['meta', {name: 'keywords', content: 'Kubernetes, Docker, Dashboard, Kuboard, Spring Cloud, micro service, DevOps, 微服务, 持续构建集成, Kubernetes 中文教程, Kubernetes 入门, K8S 教程, K8S 入门, 微服务实践, Kubernetes 国内安装, K8S 安装, Kubernetes 安装, Kubernetes 部署'}],
@@ -45,9 +45,9 @@ module.exports = {
'code-switcher': {},
'reading-progress': {},
'vuepress-plugin-element-tabs': {},
- 'vuepress-plugin-baidu-autopush':{},
+ // 'vuepress-plugin-baidu-autopush':{},
'sitemap': {
- hostname: 'https://www.kuboard.cn'
+ hostname: 'https://kuboard.cn'
},
'seo': {
siteTitle: (_, $site) => $site.title,
@@ -238,6 +238,7 @@ module.exports = {
children: [
'k8s-intermediate/service/service',
'k8s-intermediate/service/service-details',
+ 'k8s-intermediate/service/service-types',
// 'k8s-intermediate/service/dns',
// 'k8s-intermediate/service/connecting',
'k8s-intermediate/service/ingress',
diff --git a/.vuepress/styles/index.styl b/.vuepress/styles/index.styl
index 7fd080e..02fdf4f 100644
--- a/.vuepress/styles/index.styl
+++ b/.vuepress/styles/index.styl
@@ -14,7 +14,7 @@ p img {
p code {
/*border: 1px solid #007af5;*/
- color: #007af5 !important;
+ //color: #007af5 !important;
}
.noselect {
diff --git a/.vuepress/theme/layouts/Layout.vue b/.vuepress/theme/layouts/Layout.vue
index 2c5e7a2..ed921bb 100644
--- a/.vuepress/theme/layouts/Layout.vue
+++ b/.vuepress/theme/layouts/Layout.vue
@@ -30,7 +30,22 @@
- Copyright © 2019-present 邵欢庆
仁聚汇通 | 京ICP备19008693号-2
Copyright © 2019-present 邵欢庆
仁聚汇通 | 京ICP备19008693号-2
+
+
Copyright © 2019-present 邵欢庆
仁聚汇通 | 京ICP备19008693号-2
Copyright © 2019-present 邵欢庆
仁聚汇通 | 京ICP备19008693号-2
+
+
+ 
+
+
+### Iptables 代理模式
+
+**在 iptables proxy mode 下：**
+
+* kube-proxy 监听 kubernetes master 以获得添加和移除 Service / Endpoint 的事件
+* kube-proxy 在其所在的节点（每个节点都有 kube-proxy）上为每一个 Service 安装 iptable 规则
+* iptables 将发送到 Service 的 ClusterIP / Port 的请求重定向到 Service 的后端 Pod 上
+ * 对于 Service 中的每一个 Endpoint，kube-proxy 安装一个 iptable 规则
+ * 默认情况下，kube-proxy 随机选择一个 Service 的后端 Pod
+
+如下图所示：
+
+ 
+
+
+**iptables proxy mode 的优点：**
+
+* 更低的系统开销：在 linux netfilter 处理请求，无需在 userspace 和 kernel space 之间切换
+* 更稳定
+
+**与 user space mode 的差异：**
+
+* 使用 iptables mode 时，如果第一个 Pod 没有响应，则创建连接失败
+* 使用 user space mode 时，如果第一个 Pod 没有响应，kube-proxy 会自动尝试连接另外一个后端 Pod
+
+您可以配置 Pod 就绪检查（readiness probe）确保后端 Pod 正常工作，此时，在 iptables 模式下 kube-proxy 将只使用健康的后端 Pod，从而避免了 kube-proxy 将请求转发到已经存在问题的 Pod 上。
+
+### IPVS 代理模式
+
+**在 IPVS proxy mode 下：**
+
+* kube-proxy 监听 kubernetes master 以获得添加和移除 Service / Endpoint 的事件
+* kube-proxy 根据监听到的事件，调用 netlink 接口，创建 IPVS 规则；并且将 Service/Endpoint 的变化同步到 IPVS 规则中
+* 当访问一个 Service 时，IPVS 将请求重定向到后端 Pod
+
+
+ 
+
+
+**IPVS 模式的优点**
+
+IPVS proxy mode 基于 netfilter 的 hook 功能，与 iptables 代理模式相似，但是 IPVS 代理模式使用 hash table 作为底层的数据结构，并在 kernel space 运作。这就意味着
+* IPVS 代理模式可以比 iptables 代理模式有更低的网络延迟，在同步代理规则时，也有更高的效率
+* 与 user space 代理模式 / iptables 代理模式相比，IPVS 模式可以支持更大的网络流量
+
+**IPVS 提供更多的负载均衡选项：**
+* rr: round-robin
+* lc: least connection (最小打开的连接数)
+* dh: destination hashing
+* sh: source hashing
+* sed: shortest expected delay
+* nq: never queue
+
+::: tip
+* 如果要使用 IPVS 模式，您必须在启动 kube-proxy 前为节点的 linux 启用 IPVS
+* kube-proxy 以 IPVS 模式启动时，如果发现节点的 linux 未启用 IPVS，则退回到 iptables 模式
+:::
+
+### 代理模式总结
+
+在所有的代理模式中，发送到 Service 的 IP:Port 的请求将被转发到一个合适的后端 Pod，而无需调用者知道任何关于 Kubernetes/Service/Pods 的细节。
+
+Service 中额外字段的作用：
+* `service.spec.sessionAffinity`
+ * 默认值为 "None"
+ * 如果设定为 "ClientIP"，则同一个客户端的连接将始终被转发到同一个 Pod
+* `service.spec.sessionAffinityConfig.clientIP.timeoutSeconds`
+ * 默认值为 10800 （3 小时）
+ * 设定会话保持的持续时间
+
+## 多端口的Service
+
+Kubernetes 中，您可以在一个 Service 对象中定义多个端口，此时，您必须为每个端口定义一个名字。如下所示：
+
+``` yaml
+apiVersion: v1
+kind: Service
+metadata:
+ name: my-service
+spec:
+ selector:
+ app: MyApp
+ ports:
+ - name: http
+ protocol: TCP
+ port: 80
+ targetPort: 9376
+ - name: https
+ protocol: TCP
+ port: 443
+ targetPort: 9377
+```
+
+::: tip
+端口的名字必须符合 Kubernetes 的命名规则，且，端口的名字只能包含小写字母、数字、`-`，并且必须以数字或字母作为开头及结尾。
+
+例如：
+
+合法的 Port 名称：`123-abc`、`web`
+
+非法的 Port 名称：`123_abc`、`-web`
+:::
+
+## 使用自定义的 IP 地址
+
+创建 Service 时，如果指定 `.spec.clusterIP` 字段，可以使用自定义的 Cluster IP 地址。该 IP 地址必须是 APIServer 中配置字段 `service-cluster-ip-range` CIDR 范围内的合法 IPv4 或 IPv6 地址，否则不能创建成功。
+
+可能用到自定义 IP 地址的场景：
+* 想要重用某个已经存在的 DNS 条目
+* 遗留系统是通过 IP 地址寻址，且很难改造
+
+## 服务发现
+
+Kubernetes 支持两种主要的服务发现模式：
+* 环境变量
+* DNS
+
+### 环境变量
+
+kubelet 查找有效的 Service，并针对每一个 Service，向其所在节点上的 Pod 注入一组环境变量。支持的环境变量有：
+* [Docker links 兼容](https://docs.docker.com/network/links/) 的环境变量
+* {SVCNAME}_SERVICE_HOST 和 {SVCNAME}_SERVICE_PORT
+ * Service name 被转换为大写
+ * 小数点 `.` 被转换为下划线 `_`
+
+例如，Service `redis-master` 暴露 TCP 端口 6379，其 Cluster IP 为 10.0.0.11，对应的环境变量如下所示：
+
+``` s
+REDIS_MASTER_SERVICE_HOST=10.0.0.11
+REDIS_MASTER_SERVICE_PORT=6379
+REDIS_MASTER_PORT=tcp://10.0.0.11:6379
+REDIS_MASTER_PORT_6379_TCP=tcp://10.0.0.11:6379
+REDIS_MASTER_PORT_6379_TCP_PROTO=tcp
+REDIS_MASTER_PORT_6379_TCP_PORT=6379
+REDIS_MASTER_PORT_6379_TCP_ADDR=10.0.0.11
+```
+
+::: tip
+如果要在 Pod 中使用基于环境变量的服务发现方式，必须先创建 Service，再创建调用 Service 的 Pod。否则，Pod 中不会有该 Service 对应的环境变量。
+
+如果使用基于 DNS 的服务发现，您无需担心这个创建顺序的问题
+:::
+
+### DNS
+
+如果按照 www.kuboard.cn 上的文档安装 Kubernetes，默认已经安装了 DNS 服务，[Core DNS](https://coredns.io/)。
+
+CoreDNS 监听 Kubernetes API 上创建和删除 Service 的事件，并为每一个 Service 创建一条 DNS 记录。集群中所有的 Pod 都可以使用 DNS Name 解析到 Service 的 IP 地址。
+
+例如，名称空间 `my-ns` 中的 Service `my-service`，将对应一条 DNS 记录 `my-service.my-ns`。 名称空间 `my-ns` 中的Pod可以直接 `nslookup my-service` （`my-service.my-ns` 也可以）。其他名称空间的 Pod 必须使用 `my-service.my-ns`。`my-service` 和 `my-service.my-ns` 都将被解析到 Service 的 Cluster IP。
+
+Kubernetes 同样支持 DNS SRV（Service）记录，用于查找一个命名的端口。假设 `my-service.my-ns` Service 有一个 TCP 端口名为 `http`，则，您可以 `nslookup _http._tcp.my-service.my-ns` 以发现该Service 的 IP 地址及端口 `http`
+
+对于 `ExternalName` 类型的 Service，只能通过 DNS 的方式进行服务发现。参考 [Service/Pod 的 DNS](./dns.html)
+
+## Headless Services
+
+“Headless” Service 不提供负载均衡的特性，也没有自己的 IP 地址。创建 “headless” Service 时，只需要指定 `.spec.clusterIP` 为 "None"。
+
+“Headless” Service 可以用于对接其他形式的服务发现机制，而无需与 Kubernetes 的实现绑定。
+
+对于 “Headless” Service 而言：
+* 没有 Cluster IP
+* kube-proxy 不处理这类 Service
+* Kubernetes不提供负载均衡或代理支持
+
+DNS 的配置方式取决于该 Service 是否配置了 selector：
+
+* 配置了 Selector
+
+ Endpoints Controller 创建 `Endpoints` 记录，并修改 DNS 配置，使其直接返回指向 selector 选取的 Pod 的 IP 地址
+
+* 没有配置 Selector
+
+ Endpoints Controller 不创建 `Endpoints` 记录。DNS服务返回如下结果中的一种：
+ * 对 ExternalName 类型的 Service，返回 CNAME 记录
+ * 对于其他类型的 Service，返回与 Service 同名的 `Endpoints` 的 A 记录
## 支持的传输协议
-
-## Service 类型
-
-### ClusterIP
-
-### NodePort
-
-### LoadBalancer
-
-### ExternalName
+未完，待续，【2019年9月18日 22:33】
diff --git a/learning/k8s-intermediate/service/service-types.md b/learning/k8s-intermediate/service/service-types.md
new file mode 100644
index 0000000..594f112
--- /dev/null
+++ b/learning/k8s-intermediate/service/service-types.md
@@ -0,0 +1,40 @@
+---
+layout: LearningLayout
+description: Kubernetes 中发布 Service 的方式，ServiceType
+---
+
+# Service 类型
+
+Kubernetes 中可以通过不同方式发布 Service，通过 `ServiceType` 字段指定，该字段的默认值是 `ClusterIP`，可选值有：
+
+* **ClusterIP**: 默认值。通过集群内部的一个 IP 地址暴露 Service，只在集群内部可以访问
+
+* **NodePort**: 通过每一个节点上的的静态端口（NodePort）暴露 Service，同时自动创建 ClusterIP 类型的访问方式
+ * 在集群内部通过 $(ClusterIP): $(Port) 访问
+ * 在集群外部通过 $(NodeIP): $(NodePort) 访问
+
+* **LoadBalancer**: 通过云服务供应商（AWS、Azure、GCE 等）的负载均衡器在集群外部暴露 Service，同时自动创建 NodePort 和 ClusterIP 类型的访问方式
+ * 在集群内部通过 $(ClusterIP): $(Port) 访问
+ * 在集群外部通过 $(NodeIP): $(NodePort) 访问
+ * 在集群外部通过 $(LoadBalancerIP): $(Port) 访问
+
+ ::: tip 替代方案
+ * LoadBalancer 类型的 Service，可以自动调用云服务商在 IaaS 层面的接口，并自动创建 LoadBalancer，将其指向该 Service。
+ * 由于 Kuboard 不限定云服商，因此不能实现此类型的 Service，建议用户先创建 NodePort 类型的 Service，再手工创建 LoadBalancer，将其配置到各节点上对应的 Service 的 NodePort。此操作最终效果与 LoadBalancer 类型 Service 的效果相同
+ :::
+
+* **ExternalName**: 将 Service 映射到 `externalName` 指定的地址（例如：foo.bar.example.com），返回值是一个 CNAME 记录。不使用任何代理机制。
+
+ ::: tip
+ 如使用 ExternalName 类型的 Service，CoreDNS 版本不能低于 1.7
+ :::
+
+## ClusterIP
+
+未完，待续，【2019年9月18日 22:56】
+
+## NodePort
+
+## LoadBalancer
+
+## ExternalName
diff --git a/learning/k8s-intermediate/service/service.md b/learning/k8s-intermediate/service/service.md
index 8ed36b0..b322187 100644
--- a/learning/k8s-intermediate/service/service.md
+++ b/learning/k8s-intermediate/service/service.md
@@ -16,7 +16,7 @@ Kubernetes 中 Pod 是随时可以消亡的（节点故障、容器内应用程
Service 存在的意义，就是为了解决这个问题。
-## Service
+## Kubernetes Service
Kubernetes 中 Service 是一个 API 对象，通过 kubectl + YAML 或者 Kuboard，定义一个 Service，可以将符合 Service 指定条件的 Pod 作为可通过网络访问的服务提供给服务调用者。
diff --git a/learning/k8s-intermediate/workload/pod-privileged.md b/learning/k8s-intermediate/workload/pod-privileged.md
new file mode 100644
index 0000000..562ce57
--- /dev/null
+++ b/learning/k8s-intermediate/workload/pod-privileged.md
@@ -0,0 +1,12 @@
+---
+description: 在 Kubernetes 中为 Pod 中的容器开启 privileged 模式
+---
+
+# 容器组 - Privileged 模式
+
+
+## Privilged 模式运行容器
+
+Pod 中的任何容器都可以开启 privileged 模式，只需要
+
+Any container in a Pod can enable privileged mode, using the privileged flag on the security context of the container spec. This is useful for containers that want to use Linux capabilities like manipulating the network stack and accessing devices. Processes within the container get almost the same privileges that are available to processes outside a container. With privileged mode, it should be easier to write network and volume plugins as separate Pods that don’t need to be compiled into the kubelet.
diff --git a/support/change-log/change-log-on-the-way.md b/support/change-log/change-log-on-the-way.md
index b9fcea5..cb10da5 100644
--- a/support/change-log/change-log-on-the-way.md
+++ b/support/change-log/change-log-on-the-way.md
@@ -1,6 +1,6 @@
Kuboard v1.0.x 的更新说明
-## v1.0.3-beta.4
+## v1.0.3-beta.5
**发布日期**
@@ -13,17 +13,21 @@ Kuboard v1.0.x 的更新说明
**BUG 修复**
-* v1.0.3-beta.2 引入的BUG：导入工作负载时，存储卷声明未创建
-* 导入应用程序时，存储卷声明如果不填写，仍然可以下一步
* terminationGracePeriodSeconds
+* Service --> SessionAffinity
+ --> clientIP.timeoutSeconds
+* Service --> .spec.clusterIP
* Firefox 浏览器，从名称空间 后退到集群概览，布局出错
-* 创建工作负载时，不追加前缀
+* 编辑 ConfigMap 时，标签应该可以为空
+* 创建工作负载时，不追加前缀
* 存储卷声明去掉分配模式的字段
* 删除容器组时 - graceful period
* Pod Conditions: lastProbeTime/reason/message
* 按名称空间查看 Events
* 显示 Deployment/StatefulSet/DaemonSet 的事件
* 控制台/日志界面，按 名称空间/工作负载/Pod/容器 进行切换
+* hostPort
+* StatefulSet 在 available 数与 replicas 数不一致时，链接到帮助提示