前后端分离架构+k8s+ingress

一、概述

在前面几篇文章中,已经讲到了前后端分离架构和ingress,链接如下:

https://www.cnblogs.com/xiao987334176/p/12195722.html

https://www.cnblogs.com/xiao987334176/p/12195797.html

接下来使用k8s进行发布应用

二、演示3.0

环境说明

k8s集群

系统 docker ip 主机名 配置
centos 7.6 19.03.5 192.168.31.150 k8s-master 2核4G
centos 7.6 19.03.5 192.168.31.178 k8s-node01 2核4G
centos 7.6 19.03.5 192.168.31.164 k8s-node02 2核4G

harbor

系统 docker docker-compose harbor ip 主机名 配置
centos 7.6 19.03.5 1.24.1 1.8.0 192.168.31.37 harbor 2核4G

关于k8s搭建,请参考链接:

https://www.cnblogs.com/xiao987334176/p/11899321.html

关于harbor搭建,请参考链接:

https://www.cnblogs.com/xiao987334176/p/11326467.html

推送镜像到harbor

在前面2.0的环境中,已经打包好了login和api镜像,直接推送到harbor仓库即可。

修改docker配置文件,增加harbor地址

vi /etc/docker/daemon.json

内容如下:

{
  "registry-mirrors": ["http://hub-mirror.c.163.com"],
  "insecure-registries": ["192.168.31.37"]
}

重启docker

systemctl restart docker

docker登录harbor,直接使用管理员账号登录

docker login 192.168.31.37 -u admin -p Harbor12345

打tag并推送

docker tag demo_api:v1 192.168.31.37/library/demo_api:v1
docker push 192.168.31.37/library/demo_api:v1

docker tag demo_login:v1 192.168.31.37/library/demo_login:v1
docker push 192.168.31.37/library/demo_login:v1

k8s集群登录harbor

登录到k8s集群中的master节点以及node节点。

修改docker配置文件,增加harbor地址

vi /etc/docker/daemon.json

内容如下:

{
  "registry-mirrors": ["http://hub-mirror.c.163.com"],
  "insecure-registries": ["192.168.31.37"]
}

重启docker

systemctl restart docker

k8s发布应用

yum install -y git
git clone https://github.com/py3study/django-login-example.git

前端

login.yaml是使用kuboard生成的,login-ingress.yaml是否手写的。因为kuboard生成的ingress有bug,外部无法访问。

cd django-login-example/3.0
kubectl apply -f login.yaml
kubectl apply -f login-ingress.yaml 

注意:请修改yaml文件中的仓库地址,改为实际环境中的harbor

api

cd django-login-example/3.0
kubectl apply -f api.yaml
kubectl apply -f api-ingress.yaml 

注意:请修改yaml文件中的仓库地址,改为实际环境中的harbor

查看pods

# kubectl get pods -o wide
NAME                          READY   STATUS    RESTARTS   AGE     IP              NODE         NOMINATED NODE   READINESS GATES
svc-api-6559bb7cb8-58fvj      1/1     Running   0          2m24s   10.244.58.197   k8s-node02   <none>           <none>
svc-login-66c8d579b5-94x6t    1/1     Running   0          2m30s   10.244.85.198   k8s-node01   <none>           <none>

确保处于`Running`状态,如果出现imagesoff,请确保node能下载镜像,镜像地址是否正确,是否登录了harbor

查看ingress

# kubectl get ingresses.extensions
NAME           HOSTS                ADDRESS   PORTS   AGE
svc-api        api.baidu.com                  80      4m37s
svc-login      h5.baidu.com                   80      4m43s

访问页面

在1.0和2.0中,都使用了nginx转发。在3.0就无需nginx转发了,直接使用ingress转发。

将域名解析到任意node节点的ip即可。如果没有dns,windows 10添加2条hosts记录

192.168.31.178 h5.baidu.com
192.168.31.178 api.baidu.com

访问登录页面

http://h5.baidu.com/

效果如下:

登录成功后,效果如下:

原文地址:https://www.cnblogs.com/xiao987334176/p/12196195.html

时间: 2024-10-29 03:22:16

前后端分离架构+k8s+ingress的相关文章

分布式之闲侃前后端分离架构的必要性

引言 由于近期前端抽不出资源,博主最近接手一个前端项目的代码维护工作.拿到手一看,一脸懵逼,和博主当年所学的jsp开发方式.利用ajax来请求数据的单页面开发方式完全不同.然而火坑已经跳下,只能硬着头皮啃,博主只能默默告诉自己 冲冲冲,四驱战士在行动 博主勉强算是经历了前端开发的几个时期吧.本文以一种循序渐进的方法,讲前后端分离架构的必要性.不过不得不说一点,目前前后端分离架构的文章一搜一大把,博主毕竟不是专业搞前端的,如果文章有什么理解不到位的地方,请及时指出,不胜感激. 正文 以博主的资历,

前后端分离架构概述

原文转自: https://blog.csdn.net/fuzhongmin05/article/details/81591072 1.背景       前后端分离已成为互联网项目开发的业界标准使用方式,通过nginx+tomcat的方式(也可以中间加一个nodejs)有效的进行解耦,并且前后端分离会为以后的大型分布式架构.弹性计算架构.微服务架构.多端化服务(多种客户端,例如:浏览器,车载终端,安卓,IOS等等)打下坚实的基础.这个步骤是系统架构从猿进化成人的必经之路. 核心思想是前端HTML

企业管理系统前后端分离架构设计 系列一 权限模型篇

前段时间分别用vue和react写了两个后台管理系统的模板vue-quasar-admin和3YAdmin.两个项目中都实现了基于RBAC的权限控制.因为本职工作是后端开发,比较清楚权限控制一个管理系统应该必须具备的核心功能,而且是可以做到通用的.打算写写关于管理系统前后端分离方面的文章,也是做一个知识的总结,其中会涉及到vue,react,node,.net core等方面的知识. 术语描述 用户(Subject):发起操作的主体 对象(Object):指操作所针对的客体对象,比如文章或评论

[转]从MVC到前后端分离

从MVC到前后端分离 来源:csdn 发布时间:2015-10-26 阅读次数:1680 1. 理解MVC MVC是一种经典的设计模式,全名为Model-View-Controller,即模型-视图-控制器. 其中,模型是用于封装数据的载体,例如,在Java中一般通过一个简单的POJO(Plain Ordinary Java Object)来表示,其本质是一个普通的Java Bean,包含一系列的成员变量及其getter/setter方法.对于视图而言,它更加偏重于展现,也就是说,视图决定了界面

从 MVC 到前后端分离——转自:OSChina 黄勇

转自:OSChina 黄勇 从 MVC 到前后端分离 1 理解 MVC MVC 是一种经典的设计模式,全名为 Model-View-Controller,即 模型-视图-控制器. 其中,模型 是用于封装数据的载体,例如,在 Java 中一般通过一个简单的 POJO(Plain Ordinary Java Object)来表示,其本质是一个普通的 Java Bean,包含一系列的成员变量及其 getter/setter 方法.对于 视图 而言,它更加偏重于展现,也就是说,视图决定了界面到底长什么样

从MVC到前后端分离

摘要:MVC模式早在上个世纪70年代就诞生了,直到今天它依然存在,可见生命力相当之强.MVC模式最早用于Smalltalk语言中,最后在其它许多开发语言中都得到了很好的应用,例如,Java中的Struts.Spring MVC等框架. 1. 理解MVC MVC是一种经典的设计模式,全名为Model-View-Controller,即模型-视图-控制器. 其中,模型是用于封装数据的载体,例如,在Java中一般通过一个简单的POJO(Plain Ordinary Java Object)来表示,其本

从 MVC 到前后端分离

从 MVC 到前后端分离 1 理解 MVC MVC 是一种经典的设计模式,全名为 Model-View-Controller,即 模型-视图-控制器. 其中,模型 是用于封装数据的载体,例如,在 Java 中一般通过一个简单的 POJO(Plain Ordinary Java Object)来表示,其本质是一个普通的 Java Bean,包含一系列的成员变量及其 getter/setter 方法.对于 视图 而言,它更加偏重于展现,也就是说,视图决定了界面到底长什么样子,在 Java 中可通过

前后端分离实践(一)

前言 最近这一段时间由于Nodejs的逐渐成熟和日趋稳定,越来越多的公司中的前端团队开始尝试使用Nodejs来练一下手,尝一尝鲜. 一般的做法都是将原本属于后端的一部分相对于业务不是很重要的功能迁移到Nodejs上面来,也有一些公司将NodeJS作为前后端分离的一个解决方案去施行.而像淘宝网这类的大型网站也很早的完成了前后端的分离,给我们这样的后来者提供了宝贵的经验. 同样,我们的大网盘团队也早在去年早早就开始了紧锣密布的准备工作,这目前工作也做的差不多了,现在我就来总结一下在过程中遇到的坑点以

REST风格框架实战:从MVC到前后端分离(附完整Demo)

既然MVC模式这么好,难道它就没有不足的地方吗?我认为MVC至少有以下三点不足:每次请求必须经过“控制器->模型->视图”这个流程,用户才能看到最终的展现的界面,这个过程似乎有些复杂:实际上视图是依赖于模型的,换句话说,如果没有模型,视图也无法呈现出最终的效果:渲染视图的过程是在服务端来完成的,最终呈现给浏览器的是带有模型的视图页面,性能无法得到很好的优化. 为了使数据展现过程更加直接,并且提供更好的用户体验,我们有必要对MVC模式进行改进.不妨这样来尝试:首先从浏览器发送AJAX请求,然后服