diff --git a/.vuepress/config-sidebar.js b/.vuepress/config-sidebar.js index a8e2d41..f46d397 100644 --- a/.vuepress/config-sidebar.js +++ b/.vuepress/config-sidebar.js @@ -249,6 +249,7 @@ module.exports = { 'k8s-intermediate/service/np-example', ] }, + 'k8s-intermediate/service/network' ] }, { diff --git a/learning/README.md b/learning/README.md index 3099096..405d36d 100644 --- a/learning/README.md +++ b/learning/README.md @@ -95,6 +95,7 @@ meta: * [Ingress 通过互联网访问您的应用](/learning/k8s-intermediate/service/ingress.html) * [数据卷 Volume](/learning/k8s-intermediate/persistent/volume.html) * [使用port-forward访问集群中的应用程序](/learning/k8s-practice/access/port-forward.html) + * [Kubernetes网络模型](/learning/k8s-intermediate/service/network.html) * 下一步，可按教程章节顺序对 Kubernetes 各种概念进行深入理解 ::: diff --git a/learning/k8s-intermediate/service/network.assets/ingress-controller-design.png b/learning/k8s-intermediate/service/network.assets/ingress-controller-design.png new file mode 100644 index 0000000..4299d48 Binary files /dev/null and b/learning/k8s-intermediate/service/network.assets/ingress-controller-design.png differ diff --git a/learning/k8s-intermediate/service/network.assets/ingress-to-service.gif b/learning/k8s-intermediate/service/network.assets/ingress-to-service.gif new file mode 100644 index 0000000..67bf85f Binary files /dev/null and b/learning/k8s-intermediate/service/network.assets/ingress-to-service.gif differ diff --git a/learning/k8s-intermediate/service/network.md b/learning/k8s-intermediate/service/network.md index 5e55a19..60c708a 100644 --- a/learning/k8s-intermediate/service/network.md +++ b/learning/k8s-intermediate/service/network.md @@ -1,14 +1,14 @@ --- vssueId: 167 layout: LearningLayout -sharingTitle: 深度长文 - 深入理解 Kubernetes 的网络模型 -description: Kubernetes中_网络策略定义了一组Pod是否允许相互通信_或者与网络中的其他端点endpoint通信_本文描述了K8S集群中默认的网络策略 +sharingTitle: 深度长文 - 深入理解 Kubernetes 的网络模型 - 这次我终于弄明白了 +description: Kubernetes用来在集群上运行分布式系统_分布式系统的本质使得网络组件在Kubernetes中是至关重要也不可或缺的_理解 Kubernetes的网络模型可以帮助你更好的在Kubernetes上运行_监控_诊断你的应用程序 meta: - name: keywords content: Kubernetes教程,K8S教程,Kubernetes Network Model, K8S 网络模型 --- -# Network Model +# Kubernetes网络模型 @@ -303,8 +303,44 @@ CoreDNS 的工作方式与 `kubedns` 类似，但是通过插件化的架构构 3. 在 VM2 节点上，kube-proxy 在节点上安装的 iptables 规则会将该数据包的目标地址判定到对应的 Pod 上（集群内负载均衡将生效） 4. iptables 完成 NAT 映射，并将数据包转发到目标 Pod -

+

K8S教程_Kubernetes网络模型_数据包的传递_internet-to-service

-### Layer 7：Ingress控制器 +#### Layer 7：Ingress控制器 + +::: tip 译者注 +本章节讲述的 Ingress 控制器实现方式是特定于 AWS 的，与 [nginx ingress controller](/learning/k8s-intermediate/service/ingress.html) 的具体做法有所不同 +::: + +Layer 7 网络入方向访问在网络堆栈的 HTTP/HTTPS 协议层面工作，并且依赖于 KUbernetes Service。要实现 Layer 7 网络入方向访问，首先需要将 Service 指定为 `NodtePort` 类型，此时 Kubernetes master 将会为该 Service 分配一个 [节点端口](/learning/k8s-intermediate/service/service-types.html#nodeport)，每一个节点上的 iptables 都会将此端口上的请求转发到 Service 的后端 Pod 上。此时，Service-to-Pod 的路由与 [数据包的传递：Service-to-Pod](#数据包的传递：service-to-pod) 的描述相同。 + +接下来，创建一个 Kubernetes [Ingress](/learning/k8s-intermediate/service/ingress.html) 对象可以将该 Service 发布到互联网。Ingress 是一个高度抽象的 HTTP 负载均衡器，可以将 HTTP 请求映射到 Kubernetes Service。在不同的 Kubernetes 集群中，Ingress 的具体实现可能是不一样的。与 Layer 4 的网络负载均衡器相似，HTTP 负载均衡器只理解节点的 IP 地址（而不是 Pod 的 IP 地址），因此，也同样利用了集群内部通过 iptables 实现的负载均衡特性。 + +在 AWS 中，ALB Ingress 控制器使用 Amazon 的 Layer 7 Application Load Balancer实现了 Kubernetes Ingress 的功能。下图展示了 AWS 上 Ingress 控制器的细节，也展示了网络请求是如何从 ALB 路由到 Kubernetes 集群的。 + +![K8S教程_Kubernetes网络模型_Ingress_Controller_Design](./network.assets/ingress-controller-design.png) + +1. ALB Ingress Controller 创建后，将监听 Kubernetes API 上关于 Ingress 的事件。当发现匹配的 Ingress 对象时，Ingress Controller 开始创建 AWS 资源 +2. AWS 使用 Application Load Balancer（ALB）来满足 Ingress 对象的要求，并使用 Target Group 将请求路由到目标节点 +3. ALB Ingress Controller 为 Kubernetes Ingress 对象中用到的每一个 Kubernetes Service 创建一个 AWS Target Group +4. Listener 是一个 ALB 进程，由 ALB Ingress Controller 根据 Ingress 的注解（annotations）创建，监听 ALB 上指定的协议和端口，并接收外部的请求 +5. ALB Ingress Controller 还根据 Kubernetes Ingress 中的路径定义，创建了 Target Group Rule，确保指定路径上的请求被路由到合适的 Kubernetes Service + +#### 数据包的传递：Ingress-to-Service + +Ingress-to-Service 的数据包传递与 LoadBalancer-to-Service 的数据包传递非常相似。核心差别是： +* Ingress 能够解析 URL 路径（可基于路径进行路由） +* Ingress 连接到 Service 的 NodePort + +下图展示了 Ingress-to-Service 的数据包传递过程。 +1. 创建 Ingress 之后，cloud controller 将会为其创建一个新的 Ingress Load Balancer +2. 由于 Load Balancer 并不知道 Pod 的 IP 地址，当路由到达 Ingress Load Balancer 之后，会被转发到集群中的节点上（Service的节点端口） +3. 节点上的 iptables 规则将数据包转发到合适的 Pod +4. Pod 接收到数据包 + +从 Pod 返回的响应数据包将包含 Pod 的 IP 地址，但是请求客户端需要的是 Ingress Load Balancer 的 IP 地址。iptables 和 `conntrack` 被用来重写返回路径上的 IP 地址。 + +

+ K8S教程_Kubernetes网络模型_数据包的传递_Ingress-to-Service +

diff --git a/support/change-log/change-log-on-the-way.md b/support/change-log/change-log-on-the-way.md index b463dcf..86e0903 100644 --- a/support/change-log/change-log-on-the-way.md +++ b/support/change-log/change-log-on-the-way.md @@ -1,12 +1,14 @@ Kuboard v1.0.x 的更新说明 +**优化** + **BUG 修复** - +* 为什么 ping service-name 会失败？ * EndPoint * 导入工作负载时，如果存储类没有 annotations，不应该报错 * 表单校验：数据卷名不能带小数点 diff --git a/t/cka/daily.md b/t/cka/daily.md index 2774487..fbf47df 100644 --- a/t/cka/daily.md +++ b/t/cka/daily.md @@ -48,4 +48,6 @@ CKA证书的含金量如何？考不考这个证完全取决于个人，因为 [CKA每日一题 - Day 4](./daily/004.html) +[CKA每日一题 - Day 5](./daily/005.html) + diff --git a/t/cka/daily/004.md b/t/cka/daily/004.md index e78ee73..53b498c 100644 --- a/t/cka/daily/004.md +++ b/t/cka/daily/004.md @@ -46,10 +46,6 @@ spec: ### 解析 - - -## 昨日解析 - **官网中调度器地址：** https://kubernetes.io/docs/concepts/scheduling/kube-scheduler/ diff --git a/t/cka/daily/005.assets/640-20191126201848208.png b/t/cka/daily/005.assets/640-20191126201848208.png new file mode 100644 index 0000000..5bf8c88 Binary files /dev/null and b/t/cka/daily/005.assets/640-20191126201848208.png differ diff --git a/t/cka/daily/005.assets/640-20191126201848278.png b/t/cka/daily/005.assets/640-20191126201848278.png new file mode 100644 index 0000000..9b3cd9d Binary files /dev/null and b/t/cka/daily/005.assets/640-20191126201848278.png differ diff --git a/t/cka/daily/005.assets/640-20191126201848352.png b/t/cka/daily/005.assets/640-20191126201848352.png new file mode 100644 index 0000000..5ae0f91 Binary files /dev/null and b/t/cka/daily/005.assets/640-20191126201848352.png differ diff --git a/t/cka/daily/005.assets/640-20191126201848354.png b/t/cka/daily/005.assets/640-20191126201848354.png new file mode 100644 index 0000000..78c4b0f Binary files /dev/null and b/t/cka/daily/005.assets/640-20191126201848354.png differ diff --git a/t/cka/daily/005.md b/t/cka/daily/005.md new file mode 100644 index 0000000..c986f93 --- /dev/null +++ b/t/cka/daily/005.md @@ -0,0 +1,196 @@ +--- +vssueId: 170 +# layout: StepLayout +sharingTitle: CKA备考打卡 - 每日一题 - Day 5 +description: CKA备考打卡 - 每日一题 - Day 5 +meta: + - name: keywords + content: Kubernetes,K8S,CKA,Certified Kubernetes Administrator +--- + +# CKA每日一题 --- Day 5 + + + +::: tip 考题 + + + +通过命令行，创建两个deployment。 + +- 需要集群中有2个节点 ； +- 第1个deployment名称为cka-1122-01，使用nginx镜像，有2个pod，并配置该deployment自身的pod之间在节点级别反亲和； +- 第2个deployment名称为cka-1122-02，使用nginx镜像，有2个pod，并配置该deployment的pod与第1个deployment的pod在节点级别亲和； + +**最好提交最精简的deployment yaml，如果评论被限制，请提交反亲和性配置块yaml，也可多次评论提交** + +::: + +答案及解析 + + + +### 答案 + +第一个deployment：cka-1122-01 + +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + labels: + app: cka-1122-01 + name: cka-1122-01 +spec: + replicas: 2 + selector: + matchLabels: + app: cka-1122-01 + template: + metadata: + labels: + app: cka-1122-01 + spec: + containers: + - image: nginx + name: cka-1122-01 + affinity: + podAntiAffinity: + requiredDuringSchedulingIgnoredDuringExecution: + labelSelector: + matchExpressions: + - key: app + operator: In + values: + - cka-1122-01 + topologyKey: "kubernetes.io/hostname" +``` + +## 第二个deployment：cka-1122-02 + +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + labels: + app: cka-1122-02 + name: cka-1122-02 +spec: + replicas: 2 + selector: + matchLabels: + app: cka-1122-02 + template: + metadata: + labels: + app: cka-1122-02 + spec: + containers: + - image: nginx + name: cka-1122-02 + affinity: + podAffinity: + requiredDuringSchedulingIgnoredDuringExecution: + - labelSelector: + matchExpressions: + - key: app + operator: In + values: + - cka-1122-01 + topologyKey: "kubernetes.io/hostname" +``` + +最终调度结果： + +``` sh +NAME READY STATUS RESTARTS AGE IP NODE +cka-1122-01-5df9bdf8c9-qwd2v 1/1 Running 0 8m 10.192.4.2 node-1 +cka-1122-01-5df9bdf8c9-r4rhs 1/1 Running 0 8m 10.192.4.3 node-2 +cka-1122-02-749cd4b846-bjhzq 1/1 Running 0 10m 10.192.4.4 node-1 +cka-1122-02-749cd4b846-rkgpo 1/1 Running 0 10m 10.192.4.5 node-2 +``` + + + + +### 解析 + +**考点：k8s中的高级调度及用法。** + +亲和性和反亲和性调度官方文档： + +[https://kubernetes.io/docs/concepts/configuration/assign-pod-node/](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/) + +中文文档： [https://kuboard.cn/learning/k8s-intermediate/config/assign-pod-node.html](https://kuboard.cn/learning/k8s-intermediate/config/assign-pod-node.html) + +#### 将 Pod 调度到特定的 Node 上：nodeSelector + +nodeSelector是节点选择约束的最简单推荐形式。nodeSelector是PodSpec下的一个字段。它指定键值对的映射。为了使Pod可以在节点上运行，该节点必须具有每个指定的键值对作为label。 + +![CKA每日一题_Day5](./005.assets/640-20191126201848208.png) + +> 语法格式：map[string]string +> +> 作用： +> – 匹配node.labels +> – 排除不包含nodeSelector中指定label的所有node +> – 匹配机制 —— 完全匹配 + +#### nodeSelector 升级版：nodeAffinity + +节点亲和性在概念上类似于nodeSelector，它可以根据节点上的标签来限制Pod可以被调度在哪些节点上。 + +![CKA每日一题_Day5](./005.assets/640-20191126201848278.png) + +**红色框为硬性过滤：**排除不具备指定label的node；在预选阶段起作用； + +**绿色框为软性评分：**不具备指定label的node打低分， 降低node被选中的几率；在优选阶段起作用； + +#### 与nodeSelector关键差异 + +> – 引入运算符：In，NotIn （labelselector语法） – 支持枚举label可能的取值，如 zone in [az1, az2, az3...] – 支持硬性过滤和软性评分 +> +> – 硬性过滤规则支持指定多条件之间的逻辑或运算 – 软性评分规则支持 设置条件权重值 + +#### 让某些 Pod 分布在同一组 Node 上：podAffinity + +Pod亲和性和反亲和性可以基于已经在节点上运行的Pod上的标签而不是基于节点上的标签，来限制Pod调度的节点。 + +**规则的格式为：** + +如果该X已经在运行一个或多个满足规则Y的Pod，则该Pod应该（或者在反亲和性的情况下不应该）在X中运行。 + +Y表示为LabelSelector。X是一个拓扑域，例如节点，机架，云提供者区域，云提供者区域等。 + +![CKA每日一题_Day5](./005.assets/640-20191126201848354.png) + +红框硬性过滤：排除不具备指定pod的node组；在预选阶段起作用；绿框软性评分：不具备指定pod的node组打低分， 降低该组node被选中的几率；在优选阶段起作用； + +#### 与nodeAffinity的关键差异 + +> – 定义在PodSpec中，亲和与反亲和规则具有对称性 – labelSelector的匹配对象为Pod – 对node分组，依据label-key=topologyKey，每个labelvalue取值为一组 +> +> – 硬性过滤规则，条件间只有逻辑与运算 + +#### 避免某些 Pod 分布在同一组 Node 上：podAntiAffinity + +![CKA每日一题_Day5](./005.assets/640-20191126201848352.png) + +#### 与podAffinity的差异 + +> – 匹配过程相同 +> +> – 最终处理调度结果时取反 +> 即 +> – podAffinity中可调度节点，在podAntiAffinity中为不可调度 +> – podAffinity中高分节点，在podAntiAffinity中为低分 + + + + + + +> CKA 考试每日一题系列，全部内容由 [我的小碗汤](https://mp.weixin.qq.com/s/5tYgb_eSzHz_TMsi0U32gw) 创作，本站仅做转载 + + +