Cloud-Native

「K8S 生态周报」内容次要蕴含我所接触到的 K8S 生态相干的每周值得举荐的一些信息。欢送订阅知乎专栏「k8s生态」。Kubernetes ingress-nginx v1.1.2 公布就在明天 Kubernetes ingress-nginx 我的项目公布了 v1.1.2 版本。我是这个版本的 release manager 。 间隔上个版本公布有将近两个月了，咱们来看看这个版本中值得关注的一些变更。 在 #8221 中，咱们对 ingress-nginx 的 Admission controller 的逻辑做了一些调整，次要是能够用来修改 自 v1.0 版本后，如果 Kubernetes 集群中同时运行多个 ingress-nginx 的话，在创立 Ingress 资源的时候，可能导致每个 ingres-nginx 的 Admission 都会去进行查看的问题。而该问题最大的影响是，如果创立的 Ingress 配置雷同的话，则会被间接回绝掉。 在 #8253 中则是为 ingress-nginx 减少了一个 ssl_certificate_info 的 metric， 间接公开以后被加载的证书的信息。这个性能的最大的益处就是能够防止 Ingress controller Pod 加载了旧证书，进而导致客户端连贯失败的问题。 此外 #8256 是为了修改在 nginx.ingress.kubernetes.io/auth-url 中传递有效 URL 的问题，倡议降级 。 此外还有一些小的 bugfix 和优化，更多详细信息请参考 ReleaseNote 。 在这次公布过程中还有一些比拟乏味的事件，本次公布过程从工夫线看，从我开始公布流程，到最初实现公布，共继续了一周的工夫，由几个人异步合作实现。这跟平常差异还是比拟大的，平常咱们可能会约某个工夫，同时在线一起来实现。这次各种起因吧，也比较忙，往后兴许就会放弃这种模式了 （对多时区的合作比拟敌对）。 Istio 1.13.1 公布在之前的 《K8S 生态周报| Istio 行将公布重大安全更新，多个版本受影响》 中，我曾介绍过 Istio v1.13 的次要性能，以及 Istio 会在 v1.13.1 中修复一个重大安全漏洞 CVE-2022-23635。 ...

在金融行业数字化转型的驱动下，国有银行、股份制银行和各级商业银行也纷纷步入容器化的过程。 如果以容器云上生产为指标，那么整个容器云平台的设计、建设和优化对于银行来说是一个微小的挑战。如何更好地利用云原生技术，帮忙银行实现麻利、轻量、疾速、高效地进行开发、测试、交付和运维一体化，从而重构业务，推动金融科技的倒退，是个长期课题。 因而，twt社区主办了主题为“银行高并发交易类场景下，容器云架构如何保障高性能、高可靠性“的线上交流活动，吸引了泛滥来自银行一线的技术大咖参加交换。咱们将干货整理出来，以“金融云原生漫谈”系列文章的模式陆续出现。 很多银行会抉择自建容器云平台，或者间接采纳成熟的K8s发行版，不论是哪种计划，容器云如何与银行本身的继续集成系统、测试服务零碎，或者DevOps流水线进行无效对接，更好地晋升IT零碎产品研发效力和交付效率，是值得咱们去深刻思考的问题。 家喻户晓，传统瀑布式开发动辄耗时数月甚至数年，无奈满足业务疾速变动和竞争的需要，只有引入继续交付和 DevOps，掌控从开发、测试到运维的利用全生命周期，能力打造出疾速迭代、与业务同频的利用，为企业发明盈利的价值链。 云原生技术的呈现，为DevOps插上了翅膀，能够更加充沛地利用云原生基础设施，基于微服务架构体系和开源规范，晋升继续交付和智能自运维的能力，从而做到比传统DevOps更高的服务质量、更低的开发运维老本，让研发专一于业务的疾速迭代。 过来的几年间，灵雀云有幸服务了超过半数的全国性股份制银行和泛滥商业银行，在这些银行业的云原生实际中发现，银行在设计容器云平台的时候，能够通过以下几点无效地晋升各类利用产品的研发效力和交付效率： 如何利用容器云晋升研发效力首先，银行本身的继续集成系统、测试服务零碎或者DevOps流水线工具，咱们倡议尽可能应用开源工具来建设，目标次要是让整个产品研发的工具链体系和开发流程更加灵便，目前咱们看到有大量中小银行都在采纳开源工具链来进行DevOps工具体系的建设。 同时，倡议引入一些凋谢的能够整合这些开源工具链的产品，例如灵雀云的DevOps开放平台，充沛尊重银行原来应用的开源工具链，通过工具链集成的模式简化银行DevOps工具体系建设的复杂性，对立DevOps工具链全链路管理能力。 其次，扭转利用的交付形式。原来传统的以二进制Jar包、War包为制品的交付形式，最好对立成以规范容器镜像包为制品的交付形式进行交付，须要留神的是，要严格标准业务利用运行的中间件版本或者利用运行环境等，例如限定JDK的某几个罕用版本，Tomcat的某几个罕用版本等，同时尽可能应用轻量化、可容器化的中间件作为业务利用的运行环境，例如tomcat、nginx等，不倡议应用websphere、weblogic这种比拟重的并且对于容器化不够敌对的中间件产品。 最初，倡议引入Service Mesh这种下一代微服务网格技术，简化产品研发的人力资源投入，晋升整个产品的服务治理和全局可视化治理的能力。 如何利用容器云晋升交付效率首先，容器云平台肯定要提供凋谢的API对接能力，目前市面上支流的容器云平台都是基于Kubernetes技术倒退进去的，所以Kubernetes的原生对接能力是十分重要的； 其次，银行本身的继续集成系统、测试服务零碎或者DevOps流水线须要具备和容器云平台对接的能力，例如这些麻利开发工具能够间接调用Kubernetes的API来主动进行利用的继续公布； 另外，倡议容器云平台最好能够提供一部分DevOps CD的性能，在银行现有麻利开发工具无奈进行容器云平台API对接的状况下，能够通过例如基于制品更新为触发条件的自动化继续公布能力。 灵雀云在银行的云原生转型实际上曾经有了很多胜利的落地案例，银行能够通过灵雀云的银行业容器PaaS解决方案，搭建自主可控、自下而上的云治理技术平台，实现IT基础设施从硬件化IT到软件化IT的转变，更好地晋升产品研发效力和交付效率。

大家好，我是张晋涛。 本篇我来为你介绍一个我集体很喜爱的，通用策略引擎，名叫 OPA，全称是 Open Policy Agent。 在具体聊 OPA 之前，咱们先来聊一下为什么须要一个通用策略引擎，以及 OPA 解决了什么问题。 OPA 解决了什么问题在理论的生产环境中很多场景中都须要策略管制，比方： 须要策略管制用户是否可登陆服务器或者做一些操作；须要策略管制哪些项目/哪些组件可进行部署；须要策略管制如何拜访数据库；须要策略管制哪些资源可部署到 Kubernetes 中； 然而对于这些场景或者软件来说，配置它们的策略是须要与该软件进行耦合的，彼此是不对立，不通用的。治理起来也会比拟凌乱，带来了不小的保护老本。 OPA 的呈现能够将各处配置的策略进行对立，极大的升高了保护老本。以及将策略与对应的软件/服务进行解耦，不便进行移植/复用。 OPA 的倒退过程OPA 最后是由 Styra 公司在 2016 年创立并开源的我的项目，目前该公司的次要产品就是提供可视化策略管制及策略执行的可视化 Dashboard 服务的。 OPA 首次进入 CNCF 并成为 sandbox 级别的我的项目是在 2018 年， 在 2021 年的 2 月份便曾经从 CNCF 毕业，这个过程相对来说还是比拟快的，由此也能够看出 OPA 是一个比拟沉闷且利用宽泛的我的项目。 OPA 是什么后面咱们曾经介绍过 Open Policy Agent (OPA) 是一种开源的通用策略引擎，可在整个堆栈中实现对立、上下文感知的策略管制。 OPA 可将策略决策与应用程序的业务逻辑拆散（解耦），透过景象看实质，策略就是一组规定，申请发送到引擎，引擎依据规定来进行决策。 图 3 ，OPA 的策略解耦示例 OPA 并不负责具体任务的执行，它仅负责决策，须要决策的申请通过 JSON 的形式传递给 OPA ，在 OPA 决策后，也会将后果以 JSON 的模式返回。 ...

大家好，我是张晋涛。 在前两篇内容中，我别离为大家介绍了 GitOps 的概念，以及用于施行 GitOps 的工具 Argo CD。本篇咱们将以一个示例我的项目为大家介绍 Argo CD 的实际。 创立集群咱们通过 KIND（Kubernetes in Docker）工具创立一个用于本地测试的 Kubernetes 集群。应用如下的配置文件，创立一个蕴含一个 control plane 和三个 work 的集群。 kind: ClusterapiVersion: kind.x-k8s.io/v1alpha4nodes:- role: control-plane- role: worker- role: worker- role: worker应用如下命令进行集群的创立： ➜ (MoeLove) kind create cluster --config=kind-config.yaml Creating cluster "kind" ... ✓ Ensuring node image (kindest/node:v1.20.2) ✓ Preparing nodes ✓ Writing configuration ✓ Starting control-plane ️ ✓ Installing CNI ✓ Installing StorageClass ✓ Joining worker nodes Set kubectl context to "kind-kind"You can now use your cluster with:kubectl cluster-info --context kind-kindHave a nice day! 执行如下命令期待集群齐全 Ready： ...

大家好，我是张晋涛。 接下来会为大家带来一个 GitOps 的利用实际系列文章，这是第一篇。 什么是 GitOps首先咱们来理解下 GitOps： GitOps 最早是在2017年由 Weaveworks 创建提出，它是一种进行 Kubernetes 集群治理和应用程序交付的形式。 GitOps 应用 Git 作为申明性基础设施和应用程序的繁多事实起源。 GitOps 的核心思想是领有一个 Git repository，蕴含指标环境中以后所需基础设施的申明性形容，以及使指标环境与 Git repository 中形容的状态相匹配的自动化过程。借助 GitOps，能够针对 Git repository 与集群中运行的内容之间的任何差别收回警报，如果存在差别，Kubernetes reconcilers会依据状况自动更新或回滚集群。 以 Git 作为 pipeline 的核心，开发人员能够应用本人相熟的工具收回PR，以减速和简化 Kubernetes 中应用程序部署和操作工作。 这使得 GitOps 在 Twitter 和 KubeCon 上引起了不小的轰动。 这里说一下Weaveworks 这家公司，这是一家为开发人员提供最高效的形式来连贯、察看和管制 Docker 容器的公司。在官网上，咱们能看到，GitOps 工作流的准则和模式，如何实现它们在生产中大规模运行 Kubernetes， 以及GitOps 和基础设施即代码 (IAC) 配置管理工具之间的区别和最佳实际等等。https://www.weave.works/techn... K8S的创始人之一：Kelsey Hightower 曾发推文评论过 GitOps是基于申明式基础设施的版本化 CI/CD， 进行脚本化操作，开始（自动化）散发。 GitOps 是如何工作的呢？把环境配置作为 Git repositoryGitOps 以代码库为外围来组织部署。 咱们须要至多有两个仓库：利用程序库和环境配置库。 利用程序库蕴含应用程序的源代码和部署应用程序的 manifests。 环境配置库蕴含部署环境以后所需基础架构的所有部署manifests。 它形容了哪些应用程序和基础设施服务（音讯代理、服务网格、监控工具等）应该在部署环境中以何种配置和版本运行等内容。 ...

「K8S 生态周报」内容次要蕴含我所接触到的 K8S 生态相干的每周值得举荐的一些信息。欢送订阅知乎专栏「k8s生态」。KIND v0.11.0 正式公布KIND (Kubernetes In Docker) 关注我的小伙伴想必曾经都很相熟了，这是我始终都在参加也用的十分多的一个我的项目，它能够很不便的应用 Docker 容器作为 Kubernetes 的 Node ，疾速的启动一个/或多个测试集群。自上个版本公布以来曾经过了 4 个月，咱们一起来看看这个版本中有哪些值得注意的变更吧！ 破坏性变更在这个版本中默认的 k8s 版本为 v1.21.1;移除掉了应用 bazel 构建镜像的形式，kind build node-image 的 --type 参数已废除；kind build node-image 的 --kube-root 参数已废除，将会依照规范模式寻找 k8s 的代码目录的地位；新个性kind build node-image 新增了一个 --arch 的参数，可反对构建多架构的镜像了；KIND 以后公布的预构建镜像，曾经都是 multi-arch 的了，可运行在 amd64 和 arm64 架构上；以后 KIND 曾经能够运行在 rootless 模式下的 Docker 和 rootless 模式下的 Podman 中了，具体指南请参考 KIND 运行在 rootless 模式 ;KIND 默认的 CNI kindnetd 曾经反对了双栈网络, 并在 v1.21 版本的 k8s 中默认启用 ;你能够通过以下任意形式装置最新版的 KIND ： ...