k8s(四)在 Kubernetes上运行第一个应用

• 通常需要准备一个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 使用的镜像， 以及其他有用的信息