k8s-api

简介

api

1
2
3

apiVersion: batch/v2alpha1
kind: CronJob
...

CronJob : 这个 API 对象的资源类型（Resource），
batch : 它的组（Group）， (Pod、Node 等，是不需要 Group 的（即：它们的 Group 是’’）)
v2alpha1 : 就是它的版本（Version）。

创建一个 /apis/batch/v2alpha1 下的 CronJob 对象。

api-cron

发起了创建 CronJob 的 POST 请求, YAML 的信息提交给 APIServer
APIServer 的第一个功能，就是过滤这个请求，并完成一些前置性的工作，(授权、超时处理、审计等)
进入 MUX 和 Routes(APIServer 完成 URL 和 Handler 绑定的场所)。找到对应的 CronJob 类型定义. 根据这个 CronJob 类型定义，使用用户提交的 YAML 文件里的字段，创建一个 CronJob 对象。(APIServer 会进行一个 Convert 工作，即：把用户提交的 YAML 文件，转换成一个叫作 Super Version 的对象(是该 API 资源类型所有版本的字段全集)。这样用户提交的不同版本的 YAML 文件，就都可以用这个 Super Version 对象来进行处理了。接下来，APIServer 会先后进行 Admission()(Admission Controller 和 Initializer，就都属于 Admission) 和 Validation()(验证是否合法) 操作。这个被验证过的 API 对象，都保存在了 APIServer 里一个叫作 Registry 的数据结构中。最后，APIServer 会把验证过的 API 对象转换成用户最初提交的版本，进行序列化操作，并调用 Etcd 的 API 把它保存起来。

Custom Resource Definition

CRD 的全称是 Custom Resource Definition。顾名思义，它指的就是，允许用户在 Kubernetes 中添加一个跟 Pod、Node 类似的、新的 API 资源类型，即：自定义 API 资源。

示例

为 Kubernetes 添加一个名叫 Network 的 API 资源类型。它的作用是，一旦用户创建一个 Network 对象，那么 Kubernetes 就应该使用这个对象定义的网络参数，调用真实的网络插件，比如 Neutron 项目，为用户创建一个真正的“网络”。这样，将来用户创建的 Pod，就可以声明使用这个“网络”了。

cr : Custom Resource, 一个具体的“自定义 API 资源”实例

cr-example-network.yaml


apiVersion: samplecrd.k8s.io/v1
kind: Network
metadata:
  name: example-network
spec:
  cidr: "192.168.0.0/16"
  gateway: "192.168.0.1"

而为了能够让 Kubernetes 认识这个 CR，需要让 Kubernetes 明白这个 CR 的宏观定义是什么，也就是 CRD（Custom Resource Definition）。

crd-example-network.yaml


apiVersion: apiextensions.k8s.io/v1beta1  # API 信息
kind: CustomResourceDefinition  # 属于 crd
metadata:
  name: networks.samplecrd.k8s.io
spec:
  group: samplecrd.k8s.io  # 组， cr 使用 samplecrd.k8s.io/v1
  version: v1
  names:
    kind: Network  # CR 的资源类型
    plural: networks  # 复数
  scope: Namespaced  # 属于 Namespace 的对象，类似于 Pod

以上 Kubernetes 就能够认识和处理所有声明了 API 类型是 samplecrd.k8s.io/v1/network 的 YAML 文件了。需要让 Kubernetes “认识”这种 YAML 文件里描述的“网络”部分，比如“cidr”（网段），“gateway”（网关）这些字段的含义.(需要写代码了)

创建出这样一个自定义 API 对象，我们只是完成了 Kubernetes 声明式 API 的一半工作。接下来的另一半工作是：为这个 API 对象编写一个自定义控制器（Custom Controller）。这样， Kubernetes 才能根据 Network API 对象的“增、删、改”操作，在真实环境中做出相应的响应。比如，“创建、删除、修改”真正的 Neutron 网络。

参考 ks8-Operator

以后详细看吧

Aggregator APIServer

eg: 部署 Metrics Server 之后，用户就可以通过标准的 Kubernetes API 来访问到监控数据了。比如，下面这个 URL：

1	curl http://127.0.0.1:8001/apis/metrics.k8s.io/v1beta1/namespaces/<namespace-name>/pods/<pod-name>

Kubernetes 的 API Server 开启了 Aggregator 模式之后，你再访问 apis/metrics.k8s.io/v1beta1 的时候，实际上访问到的是一个叫作 kube-aggregator 的代理。

Aggregator原理

kube-apiserver 正是这个代理的一个后端
Metrics Server 则是另一个后端。

kube-aggregator 其实就是一个根据 URL 选择具体的 API 后端的代理服务器

通过 API 对 deployment 增删改查

k8scluster=172.20.19.16:6443
token=$(kubectl describe secret -n kube-system $(kubectl get secrets -n kube-system |grep admin-user-token |awk ‘{print $1}’) | grep -E ‘^token’ | awk ‘{print $2}’)

nginx-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  revisionHistoryLimit: 10 
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  minReadySeconds: 5  
  updateStrategy:
    type: RollingUpdate 
    rollingUpdate:
      maxSurge: 2 
      maxUnavailable: 1 
  template: 
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

create

curl -k --header "Authorization: Bearer $token" -H 'Content-Type: application/yaml' -s -w "状态码是:%{http_code}\n" -d "$(cat test.json)" -X POST   https://${k8scluster}/apis/apps/v1/namespaces/default/deployments

get

1	curl -k --header "Authorization: Bearer $token" -H "Accept: application/json" -H 'Content-Type: application/json' -X GET https://${k8scluster}/apis/apps/v1/namespaces/default/deployments/nginx

replace

curl -k --header "Authorization: Bearer $token"   -H "Accept: application/json"  -H 'Content-Type: application/json' -s  -d "$(cat test.json)" -X PUT    https://${k8scluster}/apis/apps/v1/namespaces/default/deployments/nginx

patch

curl -k --header "Authorization: Bearer $token"   -H "Accept: application/json"  -H 'Content-Type: applicatin/strategic-merge-patch+json'  -d "$(cat test.json)" -X PATCH    https://${k8scluster}/apis/apps/v1/namespaces/default/deployments/nginx

delete

1	curl -k --header "Authorization: Bearer $token" -H "Accept: application/json" -H 'Content-Type: application/json' -X DELETE https://${k8scluster}/apis/apps/v1/namespaces/default/deployments/nginx