错别字修订
This commit is contained in:
@ -12,17 +12,17 @@ meta:
|
||||
# Kubernetes 教程
|
||||
|
||||
<div class="row">
|
||||
<div class="col-md-4">
|
||||
<div class="col-md-4 col-sm-6">
|
||||
<a href="#kubernetes免费教程">
|
||||
<FancyImage src="/images/courses/free.png" title="免费教程" description="权威资料" alt="K8S培训_免费教程" type="Rolling"/>
|
||||
</a>
|
||||
</div>
|
||||
<div class="col-md-4">
|
||||
<div class="col-md-4 col-sm-6">
|
||||
<a href="https://kubetrain.cn/?from=learning" target="_blank">
|
||||
<FancyImage src="/images/courses/intermediate.png" title="K8S高薪培训" description="360讲师授课" alt="K8S培训_高薪培训" type="Cross"/>
|
||||
</a>
|
||||
</div>
|
||||
<div class="col-md-4">
|
||||
<div class="col-md-4 col-sm-6">
|
||||
<a href="https://kubetrain.cn/advanced.html?from=learning" target="_blank">
|
||||
<FancyImage src="/images/courses/advanced.png" title="K8S高级班" description="360讲师授课" alt="K8S培训_高薪培训" type="Rectangle"/>
|
||||
</a>
|
||||
|
||||
@ -34,7 +34,7 @@ meta:
|
||||
|
||||
在 k8s 上进行部署前,首先需要了解一个基本概念 **Deployment**
|
||||
|
||||
**Deployment** 译名为 **部署**。在k8s中,通过发布 Deployment,可以创建应用程序 (docker image) 的实例 (docker container),这个实例会被包含在称为 **Pod** 的概念中,**Pod** 是 k8s 中最小单元的可管理单元。
|
||||
**Deployment** 译名为 **部署**。在k8s中,通过发布 Deployment,可以创建应用程序 (docker image) 的实例 (docker container),这个实例会被包含在称为 **Pod** 的概念中,**Pod** 是 k8s 中最小可管理单元。
|
||||
|
||||
在 k8s 集群中发布 Deployment 后,Deployment 将指示 k8s 如何创建和更新应用程序的实例,master 节点将应用程序实例调度到集群中的具体的节点上。
|
||||
|
||||
|
||||
@ -91,7 +91,7 @@ Replication Controller确保任意时间都有指定数量的Pod“副本”在
|
||||
|
||||
*如果Pods是短暂的,那么重启时IP地址可能会改变,怎么才能从前端容器正确可靠地指向后台容器呢?*
|
||||
[Service](https://kubernetes.io/docs/concepts/services-networking/service/) **抽象**
|
||||
现在,假定有2个后台Pod,并且定义后台Service的名称为‘backend-service’,lable选择器为()。 的Service会完成如下两件重要的事情:
|
||||
现在,假定有2个后台Pod,并且定义后台Service的名称为‘backend-service’,label选择器为(tier=backend, app=myapp) 的Service会完成如下两件重要的事情:
|
||||
|
||||
- 会为Service创建一个本地集群的DNS入口,因此前端Pod只需要DNS查找主机名为 ‘backend-service’,就能够解析出前端应用程序可用的IP地址。
|
||||
- 现在前端已经得到了后台服务的IP地址,但是它应该访问2个后台Pod的哪一个呢?Service在这2个后台Pod之间提供透明的负载均衡,会将请求分发给其中的任意一个(如下面的动画所示)。通过每个Node上运行的代理(kube-proxy)完成。
|
||||
|
||||
@ -48,7 +48,7 @@ meta:
|
||||
|
||||
**Master 负责管理集群** 负责协调集群中的所有活动,例如调度应用程序,维护应用程序的状态,扩展和更新应用程序。
|
||||
|
||||
**Worker节点(即图中的Node)是VM(虚拟机)或物理计算机,充当k8s集群中的工作计算机。** 每个Worker节点都有一个Kubelet,它管理一个Worker节点并与负责与Master节点通信。该Worker节点还应具有用于处理容器操作的工具,例如Docker。
|
||||
**Worker节点(即图中的Node)是VM(虚拟机)或物理计算机,充当k8s集群中的工作计算机。** 每个Worker节点都有一个Kubelet,它管理该Worker节点并负责与Master节点通信。该Worker节点还应具有用于处理容器操作的工具,例如Docker。
|
||||
|
||||
|
||||
|
||||
|
||||
@ -16,7 +16,7 @@ meta:
|
||||
|
||||
* 在恒温器上设定好目标温度,就是在告诉该 **控制循环** 你想要的 ***目标状态***。
|
||||
* 房间里的实际温度,是 ***当前状态***
|
||||
* 恒温器通过打卡或关闭加热装置,不断地使 ***当前状态*** 接近于 ***目标状态***
|
||||
* 恒温器通过打开或关闭加热装置,不断地使 ***当前状态*** 接近于 ***目标状态***
|
||||
|
||||
在 Kubernetes 中,**控制器** 就是上面所说的 **控制循环**,它不断监控着集群的状态,并对集群做出对应的变更调整。每一个控制器都不断地尝试着将 ***当前状态*** 调整到 ***目标状态***。
|
||||
|
||||
|
||||
@ -134,7 +134,7 @@ Events: <none>
|
||||
| Node Condition | 描述 |
|
||||
| ----------------- | ------------------------------------------------------------ |
|
||||
| OutOfDisk | 如果节点上的空白磁盘空间不够,不能够再添加新的节点时,该字段为 `True`,其他情况为 `False` |
|
||||
| Ready | 如果节点时健康的且已经就绪可以接受新的 Pod。则节点Ready字段为 `True`。`False`表明了该节点不健康,不能够接受新的 Pod。 |
|
||||
| Ready | 如果节点是健康的且已经就绪可以接受新的 Pod。则节点Ready字段为 `True`。`False`表明了该节点不健康,不能够接受新的 Pod。 |
|
||||
| MemoryPressure | 如果节点内存紧张,则该字段为 `True`,否则为`False` |
|
||||
| PIDPressure | 如果节点上进程过多,则该字段为 `True`,否则为 `False` |
|
||||
| DiskPressure | 如果节点磁盘空间紧张,则该字段为 `True`,否则为 `False` |
|
||||
|
||||
@ -94,7 +94,7 @@ kube-proxy 在节点上维护网络规则。这些网络规则使得您可以在
|
||||
|
||||
### 容器引擎
|
||||
|
||||
容器引擎负责运行容器。Kubernetes支持多宗容器引擎:[Docker](http://www.docker.com/)、[containerd](https://containerd.io/)、[cri-o](https://cri-o.io/)、[rktlet](https://github.com/kubernetes-incubator/rktlet) 以及任何实现了 [Kubernetes容器引擎接口](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md) 的容器引擎
|
||||
容器引擎负责运行容器。Kubernetes支持多种容器引擎:[Docker](http://www.docker.com/)、[containerd](https://containerd.io/)、[cri-o](https://cri-o.io/)、[rktlet](https://github.com/kubernetes-incubator/rktlet) 以及任何实现了 [Kubernetes容器引擎接口](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md) 的容器引擎
|
||||
|
||||
## Addons
|
||||
|
||||
|
||||
@ -43,7 +43,7 @@ Kubernetes中为容器提供了两个 hook(钩子函数):
|
||||
容器只要实现并注册 hook handler 便可以使用钩子函数。Kubernetes 中,容器可以实现两种类型的 hook handler:
|
||||
|
||||
* Exec - 在容器的名称空进和 cgroups 中执行一个指定的命令,例如 `pre-stop.sh`。该命令所消耗的 CPU、内存等资源,将计入容器可以使用的资源限制。
|
||||
* HTTP - 想容器的指定端口发送一个 HTTP 请求
|
||||
* HTTP - 向容器的指定端口发送一个 HTTP 请求
|
||||
|
||||
|
||||
### Hook handler的执行
|
||||
|
||||
@ -21,9 +21,9 @@ meta:
|
||||
|
||||
## 设计目标
|
||||
|
||||
可以通过 RuntimeClass,使不同的 Pod 使用不同的容器引擎,以在性能和安全之间取得平衡。例如,如果某些工作负载需要非常高的信息安全保证,您可能将其 Pod 运行在那种使用硬件虚拟化的容器引擎上;同时,将其他的 Pod 运行在另外一种容器引擎上,以获得更高的性能。
|
||||
可以通过 RuntimeClass,使不同的 Pod 使用不同的容器引擎,以在性能和安全之间取得平衡。例如,如果某些工作负载需要非常高的信息安全保证,您可能想要将其 Pod 运行在那种使用硬件虚拟化的容器引擎上;同时,将其他的 Pod 运行在另外一种容器引擎上,以获得更高的性能。
|
||||
|
||||
也可以通过 RuntimeClass 配置,使不同的 Pod 使用相同的容器引擎,但是不同的容器引擎设定。
|
||||
也可以通过 RuntimeClass 配置,使不同的 Pod 使用相同的容器引擎和不同的容器引擎配置参数。
|
||||
|
||||
### 配置步骤
|
||||
|
||||
|
||||
@ -46,7 +46,7 @@ Kubernetes 通过引入 Service 的概念,将前端与后端解耦。
|
||||
|
||||
图中,Service 先连线到 Controller,Controller 在连线到容器组,这种表示方式只是概念上的,期望用户在使用 Kubernetes 的时候总是通过 Controller 创建 Pod,然后再通过 Service 暴露为网络服务,通过 Ingress 对集群外提供互联网访问。
|
||||
|
||||
事实上,Service 与 Controller 并没有直接联系,Service 通过 label selector 选择符合条件的 Pod,并将选中的 Pod 作为网络服务的提供者。从这个意义上来讲,您可以有很多中方式去定义 Service 的 label selector,然而,最佳的实践是,在 Service 中使用与 Controller 中相同的 label selector。如上图所示。
|
||||
事实上,Service 与 Controller 并没有直接联系,Service 通过 label selector 选择符合条件的 Pod,并将选中的 Pod 作为网络服务的提供者。从这个意义上来讲,您可以有很多种方式去定义 Service 的 label selector,然而,最佳的实践是,在 Service 中使用与 Controller 中相同的 label selector。如上图所示。
|
||||
|
||||
::: tip
|
||||
使用 Kubernetes 的最佳实践:
|
||||
|
||||
Reference in New Issue
Block a user