基于容器K8S构建云原生架构

云时代的云原生应用大势已来，将传统的单体架构应用迁移到云原生架构，你准备好了吗？

当前很多企业正在采用云原生应用架构，这可以帮助其IT转型，成为市场竞争中真正敏捷的力量。

O'Reilly 的报告中定义了云原生应用架构的特性，包括

• 十二因素应用程序：云原生应用架构模式的集合(🏆DevOps “八荣八耻”)
• 微服务化：独立部署的服务，每个服务只做一件事情
• 自助服务的敏捷基础设施：快速，可重复和一致地提供应用环境和后台服务的平台(Docker,Kubernetes,Devops)
• 基于API的协作：发布和版本化的API，允许在云原生应用架构中的服务之间进行交互(接口为王, Serverless)
• 弹性扩展：根据压力变化的可弹性扩容系统

CNCF对云原生（Cloud Native）的定义包含以下三个方面：

• 应用容器化(Docker)
• 面向微服务架构(API)
• 应用支持容器的编排调度(Kubernetes)

观察原来的程序有哪些

• 必须模块(如nginx -v的模块);
• 扩展模块(如php -m的扩展，nodejs的npm modules,python的requirement…)
• 版本号影响(如php5/7语法差异，python2/3语法不兼容…)
• 安全漏洞(openssl漏洞…) 上是否可以满足 → 满足就用官方镜像，不满足就要重新编译镜像

打包镜像过程中，熟练掌握 Dockerfile语法和流程

• 注意build是否正常
• 有无异常退出日志
• 尺寸上alpine > slim > normal(但alpine会有兼容性问题)

反复适配原来服务的那些参数，目录位置，权限，文件名，

注意文件中的某些参数是否与Dockerfile中的定义冲突？→ 仔细观察日志输出并定位

微服务改造后，本地调用 → 内部域名调用，配置文件修改&注入，如nginx → php:9000

检查选项是否正确？

• 公有云安全事项
• 备案资质
• 负载均衡
• 防火墙端口
• 白名单列表
• 镜像仓库地址

可以考虑以下几种方法：

API 密钥限制：可以在 API 接口中加入 API 密钥验证，限制只有特定的应用程序或开发人员才能够调用 API 接口。这样可以防止未经授权的第三方应用程序或开发人员封装和转发 API 接口。

记录 API 调用日志：记录 API 调用日志可以帮助开发人员追踪和监视 API 的使用情况，包括 API 被哪些应用程序或开发人员调用、调用次数和调用频率等。通过这些信息，开发人员可以判断是否存在二次封装和转发行为。

API 访问限制：可以设置 API 的访问限制，例如限制 API 的调用次数、频率和流量等。这样可以防止过度使用和滥用 API 接口，减少二次封装和转发的可能性。

加密二进制传输：在 API 接口的传输过程中使用加密技术，例如 SSL/TLS 等，可以防止第三方应用程序或开发人员通过网络拦截和窃取 API 接口数据。

数字签名：可以在 API 接口中加入数字签名验证，确保请求和响应数据的完整性和安全性。这样可以防止第三方应用程序或开发人员篡改 API 接口数据。

以上方法可以有效地限制或发现 API 接口的二次封装和转发行为，但需要开发人员在设计 API 接口时就考虑这些因素，并对 API 接口进行适当的安全设计和实现。

• 使用 GitLab CI 与 Argo CD 进行 GitOps 实践

• Skaffold-简化本地开发kubernetes应用的神器
• Draft-help developers hit the ground running with Kubernetes

根据企业的偏好设置您的服务器，更加灵活和安全。

两全其美的选择。