带你读《云原生应用开发 Operator原理与实践》第二章 Operator 原理2.1(三)

本文涉及的产品
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
简介: 带你读《云原生应用开发 Operator原理与实践》第二章 Operator 原理2.1

3. k8sAPI设计规范

 

Kubernetes   API   是集群系统中的重要组成部分,Kubernetes    中各种资源(对象)的数据通过该   API  被传送到后端的持久化存储(ETCD)中。Kubernetes   集群中的各部件之间通过该 API实现解耦合,KubernetesAPI中的资源对象都拥有通用的元数据,资源对象也可能存在嵌套现象,比如在一个 Pod中嵌套多个 Container。创建一个API    对象是指通过    API   调用创建一条有意义的记录,该记录一旦被创建,Kubernetes 将确保对应的资源对象会被自动创建并托管维护。在Kubernetes系统中,大多数情况下, API定义和实现都符合标准的 HTTPREST格式,如通过标准的 HTTP动作POSTPUTGETDELETE来完成对相关资源对象的查询、修改、删除等操作。但同时Kubernetes为某些非标准的REST行为提供了附加的 API,例如,监听某个资源变化的 Watch接口等。另外,某些 API可能违背严格的REST模式,因为接口不是返回单一的 JSON对象,而是返回其他类型的数据,如 JSON对象流Stream)或非结构化的文本日志数据等。 从上面的 CRD定义中可以发现,在 Kubernetes中要想完成一个 CRD,需要指定 Group、VersionKind,这在 KubernetesAPIServer中简称为 GVK。当我们在 Kubernetes中谈论API时,经常会提起 4个术语:GroupsVersions、KindsResources。

(1)      Groups/Versions

Kubernetes中的 API 组简单来说就是相关功能的集合。每个组都有一个或多个版本,它允许我们随着时间的推移改变 API的职责。

(2)      Kinds/Resources

每个 API- 版本包含一个或多个API类型,我们称之为 Kinds。虽然一个Kind可以在不同版本之间改变表单内容,但每个表单必须能够以某种方式存储其他表单的所有数据(我们可以将数据存储在字段或者注释中。 这意味着,使用旧的API版本不会导致新的数据丢失或损坏。

Resources只是 API中的一个 Kind 的使用方式。通常情况下,KindResources间是一对一的映射。 例如,Pods资源对应于 Pod 种类。但是有时同一类型可能由多个资源返回。例如,ScaleKind是由所有 Scale子资源返回的,它由 Deployments/ScaleReplicasets/Scale组成。这就是允许 KubernetesHPA(HorizontalPodAutoscaler)与不同资源交互的原因。然而,使用 CRD每个 Kind 都将对应一个 Resource。

GVK 是定义一种类型的方式。例如,Daemonsets就是 Kubernetes中的一种资源,当我们要求 Kubernetes创建一个 Daemonsets的时候Kubectl是如何知道该怎么向APIServer发送这个信息呢?是所有的不同资源都发向同一个URL,还是每种资源都是不同的?例如Daemonsets资源内容(见代码清单2-5

apiVersion:apps/v1kind:DaemonSetmetadata:

name:node-exporter

这里声明了 apiVersionapps/v1,其实就是隐含了 Groupapps,Versionv1,Kind就是定义的 DaemonSet,而   Kubectl  接收到这个声明之后,就可以根据这个声明去调用 APIServer对应的 URL来获取信息。例如,/api/apps/v1/daemonset这样API 就是由上面的设计规则实现的。Kubernetes  以符合 REST规范的 URI来组织资源。

 

前面介绍了  GVKGroupVersionKind,接下来介绍APIServer的第二个概GVRGroupVersionResource其实理解了GVK  之后再理解GVR  就很容易了,这就是面向对象编程中的类和对象的概念是一样的。Kind     相当于一个类,Resource是具体的 Kind,可以理解为一个类的对象资源。那么 GVR资源如何对应到GVK?这就是RESTMapping 的功能:RESTMapping 可以将指定的一个GVRDaemonset资源过转换映射返回对应的GVK 以及支持的操作等。

(3)      API版本

为了在兼容旧版本的同时不断升级 API,Kubernetes提供了多版本   API   的支持能力,每个版本的API通过一个版本号路径前缀加以区分,例如   /api/v1beta3。通常情况下,新旧几个不同的 API版本都能涵盖所有的 Kubernetes资源对象,在不同的版本之间这些 API存在一些细微差别。Kubernetes开发团队基于 API级别选择版本而不是基于资源和域级别来选择版本,是为了确保API能够描述一个清晰、连续的系统资源和行为的视图,能够控制访问的整个过程和实验性API的访问 。

API 详细说明如下。

GET/<资源名的复数格式>:获得某一类型的资源列表,例如GET/Pods返回一Pod资源列表。

POST/<资源名的复数格式>:创建一个资源,该资源来自用户提供的JSON 对象。

GET/<资源名复数格式 >/<名字 >:通过给出的名称(Name)获得单个资源,例GET /pods/podname返回一个名称为“podname”Pod。

DELETE/< 资源名复数格式 >/< 名字 >:通过给出的名字删除单个资源。删除选项(DeleteOptions)中可以指定的优雅删除(GraceDeletion)的时间(GracePeriodSeconds,该可选项表明了从服务端接收删除请求到资源被删除的时间间隔单位为s不同的类别(Kind)可能为优雅删除时间(Grace    Period)申明默认值。用户提交的优雅删除时间将覆盖该默认值,包括值为0 的优雅删除时间。

PUT/<资源名复数格式 >/<名字>:通过给出的资源名和客户端提供的 JSON对象来更新或创建资源。

PATCH/<资源名复数格式 >/<名字>:选择修改资源详细指定的域。此外,KubernetesAPI 添加了资源变动的观察者模式的API

GET/watch/<资源名复数格式>:随时间变化,不断接收一连串的JSON对象,这些JSON 对象记录了给定资源类别内所有资源对象的变化情况。

GET/watch/<资源名复数格式 >/:随时间变化,不断接收一连串的JSON对象,这些JSON 对象记录了某个给定资源对象的变化情况。

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
19天前
|
运维 Cloud Native 持续交付
云原生架构的演进与实践####
【10月更文挑战第16天】 云原生,这一概念自提出以来,便以其独特的魅力和无限的可能性,引领着现代软件开发与部署的新浪潮。本文旨在探讨云原生架构的核心理念、关键技术及其在实际项目中的应用实践,揭示其如何帮助企业实现更高效、更灵活、更可靠的IT系统构建与管理。通过深入剖析容器化、微服务、持续集成/持续部署(CI/CD)等核心技术,结合具体案例,本文将展现云原生架构如何赋能企业数字化转型,推动业务创新与发展。 ####
119 47
|
7天前
|
弹性计算 Kubernetes Cloud Native
云原生架构下的微服务设计原则与实践####
本文深入探讨了在云原生环境中,微服务架构的设计原则、关键技术及实践案例。通过剖析传统单体架构面临的挑战,引出微服务作为解决方案的优势,并详细阐述了微服务设计的几大核心原则:单一职责、独立部署、弹性伸缩和服务自治。文章还介绍了容器化技术、Kubernetes等云原生工具如何助力微服务的高效实施,并通过一个实际项目案例,展示了从服务拆分到持续集成/持续部署(CI/CD)流程的完整实现路径,为读者提供了宝贵的实践经验和启发。 ####
|
8天前
|
Kubernetes 负载均衡 Cloud Native
云原生应用:Kubernetes在容器编排中的实践与挑战
【10月更文挑战第27天】Kubernetes(简称K8s)是云原生应用的核心容器编排平台,提供自动化、扩展和管理容器化应用的能力。本文介绍Kubernetes的基本概念、安装配置、核心组件(如Pod和Deployment)、服务发现与负载均衡、网络配置及安全性挑战,帮助读者理解和实践Kubernetes在容器编排中的应用。
32 4
|
12天前
|
NoSQL Cloud Native atlas
探索云原生数据库:MongoDB Atlas 的实践与思考
【10月更文挑战第21天】本文探讨了MongoDB Atlas的核心特性、实践应用及对云原生数据库未来的思考。MongoDB Atlas作为MongoDB的云原生版本,提供全球分布式、完全托管、弹性伸缩和安全合规等优势,支持快速部署、数据全球化、自动化运维和灵活定价。文章还讨论了云原生数据库的未来趋势,如架构灵活性、智能化运维和混合云支持,并分享了实施MongoDB Atlas的最佳实践。
|
13天前
|
监控 Cloud Native Java
云原生架构下微服务治理策略与实践####
【10月更文挑战第20天】 本文深入探讨了云原生环境下微服务架构的治理策略,通过分析当前技术趋势与挑战,提出了一系列高效、可扩展的微服务治理最佳实践方案。不同于传统摘要概述内容要点,本部分直接聚焦于治理核心——如何在动态多变的分布式系统中实现服务的自动发现、配置管理、流量控制及故障恢复,旨在为开发者提供一套系统性的方法论,助力企业在云端构建更加健壮、灵活的应用程序。 ####
59 10
|
8天前
|
Kubernetes Cloud Native API
云原生架构下微服务治理的深度探索与实践####
本文旨在深入剖析云原生环境下微服务治理的核心要素与最佳实践,通过实际案例分析,揭示高效、稳定的微服务架构设计原则及实施策略。在快速迭代的云计算领域,微服务架构以其高度解耦、灵活扩展的特性成为众多企业的首选。然而,伴随而来的服务间通信、故障隔离、配置管理等挑战亦不容忽视。本研究聚焦于云原生技术栈如何赋能微服务治理,涵盖容器编排(如Kubernetes)、服务网格(如Istio/Envoy)、API网关、分布式追踪系统等关键技术组件的应用与优化,为读者提供一套系统性的解决方案框架,助力企业在云端构建更加健壮、可维护的服务生态。 ####
|
8天前
|
Kubernetes 监控 Cloud Native
云原生应用:Kubernetes在容器编排中的实践与挑战
【10月更文挑战第26天】随着云计算技术的发展,容器化成为现代应用部署的核心趋势。Kubernetes(K8s)作为容器编排领域的佼佼者,以其强大的可扩展性和自动化能力,为开发者提供了高效管理和部署容器化应用的平台。本文将详细介绍Kubernetes的基本概念、核心组件、实践过程及面临的挑战,帮助读者更好地理解和应用这一技术。
36 3
|
13天前
|
NoSQL Cloud Native atlas
探索云原生数据库:MongoDB Atlas 的实践与思考
【10月更文挑战第20天】本文探讨了MongoDB Atlas的核心特性、实践应用及对未来云原生数据库的思考。MongoDB Atlas作为云原生数据库服务,具备全球分布、完全托管、弹性伸缩和安全合规等优势,支持快速部署、数据全球化、自动化运维和灵活定价。文章还讨论了实施MongoDB Atlas的最佳实践和职业心得,展望了云原生数据库的发展趋势。
|
9天前
|
监控 安全 Cloud Native
云原生安全:Istio在微服务架构中的安全策略与实践
【10月更文挑战第26天】随着云计算的发展,云原生架构成为企业数字化转型的关键。微服务作为其核心组件,虽具备灵活性和可扩展性,但也带来安全挑战。Istio作为开源服务网格,通过双向TLS加密、细粒度访问控制和强大的审计监控功能,有效保障微服务间的通信安全,成为云原生安全的重要工具。
27 2
|
8天前
|
监控 Cloud Native 持续交付
云原生技术深度解析:重塑现代应用开发与部署范式####
本文深入探讨了云原生技术的核心概念、关键技术组件及其在现代软件开发中的重要性。通过剖析容器化、微服务架构、持续集成/持续部署(CI/CD)等关键技术,本文旨在揭示云原生技术如何促进应用的敏捷性、可扩展性和高可用性,进而推动企业数字化转型进程。不同于传统摘要仅概述内容要点,本部分将融入具体案例分析,直观展示云原生技术在实际应用中的显著成效与挑战应对策略,为读者提供更加丰富、立体的理解视角。 ####