【k8s 系列】k8s 学习八,在 K8S 中部署一个应用 下

简介: 接着上一篇继续部署应用到 K8S中之前简单部署的简单集群,三个工作节点是运行在 docker 和 kubelet 的,还有一个是控制节点

「这是我参与11月更文挑战的第 23 天,活动详情查看:2021最后一次更文挑战

image.png

接着上一篇继续部署应用到 K8S中

之前简单部署的简单集群,三个工作节点是运行在 docker 和 kubelet 的,还有一个是控制节点

ReplicationController , pod 和 service 本次关系

之前有提到 ReplicationController , pod 和 服务是如何组合在一起的呢?

可以通过这张如图来解释一下

image.png

我们之前创建 pod 的时候不是直接创建的,是通过 docker run 来创建的一个 replicationController ,然后基于 rc 来创建的一个 pod 实例

为了让 pod 能够被外部访问到,所以我们需要让 K8S 将 replicationController 管理的所有 pod 由一个服务对外暴露,因此有了 kubia-http

  • 服务是有对外暴露 IP 的,请求打到 service 上
  • service 将请求转到 pod 上面的 9999 端口上,然后 pod 提供服务

ReplicationController 角色是啥样的

通过上面的案例,我们应该知道 ReplicationController实际上是用于复制 pod 的,通过 ReplicationController 来创建多个 pod 副本

ReplicationController 始终确保存在一个运行中的 pod 实例

image.png

如果我们上面创建的 pod 消失了,那么 ReplicationController 将会创建一个新的 pod 来替换消失的 pod

为什么需要 service

再来看看 service ,也就是上面 kubia-http 服务

为什么需要服务,有了 pod ,还拿 service 干啥?

通过上面的 ReplicationController 我们知道,pod 消失之后, ReplicationController 会再创建一个新的将其替换

那么我们也知道,每一个 pod 都有自己的独立的主机名和 IP

pod 在环境中会因为任何原因直接挂掉和消失,然后又被新的 pod 替换,这个时候 pod 的 IP 变化了,外部如何正确访问到我们的服务呢?

image.png

这个时候就需要 service 了

  • service 可以解决不断变化的 pod IP 问题
  • service 可以在一个固定 IP 和端口上对外暴露多个pod

当一个 service 被创建的时候,会得到一个静态的 IP,在 service 整个生命周期中,它的 IP 是不会变的

客户端只需要通过这个固定 IP 连接服务即可,服务会将请求转到 内部其中一个 pod, 客户端不需要关心 pod 在哪里,只需要关系 service 在哪里即可

增加副本数量

当前的系统里面只有的一个副本,现在我们可以增加到 3 个副本

我们可以通过指令 kubectl get replicationcontrollers 来查看当前的副本数

可以通过 kubectl scale rc mykubia --replicas=3,来将副本数调整至 3 个

  • 我们执行上面这个指令,只是告诉 K8S 系统中期望的副本数量,并没有告诉 K8S 需要如何去操作,如何去实现
  • K8S 自身会去检查当前的状态是否和期望的状态一致,如果不一致就会进行调整, 这个是 K8S 中基本的原则之一

我们用到的指令中,好多都是 kubectl get xxx 的,就是获取对应的 pod,service ,rc 等等信息的

其实我们也可以直接执行 kubectl get,这样可以列出所有可能类型的对象,还能够显示缩写

最新的系统状态

通过执行上述的指令,系统中将 1 个副本,调整成了 3 个副本

这就是 K8S 可以轻易的做到水平伸缩,我们要扩充副本的时候,再也不需要手动的去安装和运行其他副本了,只用执行指令,修改期望数量即可

当然,我们放进 pod 的服务,也需要做成无状态,可横向扩展的,这样才能更好的使用 K8S 的能力

这样子的话,最新的系统应该是这个样子的

image.png

外部请求打到 service 上面,service 会将请求给到 任意一个 pod ,对应的 pod 即提供服务即可

今天就到这里,学习所得,若有偏差,还请斧正


欢迎点赞,关注,收藏

朋友们,你的支持和鼓励,是我坚持分享,提高质量的动力

image.png

好了,本次就到这里

技术是开放的,我们的心态,更应是开放的。拥抱变化,向阳而生,努力向前行。

我是阿兵云原生,欢迎点赞关注收藏,下次见~

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
5天前
|
存储 Kubernetes 对象存储
部署DeepSeek但GPU不足,ACK One注册集群助力解决IDC GPU资源不足
借助阿里云ACK One注册集群,充分利用阿里云强大ACS GPU算力,实现DeepSeek推理模型高效部署。
|
1月前
|
缓存 Kubernetes Docker
GitLab Runner 全面解析:Kubernetes 环境下的应用
GitLab Runner 是 GitLab CI/CD 的核心组件,负责执行由 `.gitlab-ci.yml` 定义的任务。它支持多种执行方式(如 Shell、Docker、Kubernetes),可在不同环境中运行作业。本文详细介绍了 GitLab Runner 的基本概念、功能特点及使用方法,重点探讨了流水线缓存(以 Python 项目为例)和构建镜像的应用,特别是在 Kubernetes 环境中的配置与优化。通过合理配置缓存和镜像构建,能够显著提升 CI/CD 流水线的效率和可靠性,助力开发团队实现持续集成与交付的目标。
|
10天前
|
存储 Kubernetes 测试技术
企业级LLM推理部署新范式:基于ACK的DeepSeek蒸馏模型生产环境落地指南
本教程演示如何在ACK中使用vLLM框架快速部署DeepSeek R1模型推理服务。
|
11天前
|
存储 人工智能 弹性计算
NVIDIA NIM on ACK:优化生成式AI模型的部署与管理
本文结合NVIDIA NIM和阿里云容器服务,提出了基于ACK的完整服务化管理方案,用于优化生成式AI模型的部署和管理。
|
1天前
|
Kubernetes 持续交付 开发工具
阿里云协同万兴科技落地ACK One GitOps方案,全球多机房应用自动化发布,效率提升50%
阿里云协同万兴科技落地ACK One GitOps方案,全球多机房应用自动化发布,效率提升50%
|
5天前
|
人工智能 Kubernetes 异构计算
大道至简-基于ACK的Deepseek满血版分布式推理部署实战
本教程演示如何在ACK中多机分布式部署DeepSeek R1满血版。
|
29天前
|
存储 监控 对象存储
ACK 容器监控存储全面更新:让您的应用运行更稳定、更透明
针对本地存储和 PVC 这两种容器存储使用方式,我们对 ACK 的容器存储监控功能进行了全新升级。此次更新完善了对集群中不同存储类型的监控能力,不仅对之前已有的监控大盘进行了优化,还针对不同的云存储类型,上线了全新的监控大盘,确保用户能够更好地理解和管理容器业务应用的存储资源。
117 21
|
1月前
|
存储 监控 对象存储
ACK容器监控存储全面更新:让您的应用运行更稳定、更透明
介绍升级之后的ACK容器监控体系,包括各大盘界面展示和概要介绍。
|
Kubernetes 开发者 微服务
简化Kubernetes应用部署工具-Helm之Hook
本文讲的是简化Kubernetes应用部署工具-Helm之Hook【编者的话】微服务和容器化给复杂应用部署与管理带来了极大的挑战。Helm是目前Kubernetes服务编排领域的唯一开源子项目,做为Kubernetes应用的一个包管理工具,可理解为Kubernetes的apt-get / yum,由Deis 公司发起,该公司已经被微软收购。
2583 0
|
1月前
|
缓存 容灾 网络协议
ACK One多集群网关:实现高效容灾方案
ACK One多集群网关可以帮助您快速构建同城跨AZ多活容灾系统、混合云同城跨AZ多活容灾系统,以及异地容灾系统。

热门文章

最新文章