ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

Kubernetes——自定义 API Server

2022-07-07 20:01:09  阅读:159  来源: 互联网

标签:API 自定义 Kubernetes server Server version APIService


自定义 API Server

  扩展 Kubernetes 系统 API 接口的另一种常用办法是使用自定义的 API Server。相比较 CRD 来说,使用自定义 API Server 更加灵活,例如可以自定义资源类型和子资源、自定义验证及其他逻辑,甚至于在 Kubernetes API Server 中实现的任何功能也都能在 API Server 中实现。

一、自定义 API Server 概述

  自定义 API Server 完全可以独立运行并能够被客户端直接访问,但最方便的方式是将它们与主 API Server(kube-apiserver)聚合在一起使用,这样不仅可以使得集群中的多个 API Server 看起来好像是由单个服务提供服务,集群组件和 kubectl 等客户端可不经修改地继续正常通信,而且也无须特殊逻辑来发现不同的 API Server 等操作。在 kube-apiserver 中,用于聚合自定 API Server 的组件是 kube-aggregator,它自 Kubernetes 1.7 版本引入,并内建于主 API Server 之中作为其进程的一部分来运行。

  在使用自定义 API Server 中的扩展资源之前,管理员需要在主 API Server 上添加一个相应的 APIService资源对象,将自定义 API Server 注册到 kube-aggregator 之上,以完成聚合操作。一个特定的 APIService 对象可用于在主 API Server 上注册一个 URL 路径,如 /apis/auth.zuoyang.tech/v1alph1/,从而使得 kube-aggregator 将发往这个路径的请求代理至相应的自定义 API Server。每个 APIService 对应一个 API 群组版本,不同版本的单个 API 可以由不同的 APIService 对象支持:

二、APIService 对象

  APIService 资源类型的最初设计目标是用于将庞大的主 API Server 分解成多个小型但彼此独立的 API Server,但它也支持将任何遵循 Kubernetes API 设计规范的自定义 API Server 聚合进主 API Server中。

  下面的配置清单示例,它定义了一个名为 v2beta1.auth.zuoyang.tech 的 APIService 对象,用于将 default 命中空间中名为 auth-api 的 Service 对象后端的自定义 API Server 聚合进主 API Server 中:

[root@k8s-master01-test-2-26 ~]# kubectl explain apiservice
KIND:     APIService
VERSION:  apiregistration.k8s.io/v1

DESCRIPTION:
     APIService represents a server for a particular GroupVersion. Name must be
     "version.group".

FIELDS:
   apiVersion	<string>
     APIVersion defines the versioned schema of this representation of an
     object. Servers should convert recognized schemas to the latest internal
     value, and may reject unrecognized values. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources

   kind	<string>
     Kind is a string value representing the REST resource this object
     represents. Servers may infer this from the endpoint the client submits
     requests to. Cannot be updated. In CamelCase. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds

   metadata	<Object>
     Standard object's metadata. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

   spec	<Object>
     Spec contains information for locating and communicating with a server

   status	<Object>
     Status contains derived information about an API server

[root@k8s-master01-test-2-26 ~]# 

  apiservice.spec 内嵌字段定义如下:

[root@k8s-master01-test-2-26 ~]# kubectl explain apiservice.spec
KIND:     APIService
VERSION:  apiregistration.k8s.io/v1

RESOURCE: spec <Object>

DESCRIPTION:
     Spec contains information for locating and communicating with a server

     APIServiceSpec contains information for locating and communicating with a
     server. Only https is supported, though you are able to disable certificate
     verification.

FIELDS:
   caBundle	<string>
     CABundle is a PEM encoded CA bundle which will be used to validate an API
     server's serving certificate. If unspecified, system trust roots on the
     apiserver are used.

   group	<string>
     Group is the API group name this server hosts

   groupPriorityMinimum	<integer> -required-
     GroupPriorityMininum is the priority this group should have at least.
     Higher priority means that the group is preferred by clients over lower
     priority ones. Note that other versions of this group might specify even
     higher GroupPriorityMininum values such that the whole group gets a higher
     priority. The primary sort is based on GroupPriorityMinimum, ordered
     highest number to lowest (20 before 10). The secondary sort is based on the
     alphabetical comparison of the name of the object. (v1.bar before v1.foo)
     We'd recommend something like: *.k8s.io (except extensions) at 18000 and
     PaaSes (OpenShift, Deis) are recommended to be in the 2000s

   insecureSkipTLSVerify	<boolean>
     InsecureSkipTLSVerify disables TLS certificate verification when
     communicating with this server. This is strongly discouraged. You should
     use the CABundle instead.

   service	<Object>
     Service is a reference to the service for this API server. It must
     communicate on port 443. If the Service is nil, that means the handling for
     the API groupversion is handled locally on this server. The call will
     simply delegate to the normal handler chain to be fulfilled.

   version	<string>
     Version is the API version this server hosts. For example, "v1"

   versionPriority	<integer> -required-
     VersionPriority controls the ordering of this API version inside of its
     group. Must be greater than zero. The primary sort is based on
     VersionPriority, ordered highest to lowest (20 before 10). Since it's
     inside of a group, the number can be small, probably in the 10s. In case of
     equal version priorities, the version string will be used to compute the
     order inside a group. If the version string is "kube-like", it will sort
     above non "kube-like" version strings, which are ordered lexicographically.
     "Kube-like" versions start with a "v", then are followed by a number (the
     major version), then optionally the string "alpha" or "beta" and another
     number (the minor version). These are sorted first by GA > beta > alpha
     (where GA is a version with no suffix such as beta or alpha), and then by
     comparing major version, then minor version. An example sorted list of
     versions: v10, v2, v1, v11beta2, v10beta3, v3beta1, v12alpha1, v11alpha2,
     foo1, foo10.

[root@k8s-master01-test-2-26 ~]# 

  定义一个 APIService 对象时,其 Spec 嵌套使用的字段包括如下这些字段:

    • group <string>: 注册使用的 API 群组名称。
    • groupPriorityMinimum <integer> -required-: API 群组的最低优先级,较高优先级的群组将优先被客户端使用;数值越大优先级越高,数值相同时则按名称字符进行排序。
    • version <string>: 注册的 API 群组的版本。
    • versionPriority <integer> -required-: 当前版本在其所属的 API 群组内的优先级;必须使用正整数数值,数值越大优先级越高,数值相同时则按名称字符进行排序。
    • service <Object>: 自定义 API Server 相关的 Service 对象,是真正提供 API 服务的后端,它必须通过 443 端口进行通信。
    • insecureSkipTLSVerify <boolean>: 与此服务通信是否禁止 TLS 证书认证。

  APIService 仅用于将 API Server 进行聚合,真正提供服务的是相应的外部 API Server,这个自定义服务器通常应该以 Pod 的形式托管运行于当前 Kubernetes 集群之上。

  在 Kubernetes 集群上部署使用自定义 API Server 主要由两步组成:

  1. 首先,需要将自定义 API Server 以 Pod 形式运行于集群之上并为其创建 Service 对象。
  2. 然后,创建一个专用的 APIService 对象与 API Server 完成聚合。

  Kubernetes 系统的系统资源指标 API 就由 metrics-server 项目提供,该项目基于 metrics-server 提供了一个扩展的 API,并通过 API 群组 metrics.k8s.io 将其完成聚合。

标签:API,自定义,Kubernetes,server,Server,version,APIService
来源: https://www.cnblogs.com/zuoyang/p/16455797.html

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有