-
通常需要准备一个JSON或YAML,包含想要部署的所有组件描述的配置文件
-
但是因为还没有介绍可以在Kubemetes中创建的组件类型,所以这里将使用一个简单的单行命令来运行应用。
3.1部署flask应用
- 部署应用程序最简单的方式是使用 kubectl run命令.该命令可以创建所有必要的组件而无需JSON或YAML文件
$ kubectl run kubia --image=amazingquyj/kubia --port=5050 pod/kubia created
| 命令 | 意义 |
|---|---|
| --image=amazingquyj/kubia | 指定运行的容器镜像 |
| --port=5050 | 告诉k8s应用正在监听的端口 |
-
pod
-
Kubernetes 的工作不直接处理单个容器.它使用多个共存容器的理念,这组容器就叫作 pod。
-
一个 pod是一组紧密相关的容器,它们总是一起运行在同一个工作节点上,以及同一个 Linux 命名空间中。
-
一个pod 就像一个独立的逻辑机器,拥有自己的 IP、 主机名、进程等,运行 一个独立的应用程序
-
应用程序可以是单个进程,运行在单个容器中也可以是一个主应用进程或者其他支持进程,每个进程都在自己的容器中运行
-
一个pod 的所有容器都运行在同一个逻辑机器上,而其他 pod 中的容器,即使运行在同一个工作节点上,也会出现在不同的节点上
-
每个pod都有自己的IP并包含一个或多个容器,每个容器都运行一个应用进程,pod 分布在不同的工作节点上 。
image-20230220161814463.png
-
-
不能列出单个容器,因为它们不是独立的 K8s对象,但是可以列出 pod
$ kubectl get pods
image-20230220164008923.png
要查看有关 pod 的更多信息,还可以使用 kubectl describe pod 命令，就 像之前查看工作节点 一样 -
底层原理
-
在 Kubemetes中运行容器镜像所必需的步骤
-
1-构建镜像并将其推送到 Docker Hub需要使它可以访问运行在 工作节点上 的 Docker 守护进程 。
-
当运行 kubectl 命令时,它通过向 K8s API服务器发送一个 REST HTTP 请求,在集群中创建一个新的 ReplicationController对象 。
-
然后,ReplicationController创建了一个新的 pod，调度器将其调度到一个工作节点上 。
-
K看到 pod 被调度到节点上,就告知 Docker从镜像中心拉取指定的镜像因为本地没有该镜像.下载镜像后,Docker创建并运行容器
-
术语调度(scheduling)的意思是将pod分配给一个节点。 pod会立即运行而不是将要运行 。
image-20230220164743599.png
-
3.2访问web应用
-
每个pod都有自己的IP地址,但是这个地址是集群内部的不能从集群外部访问 。
-
要让 pod 能够从外部访问,需要通过服务对象公开它,要创建一个特殊的LoadBalancer类型的服务
-
如果创建一个常规服务(一个ClusterIP服务),比如pod它也只能从集群内部访问。
-
通过创建LoadBalancer类型的服务,将创建一个外部的负载均衡,可以通过负载均衡的公共 IP访问pod。
$ kubectl expose pod kubia --type=LoadBalancer --name kubia-http -
大多数资源类型都有缩写,例如(pods 的缩写是 po, service 的缩写是 SVC等等 ).
-
创建伊始external-ip为pending,因为K8s运行的云基础设施创建负载均衡需要一段时间.负载均衡启动后应该会显示服务的外部IP地址
$ kubectl get services
image-20230220172146985.png
现在有外部 IP 了，应用就可以从任何地方通过 34.139.165.42:5050访问
注意:
Minikube 不 支持 LoadBalancer 类型的服务,因此服务不会有外部 IP.但是可以通过外部端口访问服务.
可以运行 minikube service kubia- http获取可以访问服务的 IP 和端口 。
3.3系统逻辑
ReplicationController、 pod 和服务是如何组合在一起的
image-20230220173556496.png
-
在系统中最重要的组件是 pod.只包含一个容器,但是通常一个pod可以包含任意数量的容器,pod有自己独立的私有IP地址和主机名。
-
ReplicationController用于复制pod (即创建pod的多个副本) 并让它 们保持运行。
-
示例中没有指定需要多少 pod副本，所以 ReplicationController创建了 一个副本 。
-
如果你的 pod 因为任何原因消失了，那么ReplicationController将创建一 个新的pod来替换消失的pod。
-
为什么需要服务
-
pod 的存在是短暂的一 个 pod 可能会在任何时候消失。发生故障、人为操作失误等
-
其中任何一种情况 发生时消失的 pod 将被ReplicationControIler替换为新的pod,它拥有新的IP
-
这就是需要服务的地方 解决不断变化的 pod IP地址的问题，以及在一个固定的 IP和端口对上对外暴露多个 pod。
-
当一个服务被创建时,它会得到一个静态的 IP在服务的生命周期中这个IP不会发生改变。客户端应该通过固定 IP地址连接到服务
-
而不是直接连接 pod服务会确保其中一个pod接收连接，而不关心pod当前运行在哪里(以及它的 IP 地址 是什么) 。
-
服务表示一组或多组提供相同服务的 pod 的静态地址.到达服务 IP和端口的请求将被转发到属于该服务的一个容器的 IP 和端口 。
-
3.4水平伸缩应用
现在拥有一个正在运行的应用，由 ReplicationController监控并保持运行，并通过服务暴露访问。 现在来创造更多副本。
使用 Kubemetes 的一个主要好处是可以简单地扩展部署 。
- 增加期望副本数
$ kubectl scale kubia --replicas=3 -
由于 pod 的实际数 量 己经增 加到 三 个(从 CURRENT 列中可以看出)，列出所有 的 pod 时显示的应该是三个而不是一个:
image-20230220175809283.png
- 当切换到服务时请求切换到所有三个 pod 上
因为现在应用的多个实例在运行，让我们看看如果再次请求服务的 URL 会发 生什么 。 会不会总是切换到应用的同一个实例呢?
image-20230220175836432.png
-
请求随机地切换到不同的 pod当pod有多个实例时 k8s服务就会这样做,服务作为负载均衡挡在多个 pod 前面
-
当只有一个 pod 时服务为单个 pod 提供一个静态地址,无论服务后面是单个pod还是一组pod,
-
这些 pod 在集群内创建、消失,这意味着它们的 IP 地址会发生变化,但服务的地址总是相同的。
-
这使得无论有多少 pod,以及它们的地址如何变化,客户端都可以很容易地连接到 pod。
-
目前架构仍然有一个服务和一个 ReplicationContraIler,但是现在有三个 pod 实例它们都是由 ReplicationController 管理的。
-
服务不再将所有请求发送到单个pod,而是将它们分散到所有三个pod中如前面使用 curl 进行的实验所示。
image-20230220180143898.png
3.5查看应用运行在哪个节点上
-
在k8s的世界中pod运行在 哪个节点上并不重要,只要它被调度到一个可以提供 pod正常运行所需的CPU和内存的节点就可以了 。
-
不管调度到哪个节点,容器中运行的所有应用都具有相同类型的操作系统。每个pod 都有自己的 IP并且可以与任何其他 pod 通信
-
不论其他pod是运行在同一个节点上,还是运行在另一个节点上,每个pod都被分配到所需的计算资源
$ kubectl get pods -o wide -
因此这些资源是由一个节点提供还是由另一个节点提供，并没有任何区别。
image-20230220180746999.png
$ kubectl describe pod kubia-hczji
image-20230220180850822.png
这展示 pod 的一些其他信息， pod 调度到的节点、启动的时间、 pod 使用的镜像， 以及其他有用的信息
网友评论