带你玩转kubernetes-k8s（第53篇-Kubernetes API版本的演进策略）

最新推荐文章于 2024-08-08 07:31:27 发布
最新推荐文章于 2024-08-08 07:31:27 发布
阅读量2.8k 收藏 4
点赞数
分类专栏： 带你玩转kubernets-k8s kubernetes
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_31136839/article/details/100135328
版权

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

API的版本号通常用于描述API的成熟阶段，例如：
◎　v1表示GA稳定版本；
◎　v1beta3表示Beta版本（预发布版本）；
◎　v1alpha1表示Alpha版本（实验性的版本）。

当某个API的实现达到一个新的GA稳定版本时（如v2），旧的GA版本（如v1）和Beta版本（例如v2beta1）将逐渐被废弃，Kubernetes建议废弃的时间如下。
◎　对于旧的GA版本（如v1），Kubernetes建议废弃的时间应不少于12个月或3个大版本Release的时间，选择最长的时间。
◎　对旧的Beta版本（如v2beta1），Kubernetes建议废弃的时间应不少于9个月或3个大版本Release的时间，选择最长的时间。
◎　对旧的Alpha版本，则无须等待，可以直接废弃。

完整的API更新和废弃策略请参考官方网站https://kubernetes.io/docs/reference/usingapi/deprecation-policy/的说明。

API Groups(API 组)

      为了更容易对API进行扩展，Kubernetes使用API Groups（API组）进行标识。API Groups以REST URL中的路径进行定义。当前支持两类API groups。

◎　Core Groups（核心组），也可以称之为Legacy Groups，作为Kubernetes最核心的API，其特点是没有“组”的概念，例如“v1”，在资源对象的定义中表示为“apiVersion:v1”。
◎　具有分组信息的API，以/apis/$GROUP_NAME/$VERSION URL路径进行标识，在资源对象的定义中表示为“apiVersion: $GROUP_NAME/$VERSION”，例如：“apiVersion: batch/v1”“apiVersion: extensions:v1beta1”“apiVersion: apps/v1beta1”等，详细的API列表请参见官网https://kubernetes.io/docs/reference，目前根据Kubernetes的不同版本有不同的API说明页面。

例如，Pod的API说明，由于Pod属于核心资源对象，所以不存在某个扩展API Group，页面显示为Core，在Pod的定义中为“apiVersion: v1”。

StatefulSet则属于名为apps的API组，版本号为v1，在StatefulSet的定义中为“apiVersion: apps/v1"。

如果要启用或禁用特定的API组，则需要在API Server的启动参数中设置--runtime-config进行声明，例如，--runtime-config=batch/v2alpha1表示启用API组“batch/v2alpha1”；也可以设置--runtime-config=batch/v1=false表示禁用API组“batch/v1”。多个API组的设置以逗号分隔。在当前的API Server服务中，DaemonSets、Deployments、HorizontalPodAutoscalers、Ingress、Jobs和ReplicaSets所属的API组是默认启用的。

API REST的方法说明

   API资源使用REST模式，对资源对象的操作方法如下。
（1）GET /<资源名的复数格式>：获得某一类型的资源列表，例如GET /pods返回一个Pod资源列表。
（2）POST /<资源名的复数格式>：创建一个资源，该资源来自用户提供的JSON对象。
（3）GET /<资源名复数格式>/<名称>：通过给出的名称获得单个资源，例如GET/pods/first返回一个名为first的Pod。
（4）DELETE /<资源名复数格式>/<名称>：通过给出的名称删除单个资源，在删除选项（DeleteOptions）中可以指定优雅删除（Grace Deletion）的时间（GracePeriodSeconds），该选项表明了从服务端接收到删除请求到资源被删除的时间间隔（单位为s）。不同的类别（Kind）可能为优雅删除时间（Grace Period）声明默认值。用户提交的优雅删除时间将覆盖该默认值，包括值为0的优雅删除时间。

（5）PUT /<资源名复数格式>/<名称>：通过给出的资源名和客户端提供的JSON对象来更新或创建资源。
（6）PATCH /<资源名复数格式>/<名称>：选择修改资源详细指定的域。

对于PATCH操作，目前Kubernetes API通过相应的HTTP首部“Content-Type”对其进行识别。
目前支持以下三种类型的PATCH操作。

（1）JSON Patch, Content-Type: application/json-patch+json。在RFC6902的定义中，JSON Patch是执行在资源对象上的一系列操作，例如 {"op": "add", "path": "/a/b/c", "value": ["foo","bar"]}。详情请查看RFC6902说明，网址为https://tools.ietf.org/html/rfc6902。
（2）Merge Patch, Content-Type: application/merge-json-patch+json。在RFC7386的定义中，Merge Patch必须包含对一个资源对象的部分描述，这个资源对象的部分描述就是一个JSON对象。该JSON对象被提交到服务端，并和服务端的当前对象合并，从而创建一个新的对象。详情请查看RFC73862说明，网址为https://tools.ietf.org/html/rfc7386。
（3）Strategic Merge Patch, Content-Type: application/strategic-merge-patch+json。Strategic Merge Patch是一个定制化的Merge Patch实现。接下来将详细讲解Strategic Merge Patch。

在标准的JSON Merge Patch中，JSON对象总被合并（Merge），但是资源对象中的列表域总被替换，用户通常不希望如此。例如，我们通过下列定义创建一个Pod资源对象：

spec:
  containers:
  - name: bgubx
    image: nginx-1.0

接着，我们希望添加一个容器到这个Pod中，代码和上传的JSON对象如下：

PATH: /api/v1/namespaces/default/pods/pod-name
spec:
  containers:
  - name: log-tailer
    image: log-tailer-1.0

如果我们使用标准的Merge Patch，则其中的整个容器列表将被单个“log-tailer”容器所替换，然而我们的目的是使两个容器列表合并。

为了解决这个问题，Strategic Merge Patch添加元数据到API对象中，并通过这些新元数据来决定哪个列表被合并，哪个列表不被合并。当前这些元数据作为结构标签，对于API对象自身来说是合法的。对于客户端来说，这些元数据作为Swagger annotations也是合法的。在上述例子中向containers中添加了patchStrategy域，且它的值为merge，通过添加patchMergeKey，它的值为name。也就是说，containers中的列表将会被合并而不是替换，合并的依据为name域的值。

此外，Kubernetes API添加了资源变动的观察者模式的API接口。

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

上述接口改变了返回数据的基本类别，watch动词返回的是一连串JSON对象，而不是单个JSON对象。并不是所有对象类别都支持观察者模式的API接口，在后续的章节中将会说明哪些资源对象支持这种接口。

另外，Kubernetes还增加了HTTP Redirect与HTTP Proxy这两种特殊的API接口，前者实现资源重定向访问，后者则实现HTTP请求的代理。

API Server响应说明

API Server在响应用户请求时附带一个状态码，该状态码符合HTTP规范。

状态码编码描述
200OK表明请求完全成功
201Created表明创建类的请求完全成功
204NoContent

表明请求完全成功，同时HTTP响应不包含响应体。

在响应OPTIONS方法的HTTP请求时返回。

307TemporayRedirect表面请求资源的地址改变，建议客户端使用Location首部给出的临时URL来定位资源
400BadRequest表明请求是非法的，建议用户不要重试，修改该请求
401Unauthorized表明请求能够到达服务端，且服务端能够理解用户请求，但是拒绝做更多的事情，因为客户端必须提供认证信息。如果客户端提供了认证信息，则返回该状态码，表明服务端指出所提供的认证信息不合适或非法
403Forbidden表明请求能够到达服务端，且服务端能够理解用户请求，但是拒绝做更多的事情，因为该请求被设置为拒绝访问，建议用户不要重试，修改该请求。
404

NotFound

表明所请求的资源不存在。
405MethodNotAllowed表明在请求中有该资源不支持的方法。
409Conflict表明客户端尝试创建的资源已存在，或者由于冲突，请求的更新操作不能被完成
422UnprocessableEntity表明由于所提供的作为请求部分的数据非法，创建或修改操作不能被完成
429TooManyRequeste表明超出了客户端访问频率的限制或者服务端接收到多于它能处理的请求。建议客户端读取相应的Retry-After首部，然后等待该首部指出的时间后再重试
500InternalServerError表明服务端被请求访问到，但是不能理解用户的请求；或者在服务端内产生非预期的一个错误，而且该错误无法被认知；或者服务端不能再一个合理的时间内完成处理（这可能是服务器临时负载过重造成的，或和其他服务器通信时的一个临时通信故障造成的）
503ServuceUnavailable表面被请求的服务无效。
504ServerTimeout表明请求在给定的时间内无法完成。客户端仅在为请求指定超时（Timeout）参数时得到该响应。

在调用API接口发生错误时，Kubernetes将会返回一个状态类别（Status Kind）。下面是两种常见的错误场景。

（1）当一个操作不成功时（例如，当服务端返回一个非2xx HTTP状态码时）。
（2）当一个HTTP DELETE方法调用失败时。

状态对象被编码成JSON格式，同时该JSON对象被作为请求的响应体。该状态对象包含人和机器使用的域，在这些域中包含来自API的关于失败原因的详细信息。状态对象中的信息补充了对HTTP状态码的说明。例如：

curl -v -k -H "Authorization: Bearer WhCDV4q.............." HTTPS://10.240.122.184:443/api/v1/namespaces/default/pods/grafana

◎ status域包含两个可能的值：Success或Failure。

◎　message域包含对错误的描述信息。
◎　reason域包含说明该操作失败原因的描述。
◎　details可能包含和reason域相关的扩展数据。每个reason域都可以定义它的扩展的details域。该域是可选的，返回数据的格式是不确定的，不同的reason类型返回的details域的内容不一样。

其他客户端库

为了让开发人员更方便地访问Kubernetes的RESTful API，Kubernetes社区推出了针对Go、Python、Java、dotNet、JavaScript等编程语言的客户端库，这些库由特别兴趣小组（SIG）API Machinary维护，其官方网站为https://github.com/kubernetes/community/tree/master/sig-api-machinery。

Kubernetes API的扩展

随着Kubernetes的发展，用户对Kubernetes的扩展性也提出了越来越高的要求。从1.7版本开始，Kubernetes引入扩展API资源的能力，使得开发人员在不修改Kubernetes核心代码的前提下可以对Kubernetes API进行扩展，仍然使用Kubernetes的语法对新增的API进行操作，这非常适用于在Kubernetes上通过其API实现其他功能（例如第三方性能指标采集服务）或者测试实验性新特性（例如外部设备驱动）。

在Kubernetes中，所有对象都被抽象定义为某种资源对象，同时系统会为其设置一个API入口（API Endpoint），对资源对象的操作（如新增、删除、修改、查看等）都需要通过Master的核心组件API Server调用资源对象的API来完成。与API Server的交互可以通过kubectl命令行工具或访问其RESTful API进行。每个API都可以设置多个版本，在不同的API URL路径下区分，例如“/api/v1”或“/apis/extensions/v1beta1”等。使用这种机制后，用户可以很方便地定义这些API资源对象（YAML配置），并将其提交给Kubernetes（调用RESTful API），来完成对容器应用的各种管理工作。

Kubernetes系统内置的Pod、RC、Service、ConfigMap、Volume等资源对象已经能够满足常见的容器应用管理要求，但如果用户希望将其自行开发的第三方系统纳入Kubernetes，并使用Kubernetes的API对其自定义的功能或配置进行管理，就需要对API进行扩展了。目前Kubernetes提供了以下两种机制供用户扩展API。

（1）使用CRD机制：复用Kubernetes的API Server，无须编写额外的API Server。用户只需要定义CRD，并且提供一个CRD控制器，就能通过Kubernetes的API管理自定义资源对象了，同时要求用户的CRD对象符合API Server的管理规范。
（2）使用API聚合机制：用户需要编写额外的API Server，可以对资源进行更细粒度的控制（例如，如何在各API版本之间切换），要求用户自行处理对多个API版本的支持。

使用CRD扩展API资源

        CRD是Kubernetes从1.7版本开始引入的特性，在Kubernetes早期版本中被称为TPR（ThirdPartyResources，第三方资源）。TPR从Kubernetes 1.8版本开始被停用，被CRD全面替换。

CRD本身只是一段声明，用于定义用户自定义的资源对象。但仅有CRD的定义并没有实际作用，用户还需要提供管理CRD对象的CRD控制器（CRD Controller），才能实现对CRD对象的管理。CRD控制器通常可以通过Go语言进行开发，并需要遵循Kubernetes的控制器开发规范，基于客户端库client-go进行开发，需要实现Informer、ResourceEventHandler、Workqueue等组件具体的功能处理逻辑，详细的开发过程请参考官方示例（https://github.com/kubernetes/sample-controller）和client-go库（https://github.com/kubernetes/sample-controller/blob/master/docs/controller-client-go.md）的详细说明。

1.创建CRD的定义

与其他资源对象一样，对CRD的定义也使用YAML配置进行声明。以Istio系统中的自定义资源VirtualService为例，配置文件crd-virtualservice.yaml的内容如下：

apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: virtualservices.networking.istio.io
  annotations:
    "helm.sh/hook": crd-install
  labels:
    app: istio-pilot
  spec:
    group: networking.istio.io
    scope: Namespaced
    versions:
    - name: vlalpha3
      served: true
      storage: true
    names:
      kind: VirtualService
      listKind: VirtualServiceList
      singular: virtualservice
      plural: virtualservices
      categories:
      - istio-io
      - networking-istio-io

CRD定义中的关键字段如下。

（1）group：设置API所属的组，将其映射为API URL中“/apis/”的下一级目录，设置netwirking.stio.io生成的API URL路径为“/apis/networking.istio.io”。
（2）scope：该API的生效范围，可选项为Namespaced（由Namespace限定）和Cluster（在集群范围全局生效，不局限于任何Namespace），默认值为Namespaced。
（3）versions：设置此CRD支持的版本，可以设置多个版本，用列表形式表示。目前还可以设置名为version的字段，只能设置一个版本，在将来的Kubernetes版本中会被弃用，建议使用versions进行设置。如果该CRD支持多个版本，则每个版本都会在API URL“/apis/networking.istio.io”的下一级进行体现，例如“/apis/networking.istio.io/v1”或“/apis/networking.istio.io/v1alpha3”等。每个版本都可以设置下列参数。

◎　name：版本的名称，例如v1、v1alpha3等。
◎　served：是否启用，在被设置为true时表示启用。
◎　storage：是否进行存储，只能有一个版本被设置为置为true。
（4）names：CRD的名称，包括单数、复数、kind、所属组等名称的定义，可以设置如下参数。
◎　kind：CRD的资源类型名称，要求以驼峰式命名规范进行命名（单词的首字母都大写），例如VirtualService。
◎　listKind：CRD列表，默认被设置为<kind>List格式，例如VirtualServiceList。
◎　singular：单数形式的名称，要求全部小写，例如virtualservice。
◎　plural：复数形式的名称，要求全部小写，例如virtualservices。

◎　shortNames：缩写形式的名称，要求全部小写，例如vs。
◎　categories：CRD所属的资源组列表。例如，VirtualService属于istio-io组和networking-istio-io组，用户通过查询istio-io组和networking-istio-io组，也可以查询到该CRD实例。

使用kubectl create命令完成CRD的创建：

kubectl create -f crd-virtualservice.yaml

在CRD创建成功后，由于本例的scope设置了Namespace限定，所以可以通过API Endpoint“/apis/networking.istio.io/v1alpha3/namespaces/<namespace>/virtualservices/”管理该CRD资源。

用户接下来就可以基于该CRD的定义创建相应的自定义资源对象了。

2.基于CRD的定义创建自定义资源对象

基于CRD的定义，用户可以像创建Kubernetes系统内置的资源对象（如Pod）一样创建CRD资源对象。在下面的例子中，virtualservice-helloworld.yaml定义了一个类型为VirtualService的资源对象：

apiVersion: networking.istio.io/vlalpha3
kind: VirtualService
metadata:
  name: helloworld
spec:
  hosts:
  - "*"
  gateways:
  - helloworld-gateway
  http:
  - match:
  - uri:
      exact: /hello
  route:
  - destination:
      host: helloworld
      port:
        number: 5000

除了需要设置该CRD资源对象的名称，还需要在spec段设置相应的参数。在spec中可以设置的字段是由CRD开发者自定义的，需要根据CRD开发者提供的手册进行配置。这些参数通常包含特定的业务含义，由CRD控制器进行处理。

使用kubectl create命令完成CRD资源对象的创建：

kubectl create -f virtualservice-helloworld.yaml

然后，用户就可以像操作Kubernetes内置的资源对象（如Pod、RC、Service）一样去操作CRD资源对象了，包括查看、更新、删除和watch等操作。

查看CRD资源对象：

kubectl get virtualservice

也可以通过CRD所属的categories进行查询：

kubectl  get istio-io
kubectl get networking-istio-io

3.CRD的高级特性

随着Kubernetes的演进，CRD也在逐步添加一些高级特性和功能，包括subresources子资源、校验（Validation）机制、自定义查看CRD时需要显示的列，以及finalizer预删除钩子。

（1）CRD的subresources子资源

Kubernetes从1.11版本开始，在CRD的定义中引入了名为subresources的配置，可以设置的选项包括status和scale两类。

◎ stcatus：启用/status路径，其值来自CRD的.status字段，要求CRD控制器能够设置和更新这个字段的值。

◎ scale：启用/scale路径，支持通过其他Kubernetes控制器（如HorizontalPodAutoscaler控制器）与CRD资源对象实例进行交互。用户通过kubectl scale命令也能对该CRD资源对象进行扩容或缩容操作，要求CRD本身支持以多个副本的形式运行。

下面是一个设置了subresources的CRD示例：

apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: crontabs.stable.example.com
spec:
  group: stable.example.com
  versions:
  - name: v1
    served: true
    storage: true
  scope: Namespaced
  names:
    plural: crontabs
    singular: crontab
    kind: CronTab
    shortNames:
    - ct
  subresources:
    status: {}
    scale:
      specReplicasPath: .spec.replicas
      statusReplicasPath: .status.replicas
      labelSelectorPath: .status.labelSelector

基于该CRD的定义，创建一个自定义资源对象my-crontab.yaml：

apiVersion: "stable.example.com/v1"
kind: CronTab
metadata:
  name: my-new-cron-object
spec:
  cronSpec: "* * * * */5"
  image: my-awesome-cron-image
  replicas: 3

之后就能通过API Endpoint查看该资源对象的状态了：

/apis/stable.example.com/v1/namespaces/<namespace>/contabs/status

并查看该资源对象的扩缩容（scale）信息：

/apis/stable.example/com/v1/namespaces/<namespace>/contabs/scale

用户还可以使用kubectl scale命令对Pod的副本数量进行调整，例如：

kubectl scale --replicas=5 cibtavs/my-new-cron-object

（2）CRD的校验（Validation）机制

Kubernetes从1.8版本开始引入了基于OpenAPI v3 schema或validatingadmissionwebhook的校验机制，用于校验用户提交的CRD资源对象配置是否符合预定义的校验规则。该机制到Kubernetes 1.13版本时升级为Beta版。要使用该功能，需要为kube-apiserver服务开启--feature-gates=CustomResourceValidation=true特性开关。

下面的例子为CRD定义中的两个字段（cronSpec和replicas）设置了校验规则：

apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: crontabs.stable.example.com
spec:
  group: stable.example.com
  versions:
  - name: v1
    served: true
    storage: true
  version: v1
  scope: Namespaced
  names:
    plural: crontabs
    singular: crontab
    kind: CronTab
    shortNames:
    - ct
  validation:
    openAPIV3Schema:
      properties:
        spec:
          properties:
            cronSpec:
              type: string
              pattern: '^(\d+|\*)(/\d+)?(\s+(\d+|\*)(/\d+)?){4}$'
            replicas:
              type: integer
              minimum: 1
              maximum: 10

校验规则如下。
◎　spec.cronSpec：必须为字符串类型，并且满足正则表达式的格式。
◎　spec.replicas：必须将其设置为1～10的整数。

对于不符合要求的CRD资源对象定义，系统将拒绝创建。

如，下面的my-crontab.yaml示例违反了CRD中validation设置的校验规则，即cronSpec没有满足正则表达式的格式，replicas的值大于10：

apiVersion: "stable.example.com/v1"
kind: CronTab
metadata:
  name: my-new-cron-object
spec:
  cronSpec: "* * * *"
  image: my-awesome-cron-image
  replicas: 15

创建时，系统将报出validation失败的错误信息。

（3）自定义查看CRD时需要显示的列

从Kubernetes 1.11版本开始，通过kubectl get命令能够显示哪些字段由服务端（API Server）决定，还支持在CRD中设置需要在查看（get）时显示的自定义列，在spec.additionalPrinterColumns字段设置即可。

在下面的例子中设置了3个需要显示的自定义列Spec、Replicas和Age，并在JSONPath字段设置了自定义列的数据来源：

apiVersion: apiextensions.k8s.io/v1beta1
  kind: CustomResourceDefinition
  metadata:
    name: crontabs.stable.example.com
  spec:
    group: stable.example.com
    version: v1
    scope: Namespaced
    names:
      plural: crontabs
      singular: crontab
      kind: CronTab
      shortNames:
      - ct
    additionalPrinterColumns:
    - name: Spec
      type: string
      description: The cron spec defining the interval a CronJob is run
      JSONPath: .spec.cronSpec
    - name: Replicas
      type: integer
      description: The number of jobs launched by the CronJob
      JSONPath: .spec.replicas
    - name: Age
      type: date
      JSONPath: .metadata.creationTimestamp

通过kubectl get命令查看CronTab资源对象，会显示出这3个自定义的列。

（4）Finalizer（CRD资源对象的预删除钩子方法）
         Finalizer设置的方法在删除CRD资源对象时进行调用，以实现CRD资源对象的清理工作。
         在下面的例子中为CRD“CronTab”设置了一个finalizer（也可以设置多个），其值为URL“finalizer.stable.example.com”：

apiVersion: "stable.example.com/v1"
kind: CronTab
metadata:
  finalizers:
  - finalizer.stable.example.com

在用户发起删除该资源对象的请求时，Kubernetes不会直接删除这个资源对象，而是在元数据部分设置时间戳“metadata.deletionTimestamp”的值，标记为开始删除该CRD对象。然后控制器开始执行finalizer定义的钩子方法“finalizer.stable.example.com”进行清理工作。对于耗时较长的清理操作，还可以设置metadata.deletionGracePeriodSeconds超时时间，在超过这个时间后由系统强制终止钩子方法的执行。在控制器执行完钩子方法后，控制器应负责删除相应的finalizer。当全部finalizer都触发控制器执行钩子方法并都被

CRD极大扩展了Kubernetes的能力，使用户像操作Pod一样操作自定义的各种资源对象。CRD已经在一些基于Kubernetes的第三方开源项目中得到广泛应用，包括CSI存储插件、Device Plugin（GPU驱动程序）、Istio（Service Mesh管理）等，已经逐渐成为扩展Kubernetes能力的标准。

小结：

           本节内容到此结束，谢谢大家的浏览！

 

坚持的道路注定孤独
关注
专栏目录
通过ftp在Centos6和Centos7上搭建yum仓库
yonggeit的博客
04-20 3534
yum网络仓库的搭建　CentOＳ7yum -y install vsftpd systemctl start vsftpd [318][root@liyong: yum.repos.d]# systemctl enable vsftpdiptables -F systemctl stop firewalld.service systemctl disable firewalld.service r
linux下home目录迁移
yonggeit的博客
04-26 5251
根分区预留不宽裕,du -sh /home 发现home分区占比较大,于是将home目录迁移到新的分区#添加硬盘后触发扫描 echo '- - -' > /sys/class/scsi_host/host2/scan [389][root@liyong: etc]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda
Kubernetes API 基础
期待幸福
05-16 1561
APIServer 在kubernetes架构概念层面上，Kubernetes由一些具有不同角色的服务节点组成。而master的控制平面由 Apiserver Controller-manager 和 Scheduler 组成。 Apiserver 从概念上理解可以分为 api 和 object 的集合，api 可以理解为，处理读写请求来修改相应 object 的组件；而 object 可以表示为 kubernetes 对象，如 Pod， Deployment 等 。 基于声明式的API 在命令式 API
Kubernetes API模型(二)
任我行的博客
05-19 428
文章目录1.介绍2.API对象2.1 版本2.2 API路径3.API请求处理 1.介绍 kubernetes中最核心的就是kube-apivserver组件，其他组件都还是和kube-apiserver进行通信的，本节主要来研究kubernetes API接口的模型。 2.API对象 在kubernetes集群中，kubernetes对象是我们持久化的实体，就是最终要存入etcd数据，集群中通过这些实体来表示整个群体的状态。平时我们都是直接编写YAML资源清单文件，然后通过kubectl来提交创建对应的资
Kubernetes 客户端库 Client-Go 教程
最新发布
gitblog_00850的博客
08-08 851
Kubernetes 客户端库 Client-Go 教程 client-goGo client for Kubernetes.项目地址:https://gitcode.com/gh_mirrors/cl/client-go 1. 项目介绍 Kubernetes Client-Go 是一个用于开发 Kubernetes 应用程序的官方 Go 语言客户端库。它提供了与 Kubernetes 集群通信...
Kubernetes 了解声明式 API
爱死亡机器人
11-26 1547
Kubernetes API概述 Kubernetes API是集群系统中的重要组成部分，Kubernetes中各种资源（对象）的数据都通过该API接口被提交到后端的持久化存储（etcd）中，Kubernetes集群中的各部件之间通过该API接口实现解耦合，同时Kubernetes集群中一个重要且便捷的管理工具kubectl也是通过访问该API接口实现其强大的管理功能的。Kubernetes API中的资源对象都拥有通用的元数据，资源对象也可能存在嵌套现象，比如在一个Pod里面嵌套多个Container。创
Ingress 资源与 networking.k8s.io/v1 问题
weixin_48505120的博客
10-14 4712
官方文档：https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/、https://kubernetes.io/blog/2021/07/26/update-with-ingress-nginx/ 和。这个v1beta1 版本中来，至于什么时候开始这个 networking.k8s.io/v1beta1 这个beta版本变成了稳定版本，可以看。版本下， 我们ingress 的yaml 里，有些。, e.g ，下面我们需要修改我们的。
企业运维实战之k8s（k8s网络通信）初学者必看，点赞关注后期不迷路
Puuwuuchao的博客
07-29 881
文章目录IPVS模式的service IPVS模式的service 网络 vim ext-ip.yaml apiVersion: v1 kind: Service metadata: name: ex-service spec: selector: app: myapp ports: - name: http protocol: TCP port: 80 targetPort: 80 externalIPs: - 172.25.21
《Kubernetes Operator 开发进阶》- 作者絮絮叨
farmer_hutao的博客
01-05 1435
Kubernetes Operator 开发进阶》终于和读者朋友们见面了！ 本书介绍？送书活动？你想知道的都在这篇文章里！
遇见OFFER，阿里云最强技术团队现身招聘，“职”为你来
热门推荐
遇见OFFER
05-28 6万+
最近还在找工作吗？我们又来放送招聘信息啦！快来看看吧~
shell实例手册
yonggeit的博客
05-27 6010
shell实例手册 1文件{ touch file # 创建空白文件 rm -rf 目录名 # 不提示删除非空目录(-r:递归删除 -f强制) dos2unix # windows文本转linux文本 unix2dos # linux文本转windows文本 enca filename ...
json-merge-patch:JSON 合并补丁 (RFC 7396) 的实现
07-23
JSON 合并补丁 JSON 合并补丁 JSON 合并补丁是一种标准格式，允许您通过发送更改而不是整个文档来更新 JSON 文档。 JSON Merge Patch 与 HTTP PATCH 动词（方法）和 REST 风格的编程配合得很好。 安装 安装当前版本（并将其保存为依赖项）： 新产品经理 $ npm install json-merge-patch --save 用法 应用补丁： jsonmergepatch . apply ( obj : Object , patch : Object ) : Object 将patch应用到源obj 。 例子： var source = { "title" : "Goodbye!" , "author" : { "givenName" : "John" , "familyName" : "Doe" } } ; va
k8s 网络策略
qq_39124041的博客
02-13 569
支持基于calico的网络策略 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: test-network-policy namespace: default spec: podSelector: matchLabels: #该参数为空则保护当前命名空间下所有pod role: db policyTypes: - Ingress #其它客户端进入流量 - Egress
K8S 网络策略
elihe2011的专栏
03-15 1708
1. 网络策略 NetworkPolicy 是一种以应用为中心的结构，允许你设置如何允许 Pod 与网络上的各类网络 “实体” 通信，在 IP/Port (L3/L4) 层面控制网络流量，用于隔离应用以减少攻击面。 Pod 之间能否通信，可通过如下三个组合进行确认： 其他被允许的 Pods (例如：Pod 无法限制对自身的访问) 被允许的 namespace IP CIDR (例如：与Pod运行所在节点的节点的通信总是被允许的) 支持的网络插件： Calico Canal Cilium Kube-ro
【云原生】容器服务（K8s版）使用 Kubectl 部署 web 服务到 K8s 集群
write less , do more
07-04 4521
首先，我们需要将业务应用部署到 k8s 集群中。这里我们已经准备好了一个应用并打包成镜像，镜像地址如下： registry.cn-shanghai.aliyuncs.com/workbench_1459088147016887/handson_ack_test:3 这是一个使用 spring boot 开发的 java web 应用。这个应用会监听 8080 端口，接受所有路径的访问，并输出一些环境基本信息。 要让这个 web 应用的镜像在 k8s 中运行，我们首先要定义一个 deployment 资源。
3. 详解 kubectl patch 命令 – strategic、json 和 merge 区别
极客神殿
06-10 1556
的选项，我挑几个比较高频的选项进行讲解，其他的我暂时没有使用过，后续再研究。的值如下，有变更的字段发生进行更新，没有变化的字段则进行合并，并不会删除。参数，跟的应当是一个 json 列表，该列表里的每个对象，都应是如下结构。也是我在写某控制器时，偶尔发现的，应该只有使用。对象的更新的部分字段，而不用指定全量的字段。，有相同的字段就替换，没有相同的字段就合并。，检查一些格式的检查，并不会真正地提交到。的结果，有时候还是不一样的，建议使用。，翻译过来是策略合并，是默认的选项。比较特殊，会包含波浪线和斜杠，当。
K8s Restful patch请求content-type相关设置
二月依依的博客
06-11 2386
API 资源使用REST模式，具体说明如下。 GET /<资源名的复数格式>：获得某一类型的资源列表，例如GET /pods 返回一个Pod资源列表。 POST /<资源名的复数格式>：创建一个资源，该资源来自用户提供的JSON对象。 GET /<资源名复数格式>/<名字>：通过给出的名称（Name）获得单个资源，例如GET...
课时 23：Kubernetes API 编程范式（陈显鹭）
阿里巴巴云原生的博客
10-28 316
本文将主要分享以下四个方面的内容： 需求来源 用例解读 操作演示 架构设计 需求来源 首先我们先来看一下 API 编程范式的需求来源。 在 Kubernetes 里面， API 编程范式也就是 Custom Resources Definition（CRD）。我们常讲的 CRD，其实指的就是用户自定义资源。 为什么会有用户自定义资源问题呢？ 随着 Kubernetes 使用的越来越多，用户自定...
部署应用报错no matches for kind “Ingress“ in version “networking.k8s.io/v1beta1“
qq_45034687的博客
03-29 1631
应用部署错误no matches for kind “Ingress“ in version “networking.k8s.io/v1beta1“
K8S 1.18.6对应的kubernetes-cni插件版本
06-03
Kubernetes版本和CNI插件版本之间的对应关系可以参考Kubernetes官方文档中的CNI插件支持矩阵。根据文档中的描述，Kubernetes 1.18.6版本建议使用如下版本的CNI插件： - CNI插件版本：v0.8.6 - CNI-IPAM插件版本：v...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值