云原生项目上云最佳实践

Posted 跳楼梯企鹅

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了云原生项目上云最佳实践相关的知识，希望对你有一定的参考价值。

博主昵称：跳楼梯企鹅
博主主页面链接：博主主页传送门

博主专栏页面连接：专栏传送门--网路安全技术
创作初心：本博客的初心为与技术朋友们相互交流，每个人的技术都存在短板，博主也是一样，虚心求教，希望各位技术友给予指导。
博主座右铭：发现光，追随光，成为光，散发光;
博主研究方向：渗透测试、机器学习 ;
博主寄语：感谢各位技术友的支持，您的支持就是我前进的动力 ;

 

 一、浅谈云计算

1.概念

云计算（cloud computing）是分布式计算的一种，指的是通过网络“云”将巨大的数据计算处理程序分解成无数个小程序，然后，通过多部服务器组成的系统进行处理和分析这些小程序得到结果并返回给用户。云计算早期，简单地说，就是简单的分布式计算，解决任务分发，并进行计算结果的合并。因而，云计算又称为网格计算。通过这项技术，可以在很短的时间内（几秒钟）完成对数以万计的数据的处理，从而达到强大的网络服务。

2.为什么要用云计算

（1）云计算提高了速度和敏捷性

如果今天的商业环境有一个基本的事实，那就是它正在以不断加快的速度发展。

每个企业都面临着压力，必须对不断变化的商业环境作出更快的反应。不幸的是，传统的IT流程与今天的速度并不匹配。配置资源通常需要数周或数月时间，因此减慢了业务的反应速度。有了云计算，资源可以在几分钟内获得，这意味着企业可以更快地对新市场的发展做出反应。

（2）实现可持续创新

然而，在今天的商业环境中，成功需要的不仅仅是速度。同样重要的是创新——即开发新产品、评估其潜在市场认可度，然后推出成功产品、淘汰失败产品的能力。

在这方面，云计算也比传统的IT基础设施方法更适合。因为资源的可用性非常快，所以很容易很快地体验新产品。公司可以立即获得用户反馈，而不是等上几个月才让产品进入市场试验。

（3）有助于管理成本

传统IT基础设施的另一个现实是，它的价格非常昂贵。显然，基础设施需要物理资源：服务器、存储和网络。但除此之外，运营这些资源还需要大量的开支：人员、设施和电力。

而且大多数IT组织在基础设施方面效率不高。采购很少，而且数量很少，因此资源成本很高。操作过程通常不是自动化的，所以人工成本也很高。

相比之下，大型云服务提供商则是批量购买。而且因为他们的经营规模非常之大，所以必须投资于过程自动化。并且，他们不可能雇佣或负担得起足够的员工来手动管理他们庞大的服务器群。

（4）支持应用程序弹性

应用程序正常运行时间一直很重要。但如今，可用性比以往任何时候都重要。这是因为越来越多的公司正在成为数字化企业，他们的客户和供应商通过基于IT的机制进行互动和参与。

向数字化的转变使应用程序的弹性变得至关重要。简单地说，应用程序需要保持可用性，即使面临基础设施故障。

大多数内置应用程序表现出较差的弹性。由于设备非常昂贵，大多数应用程序负担不起冗余，因此它们包含SPOFs(单点故障)。当基础设施出现故障时，应用程序会停止运行，直到进行修复为止。

云计算极大地改变了弹性方程。首先，很容易获得额外的基础设施资源。因此，如果出现故障，在新的资源上重启应用程序是很简单的。

但应用程序的弹性不仅仅是快速获得替换包。因为资源是随时可用的，而且组织只为他们使用的东西付费，所以避免SPOF应用程序设计和使用冗余资源是划算的。如果出现故障，应用程序将继续对仍在工作的资源进行操作，从而允许操作将问题作为后台任务处理。

参考资料链接

3.云计算服务

云部署模型

云环境主要分为三种类型，也称为云部署模型。企业可以选择在公共云、私有云或混合云上运行应用程序，具体取决于他们的要求。

公共云

公共云环境由外包云提供商所有，许多企业可以通过互联网以按使用付费的模式访问。这种部署模型为希望节省 IT 运营成本的企业提供服务和基础设施，但负责创建和维护资源的是云提供商。

私有云

这种云部署模型是由单个企业拥有的定制基础架构。它提供了一个更加可控的环境，在该环境中，对 IT 资源的访问更加集中在企业内部。该模型可以在外部托管，也可以在内部进行管理。尽管私有云托管可能很昂贵，但对于大型企业来说，它可以提供更高级别的安全性和更多自主权来定制存储、网络和计算组件以满足其 IT 需求。

混合云

对于寻求私有云和公共云部署模型的好处的企业来说，混合云环境是一个不错的选择。通过结合这两种模型，混合云模型提供了更量身定制的 IT 解决方案，可以满足特定的业务需求。

 

 

二、云计算基础服务

 云计算的三种主要服务模式——基础设施即服务（IaaS）、平台即服务（PaaS）和软件即服务（SaaS）。

（1）基础设施即服务（IaaS）

这是最常见的云计算服务模型，因为它提供了虚拟服务器、网络、操作系统和数据存储驱动器的基础架构。它实现了许多企业通过云寻求的灵活性、可靠性和可扩展性，并消除了办公室对硬件的需求。这使其成为寻求经济高效的 IT 解决方案以支持业务增长的中小型组织的理想选择。IaaS 是一项完全外包的按使用付费服务，可作为公共、私有或混合基础设施使用。

（2）平台即服务（PaaS）

这是云计算提供商部署基础设施和软件框架的地方，但企业可以开发和运行自己的应用程序。可以通过 PaaS 快速轻松地创建 Web 应用程序，并且该服务足够灵活和强大以支持它们。PaaS 解决方案具有可扩展性，非常适合多个开发人员在单个项目上工作的业务环境。对于需要利用现有数据源（例如 CRM 工具）的情况，它也很方便。

（3）软件即服务（SaaS）

这种云计算解决方案涉及通过互联网向通过订阅或按使用付费模式付费的各种企业部署软件。对于 CRM 和需要大量 Web 或移动访问的应用程序（例如移动销售管理软件）来说，它是一个有价值的工具。SaaS 从一个中心位置进行管理，因此企业不必担心自己维护它，是短期项目的理想选择。

三、云计算分层架构应用

 

1、应用层

应用层是以友好的用户界面为用户提供所需的各项应用软件和服务，应用层直接面向客户需求，向企业客户提供CRM、ERP、OA等企业应用。

2、中间层

中间层是承上启下的一层，它在基础设施层所提供资源的基础上为用户提供服务，包括了访问控制、资源管理、数据库和中间件等集群，同时可通过集成API为客户提供定制开发接口。

3、基础设施层

基础设施层是为中间层或者用户提供其所需的计算和存储等资源，并通过虚拟化等技术奖资源池化，以实现资源的按需分配和快速部署。

 

四、云原生架构----Docker

1.Docker框架

Docker是客户端-服务器架构的应用，主要由以下部分组成：

  • 服务端是一个名为dockerd守护进程，用来监听REST API请求并管理Docker对象，比如镜像、容器、存储卷及网络等。
  • 命令行客户端（CLI），也就是我们平常在控制台输入的docker命令行，通过调用REST API进行控制Docker daemon或者同其进行集成。
  • 镜像仓库（Docker Registries），镜像仓库用来存储Docker镜像。

 2.Docker对象

  • IMAGES 

镜像一般是通过指令创建的只读文件，用来生成容器。一般一个镜像是基于另外一个镜像并添加一些额外的指令创建的，可以通过一个名为Dockerfile的文件来生成一个镜像，在Dockerfile中的每一行指令会生成一层（layer）。当Dockerfile有改动需要重新生成镜像时，只需要重新生成改变的那些层就可以，这样就可以使得镜像文件更加轻量、快速构建。

  • CONTAINERS

容器是通过镜像文件生成的运行实例。可以通过REST API或者docker client进行创建、启动、停止、移动或者删除一个容器。

  • SERVICE

用来管理和扩展多个容器，需要同docker swarm一起工作

 3.Docker的安装部署

（1）配置初始化

# cat /etc/sysconfig/network-scripts/ifcfg-ens33
TYPE=Ethernet
BOOTPROTO=static
NAME=ens33
DEVICE=ens33
ONBOOT=yes
IPADDR=192.168.xxx.xxx
NETMASK=255.255.255.0
GATEWAY=192.168.xxx.xxx

（2）配置DNS

[root@localhost yum.repos.d]# vim /etc/resolv.confnameserver 192.168.xxx.xxx

（3）配置主机

# hostnamectl --static set-hostname docker-90

（4）挂载

[root@localhost ~]# mkdir /iso
[root@localhost ~]# mount /dev/sr0 /iso
[root@localhost ~]# chmod +x /etc/rc.d/rc.local
[root@localhost ~]# vi /etc/rc.d/rc.local
##挂载
mount /dev/sr0 /iso

（5）镜像源配置

[root@localhost ~]# cd /etc/yum.repos.d/
[root@localhost yum.repos.d]# rm -rf *.repo
[root@localhost yum.repos.d]# vi base.repo
vi内部内容如下：
[root@localhost yum.repos.d]# cat base.repo
[base]
name=base
baseurl=file:///iso
enabled=1
gpgcheck=0

继续输入命令
[root@localhost yum.repos.d]# yum clean all
[root@localhost yum.repos.d]# yum makecache

（6）设置环境

[root@localhost yum.repos.d]# iptables -F
[root@localhost yum.repos.d]# iptables -t nat -F
[root@localhost yum.repos.d]# systemctl stop firewalld
[root@localhost yum.repos.d]# systemctl disable firewalld
[root@localhost yum.repos.d]# systemctl stop NetworkManager
[root@localhost yum.repos.d]# systemctl disable NetworkManager
[root@localhost yum.repos.d]# systemctl stop postfix
[root@localhost yum.repos.d]# systemctl disable postfix

（7）修改内核

[root@localhost yum.repos.d]# vim /boot/grub2/grub.cfg
将 第 100 行的
rhgb quiet 去掉，改为 vga=817


修改目录路径
[root@localhost yum.repos.d]# vim /etc/bashrc
#第41行，修改
...... && PS1="[\\u@\\h \\w]\\\\$ ，将 \\W 改为 \\w

（8）导入key

[root@docker ~]#rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org

（9）安装yum源

[root@docker ~]#rpm -Uvh http://www.elrepo.org/elrepo-release-7.0-3.el7.elrepo.noarch.rpm
[root@docker ~]#yum clean all
[root@docker ~]#yum makecache fast

（10）部署docker-ce

清理环境
[root@Docker1 ~]#systemctl stop docker
[root@Docker1 ~]#yum remove docker-ce docker-ce-cli docker-selinux

配置网络
root@Docker1 ~]#cd /etc/yum.repos.d/
[root@Docker1 /etc/yum.repos.d]#mv elrepo.repo elrepo.repo.bak
[root@Docker1 /etc/yum.repos.d]#vim aliyun.repo
###输入以下内容
[base]
name=base
baseurl=https://mirrors.aliyun.com/centos/7/os/x86_64/
enabled=1
gpgcheck=0

[extras]
name=extras
baseurl=https://mirrors.aliyun.com/centos/7/extras/x86_64/
enabled=1
gpgcheck=0

[aliyun-os]
name=aliyun-os
baseurl=https://mirrors.aliyun.com/centos/7/os/x86_64/
enabled=1
gpgcheck=0

[aliyun-epel]
name=aliyun-epel
baseurl=https://mirrors.aliyun.com/epel/7/x86_64/
enabled=1
gpgcheck=0

[aliyun-extra]
name=aliyun-extra
baseurl=https://mirrors.aliyun.com/centos/7/extras/x86_64/
enabled=1
gpgcheck=0

安装最新版本docker-ce
[root@Docker1 /etc/yum.repos.d]# yum install docker-ce docker-ce-cli containerd.io

（11）测试docker 工具

[root@Docker1 /etc/yum.repos.d]# docker -v
Docker version 20.10.6, build 370c289

查看docker详情

#docker info

 （12）配置加速器

https://cr.console.aliyun.com/cn-guangzhou/instances/mirrors


[root@Docker1 /etc/docker]# vim /etc/docker/daemon.json

## 输入以下内容

"registry-mirrors": ["https://xxxxxxxx.mirror.aliyuncs.com"] ##这里修改为自己的阿里云加速器地址

[root@Docker1 /etc/docker]# systemctl daemon-reload
[root@Docker1 /etc/docker]# systemctl restart docker

 （13）启动

[root@Docker1 /etc/yum.repos.d]# systemctl start docker

docker开机自启动：# systemctl enable docker

[root@Docker1 /etc/yum.repos.d]# systemctl status docker

五、云原生架构----Kubernetes

 1.Kubernetes系统架构解析

  • K8S是谷歌开源的容器集群管理系统；他构建在容器之上，为容器化的应用提供资源调度，部署运行，服务发现，扩容缩容等一整套功能。
  • 将容器宿主机组成集群，统一进行资源调度，自动管理容器生命周期，提供跨节点服务发现和负载均衡；更好的支持服务概念、划分、细分服务之间的边界，比如label，pod等概念的引入
  • 轻量，迁移方便，部署快捷，插件化，可扩展

2.controller控制器原理解析

Controller Manager主要提供了一个分发事件的能力，而不同的Controller只需要注册对应的Handler来等待接受和处理事件。
在Controller Manager的帮助下， Controller的逻辑可以做的非常纯粹，只需要实现相应的EventHandler即可，以Deployment controller为例。

  • List是短连接实现，用于获取该资源的所有Object
  • Watch是长连接实现，用于监听在List中获取的资源的变换
  • api-server检测到资源产生变更时，会主动通知到Controller manager(利用分块传输编码

3.list-watch机制解析

Kubernetes 是通过 List-Watch 的机制进行每个组件的协作，保持数据同步的，每个组件之间的设计实现了解耦。
用户是通过 kubectl 根据配置文件，向 APIServer 发送命令，在 Node 节点上面建立 Pod 和 Container。
APIServer 经过 API 调用，权限控制，调用资源和存储资源的过程，实际上还没有真正开始部署应用。这里需要 Controller Manager、Scheduler 和 kubelet 的协助才能完成整个部署过程。
在 Kubernetes 中，所有部署的信息都会写到 etcd 中保存。实际上 etcd 在存储部署信息的时候，会发送 Create 事件给 APIServer，而 APIServer 会通过监听（Watch）etcd 发过来的事件。其他组件也会监听（Watch）APIServer 发出来的事件。

六、无服务应用架构设计

1.优点

无服务器架构的优点之一是企业机构不用管理运行应用的后端基础设施。例如开发人员不必担心容量规划问题，因为有人会为他们解决。云服务提供商提供自动化的无服务器架构，这种架构可以在必要时提供更多的资源或缩小规模，这就又为开发人员减少了一项待办任务。开发人员不必负责维护后端基础设施，包括配置和扩展等，可以将更多的时间用于其他更有意义的项目。

这种弹性为企业机构解决了容量规划等掌管服务器时所需要担心的问题。而且企业不负责后端基础设施，因此也不需要在服务器崩溃或出错时进行修复。云服务提供商所提供的自动扩展和调试功能，帮助无服务器架构成为一个值得投资的项目。

无服务器架构的另一个优点是成本，可能是一个物有所值的选择。节省团队的时间就是节省资金，团队花在后端基础设施维护上的时间越少，企业减少的成本就越多。此外，使用无服务器架构的企业不需要一个完整的团队来管理服务器，因此开发人员不必是服务器专家，这使企业机构的招聘条件变得更加宽松。

2.缺点

企业也应该考虑这种架构的一些缺点。

由于无服务器架构的性质，在上面运行的应用无法被监控。服务器不属于自己，企业机构无法完整地看到上面所运行的一切，也就更加难以衡量一个应用的性能。同时，他们也无法轻易看到性能问题的发展趋势，或主动预防问题。比方说，因为不负责后端，企业机构无法深入研究调查日志。对于企业机构来说，转移这项责任在某些方面可能是件好事，但不好的方面是他们无法看到关键性能分析，也无法了解服务器上的情况究竟如何。

无服务器架构的另一个潜在缺点是安全问题。由于受攻击面大于企业通常使用的内部服务器，无服务器应用可能会面临更大的安全风险。同样，这也取决于云服务提供商和第三方服务所采取的措施与企业安全能力的比较结果。如果企业机构认为自己的服务器安全性不如AWS Lambda，那么与云供应商合作更加明智。

资源限制也可能是无服务器架构的缺点之一。虽然无服务器架构具有弹性，可以通过加速和减速来为应用分配资源，但它是有限制的。如果一家企业机构的应用大到超过这些限制，那么可能就不适合使用无服务器架构。

某些应用在设计上不适合成为无服务器应用，所以无服务器架构并非适合每一个用例。如果根据应用所使用的资源来定价，有些应用会不断消耗所获得的计算资源，使无服务器架构的成本激增。此类应用会占用越来越多的资源，而企业机构必须为此买单。

完

前端走进云原生，k8s部署助力项目上云

 一、云原生

云原生是面向云应用设计的一种全新架构理念,是充分发挥云效能的最佳实践路径,可以帮助企业构建弹性可靠、松耦合、易管理可观测的应用系统,提升关键应用的交付效率,降低系统的运维复杂度。

云原生是一种文化，更是一种潮流，也是云计算的一个必然导向。意义在于让云成为云化战略成功的基石，而不是障碍。

二、k8s部署助力项目上云

在完成整体代码的开发后 ， 我们还需要考虑部署问题 。

这个时候k8s就有了很大的发挥空间，使用 Docker 接入整个开发 、 生产 、 打包流程 ， 保证各运行环境一致、使用 Kubernetes 作为容器编排 ，最终解决项目部署云端的问题。

1、主要思路

  • 本地开发时使用 Docker 开发
  • 推送代码至 Gitlab 触发 CI
  • CI 基于基础镜像打包 ， 每个 COMMIT ID 对应一个镜像 ， 推送至私有仓库 ，触发 CD
  • CD 通过 kubectl 控制 K8s 集群更新应用

2、在本地开发阶段 ， 我们将依赖下载及开发模式分开 。

# 依赖下载
docker run -it \\
    -v $(pwd)/package.json:/opt/work/package.json \\
    -v $(pwd)/yarn.lock:/opt/work/yarn.lock \\
    -v $(pwd)/.yarnrc:/opt/work/.yarnrc \\ 
    # 挂载 package.json 、 yarn.lock 、 .yarnrc 到 /opt/work/ 下
    -v mobile_node_modules:/opt/work/node_modules \\ 
    # /opt/work/node_modules 挂载为 mobile_node_modules 数据卷
    --workdir /opt/work \\
    --rm node:13-alpine \\
    yarn

在依赖下载中 ， 思路是将 node_modules 目录作为一个数据卷 。 在需要使用时将其挂载到指定目录下 ， 之后只需要将会影响到依赖下来的相关文件挂载到容器中 ， 将 node_modules 数据卷挂载到文件夹 。 这样子就能持久化存储依赖文件 。

# 开发模式
docker run -it \\
    -v $(pwd)/:/opt/work/ \\ 
    # 挂载项目目录至 / opt/work/ 下
    -v mobile_node_modules:/opt/work/node_modules \\ 
    # 挂载 node_modules 数据卷到 /opt/work/node_modules 目录下
    --expose 8081 -p 8081:8081 \\ # HotReload Socket
    --expose 9229 -p 9229:9229 \\ # debugger
    --expose 3003 -p 3003:3003 \\ # Node Server
    # 暴露各个端口
    --workdir /opt/work \\
    node:13-alpine \\
    ./node_modules/.bin/nodemon --inspect=0.0.0.0:9229 --watch server server/bin/www

开发模式下 ， 我们只需要将之前的 node_modules 数据卷挂载到 node_modules 目录 ， 再将项目目录挂载到容器中 。 暴露指定端口即可开始开发 。 这里 8081 为写死的 HotReload Socket 接口 、 3003 为 Node 服务接口 、 9229 为 debugger 接口 。 再把启动命令设置为开发模式指令就可以正常开发 。

3、推送代码 ， 触发 CI 。

在 CI 阶段 ， 我们通过 Dockerfile 为每一次提交记录都生成一个与之对应的镜像 。

FROM node:13-alpine

COPY package.json /opt/dependencies/package.json
COPY yarn.lock /opt/dependencies/yarn.lock
COPY .yarnrc /opt/dependencies/.yarnrc
RUN cd /opt/dependencies \\
    && yarn install --frozen-lockfile \\
    && yarn cache clean \\
    && mkdir /opt/work \\
    && ln -s /opt/dependencies/node_modules /opt/work/node_modules

# 具体文件处理
COPY ci/docker/docker-entrypoint.sh /usr/bin/docker-entrypoint.sh
COPY ./ /opt/work/
RUN cd /opt/work \\
    && yarn build

WORKDIR /opt/work
EXPOSE 3003
ENV NODE_ENV production

ENTRYPOINT ["docker-entrypoint.sh"]
CMD ["node", "server/bin/www"]

上面是我们使用到的一个 Dockerfile 。

  1. 使用 node:13-alpine 作为基础镜像
  2. 复制依赖相关文件到容器中下载依赖 ， node_modules 软连接到 /opt/work 下 。 清理安装缓存
  3. 复制项目文件到容器中 ， 执行客户端代码打包命令
  4. 设置环境变量 ， 对外暴露服务端口 ， 设置镜像启动命令
docker build -f Dockerfile --tag frontend-mobile:COMMIT_SHA .

最后使用以上命令将该版本打包为一个镜像 ， 推送至私有仓库 。

我们在 Dockerfile 优化编译速度及镜像体积时使用到的一些技巧:

  1. 前置合并不变的操作 ， 将下载依赖和编译分开为两个RUN 指令 ， 可以利用 Docker 的层缓存机制 。 在依赖不变的情况下 ， 跳过依赖下载部分 ， 直接使用之前的缓存。
  2. 每次操作后清理不需要的文件 ， 如 yarn 生成的全局缓存 ，这些缓存不会影响到我们程序的运行 。 还有很多包管理工具也会生成一些缓存 ， 按各种需要清理即可 。
  3. ‘.dockerignore’ 中忽略不影响到编译结果的文件 ， 下次这些文件变动时 ， 打包会直接使用之前的镜像 ， 改个 README 或者一些 K8s 发布配置时就不会重新打包镜像 。

4、推送镜像至私有仓库 ， 触发 CD 。

使用 Kubernetes 进行容器编排 。

K8s 非常的灵活且智能 。 我们只需要描述我们需要怎么样的应用程序 。 K8s 就会根据资源需求和其他约束自动放置容器 。括一些自动水平扩展 ， 自我修复 。能方便我们去追踪监视每个应用程序运行状况 。

CD 容器通过 kubectl 控制 K8s 集群 。在每个分支提交代码触发 CD 之后 ， 会为每个分支单独创建一个 Deployment 。 对应每个分支环境 。通过 Service 暴露一组指定 Deployment 对应的 Pod 服务 ， Pod 运行的是 Deployment 指定的应用镜像 。最后使用 Ingress 根据域名区分环境对外提供服务 。

5、k8s配置

apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend-mobile  # deployment 名称
  namespace: mobile # 命名空间
  labels:
    app: frontend-mobile # 标签
spec:
  selector:
    matchLabels:
     # 对应的 Pod 标签, 被其选择的 Pod 的现有副本集将受到此部署的影响
     app: frontend-mobile
  replicas: 8 # Pod 节点数量, 默认为 1
  template:   # 相当于 Pod 的配置
    metadata:
      name: frontend-mobile  # Pod 名称
      labels:
        app: frontend-mobile # Pod 标签
    spec:
      containers:
        - name: frontend-mobile
          image: nginx:latest
          ports:
            - containerPort: 3003
          resources: # 设置资源限制
            requests:
              memory: "256Mi"
              cpu: "250m"     # 0.25 个cpu
            limits:
              memory: "512Mi"
              cpu: "500m"     # 0.5 个cpu
          livenessProbe:
            httpGet:
              path: /api/serverCheck
              port: 3003
              httpHeaders:
                - name: X-Kubernetes-Health
                  value: health
            initialDelaySeconds: 15
            timeoutSeconds: 1
---
apiVersion: v1
kind: Service
metadata:
  name: frontend-mobile  # Service 名称
  namespace: mobile # 命名空间
  labels:
    app: frontend-mobile # 标签
spec:
  selector:
    app: frontend-mobile # 对应的 Pod 标签
  ports:
    - protocol: TCP
      port: 8081       # 服务端口
      targetPort: 3003 # 代理端口
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: frontend-mobile
  namespace: mobile # 命名空间
  labels:
    app: frontend-mobile # 标签
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
    - host: local-deploy.com
      http:
        paths:
          - path: /
            backend:
              serviceName: frontend-mobile # 引用的服务名称
              servicePort: 8081         # 引用的服务端口, 对应 Service 中的 port

三、总结

到这里，前端项目的部署在k8s上的配置基本ok了。

CI / CD管道通过一系列测试套件和部署环境来促进变化。 通过一个阶段需求的更改会自动部署或排队，以便手动部署到更严格的环境中。 早期阶段是为了证明继续测试并推动变更更接近生产是值得的。

尤其对于后期阶段，在测试环境中尽可能接近地再现生产环境有助于确保测试准确地反映变化在生产中的表现。 分期和生产之间的显着差异可以允许发布有问题的变更，而这些变更在测试中从未被发现过。 

每个CI / CD的实施将有所不同，遵循这些基本原则中的一些将帮助您避免一些常见的陷阱并加强您的测试和开发实践。 与持续集成的大多数方面一样，过程，工具和习惯的混合将有助于使发展变化更加成功和有影响力。

开发者涨薪指南 48位大咖的思考法则、工作方式、逻辑体系

以上是关于云原生项目上云最佳实践的主要内容，如果未能解决你的问题，请参考以下文章

前端走进云原生，k8s部署助力项目上云

前端走进云原生，k8s部署助力项目上云

2022-07-10企业构建云原生应用上云知识库最佳实践

2022-07-10企业构建云原生应用上云知识库最佳实践

2022-07-10企业构建云原生应用上云知识库最佳实践

前端走进云原生，k8s部署助力项目上云