kubernetes 简介：API Server 简介

最新推荐文章于 2024-09-06 03:15:34 发布
最新推荐文章于 2024-09-06 03:15:34 发布
阅读量1.6w 收藏 7
点赞数 2
分类专栏： kubernetes 文章标签： kubernetes kube-apiserver

http://cizixs.com/2016/11/07/kubernetes-intro-api-server

简介

这篇文章是整个系统的第二篇，上一篇文章讲解了 kubelet 的功能和使用。

在 kubernetes 集群中，API Server 有着非常重要的角色。API Server 负责和 etcd 交互（其他组件不会直接操作 etcd，只有 API Server 这么做），是整个 kubernetes 集群的数据中心，所有的交互都是以 API Server 为核心的。简单来说，API Server 提供了一下的功能：

  • 整个集群管理的 API 接口：所有对集群进行的查询和管理都要通过 API 来进行
  • 集群内部各个模块之间通信的枢纽：所有模块之前并不会之间互相调用，而是通过和 API Server 打交道来完成自己那部分的工作
  • 集群安全控制：API Server 提供的验证和授权保证了整个集群的安全

在这篇教程中，我们的系统架构将变成下面这个样子：

我们把要配置的 pod 通过 kubectl 发送给 API Server，里面已经手动指定了要运行的节点。API Server 解析并保存对应的资源，对应的 kubelet 定时拉取数据时候发现 pod 是分配给自己的，会下载对应的配置并执行去生成 pod。

参数介绍

API Server 主要是和 etcd 打交道，并且对外提供 HTTP 服务，以及进行安全控制，因此它的命令行提供的参数也主要和这几个方面有关。下面是一些比较重要的参数以及说明（不同版本参数可能会有不同）：

参数含义默认值
–advertise-address通过该 ip 地址向集群其他节点公布 api server 的信息，必须能够被其他节点访问nil
–allow-privileged是否允许 privileged 容器运行false
–admission-control准入控制AlwaysAdmit
–authorization-mode授权模式 ，安全接口上的授权AlwaysAllow
–bind-addressHTTPS 安全接口的监听地址0.0.0.0
–secure-portHTTPS 安全接口的监听端口6443
–cert-dirTLS 证书的存放目录/var/run/kubernetes
–etcd-prefix信息存放在 etcd 中地址的前缀“/registry”
–etcd-servers逗号分割的 etcd server 地址[]
–insecure-bind-addressHTTP 访问的地址127.0.0.1
–insecure-portHTTP 访问的端口8080
–log-dir日志存放的目录 
–service-cluster-ip-rangeservice 要使用的网段，使用 CIDR 格式，参考 kubernetes 中 service 的定义 

安装和运行

API Server 是通过提供的 kube-apiserver 二进制文件直接运行的，下面的例子指定了 service 分配的 ip 范围，etcd 的地址，和对外提供服务的 ip 地址：

/usr/bin/kube-apiserver \
        --service-cluster-ip-range=10.20.0.1/24 \
        --etcd-servers=http://127.0.0.1:2379 \
        --advertise-address=192.168.8.100 \
        --bind-address=192.168.8.100 \
        --insecure-bind-address=192.168.8.100 \
        --v=4

这篇教程不会提供对 API Server 进行 HTTPS 的配置，所有的操作都是直接通过 8080 非安全端口访问的。

直接访问 8080 端口，API Server 会返回它提供了哪些接口：

[root@localhost vagrant]# curl http://192.168.8.100:8080                                                                                                                                 
{
  "paths": [
    "/api",
    "/api/v1",
    "/apis",
    "/apis/apps",
    "/apis/apps/v1alpha1",
    "/apis/autoscaling",
    "/apis/autoscaling/v1",
    "/apis/batch",
    "/apis/batch/v1",
    "/apis/batch/v2alpha1",
    "/apis/extensions",
    "/apis/extensions/v1beta1",
    "/apis/policy",
    "/apis/policy/v1alpha1",
    "/apis/rbac.authorization.k8s.io",
    "/apis/rbac.authorization.k8s.io/v1alpha1",
    "/healthz",
    "/healthz/ping",
    "/logs/",
    "/metrics",
    "/swaggerapi/",
    "/ui/",
    "/version"
  ]
}

而目前最重要的路径是 /api/v1，里面包含了 kubernetes 所有资源的操作，比如下面的 nodes：

➜  ~ http http://192.168.8.100:8080/api/v1/nodes
HTTP/1.1 200 OK
Content-Length: 112
Content-Type: application/json
Date: Thu, 08 Sep 2016 08:14:45 GMT

{
    "apiVersion": "v1",
    "items": [],
    "kind": "NodeList",
    "metadata": {
        "resourceVersion": "12",
        "selfLink": "/api/v1/nodes"
    }
}

API 以 json 的形式返回，会通过 apiVersion 来说明 API 版本号，kind 说明请求的是什么资源。不过这里面的内容是空的，因为目前还没有任何 kubelet 节点接入到我们的 API Server。对应的，pod 也是空的：

➜  ~ http http://192.168.8.100:8080/api/v1/pods
HTTP/1.1 200 OK
Content-Length: 110
Content-Type: application/json
Date: Thu, 08 Sep 2016 08:18:53 GMT

{
    "apiVersion": "v1",
    "items": [],
    "kind": "PodList",
    "metadata": {
        "resourceVersion": "12",
        "selfLink": "/api/v1/pods"
    }
}

添加节点

添加节点也非常简单，启动　kubelet　的时候使用　--api-servers　指定要接入的　API Server 就行。kubelet 启动之后，会把自己注册到指定的 API Server，然后监听 API 对应 pod 的变化，根据 API 中 pod 的实际信息来管理节点上 pod 的生命周期。

现在访问 /api/v1/nodes 就能看到已经添加进来的节点：

➜  ~ http http://192.168.8.100:8080/api/v1/nodes
HTTP/1.1 200 OK
Content-Type: application/json
Date: Thu, 08 Sep 2016 08:27:44 GMT
Transfer-Encoding: chunked

{
    "apiVersion": "v1",
    "items": [
        {
            "metadata": {
                "annotations": {
                    "volumes.kubernetes.io/controller-managed-attach-detach": "true"
                },
                "creationTimestamp": "2016-09-08T08:23:01Z",
                "labels": {
                    "beta.kubernetes.io/arch": "amd64",
                    "beta.kubernetes.io/os": "linux",
                    "kubernetes.io/hostname": "192.168.8.100"
                },
                "name": "192.168.8.100",
                "resourceVersion": "65",
                "selfLink": "/api/v1/nodes/192.168.8.100",
                "uid": "74e16eba-759d-11e6-b463-080027c09e5b"
            },
            "spec": {
                "externalID": "192.168.8.100"
            },
            "status": {
                "addresses": [
                    {
                        "address": "192.168.8.100",
                        "type": "LegacyHostIP"
                    },
                    {
                        "address": "192.168.8.100",
                        "type": "InternalIP"
                    }
                ],
                "allocatable": {
                    "alpha.kubernetes.io/nvidia-gpu": "0",
                    "cpu": "1",
                    "memory": "502164Ki",
                    "pods": "110"
                },
                "capacity": {
                    "alpha.kubernetes.io/nvidia-gpu": "0",
                    "cpu": "1",
                    "memory": "502164Ki",
                    "pods": "110"
                },
                "conditions": [
                    {
                        "lastHeartbeatTime": "2016-09-08T08:27:36Z",
                        "lastTransitionTime": "2016-09-08T08:23:01Z",
                        "message": "kubelet has sufficient disk space available",
                        "reason": "KubeletHasSufficientDisk",
                        "status": "False",
                        "type": "OutOfDisk"
                    },
                    {
                        "lastHeartbeatTime": "2016-09-08T08:27:36Z",
                        "lastTransitionTime": "2016-09-08T08:23:01Z",
                        "message": "kubelet has sufficient memory available",
                        "reason": "KubeletHasSufficientMemory",
                        "status": "False",
                        "type": "MemoryPressure"
                    },
                    {
                        "lastHeartbeatTime": "2016-09-08T08:27:36Z",
                        "lastTransitionTime": "2016-09-08T08:24:56Z",
                        "message": "kubelet is posting ready status",
                        "reason": "KubeletReady",
                        "status": "True",
                        "type": "Ready"
                    }
                ],
                "daemonEndpoints": {
                    "kubeletEndpoint": {
                        "Port": 10250
                    }
                },
                "images": [
                    {
                        "names": [
                            "172.16.1.41:5000/nginx:latest"
                        ],
                        "sizeBytes": 425626718
                    },
                    {
                        "names": [
                            "172.16.1.41:5000/hyperkube:v0.18.2"
                        ],
                        "sizeBytes": 207121551
                    },
                    {
                        "names": [
                            "172.16.1.41:5000/etcd:v3.0.4"
                        ],
                        "sizeBytes": 43302056
                    },
                    {
                        "names": [
                            "172.16.1.41:5000/busybox:latest"
                        ],
                        "sizeBytes": 1092588
                    },
                    {
                        "names": [
                            "172.16.1.41:5000/google_containers/pause:0.8.0"
                        ],
                        "sizeBytes": 241656
                    }
                ],
                "nodeInfo": {
                    "architecture": "amd64",
                    "bootID": "48955926-11dd-4ad3-8bb0-2585b1c9215d",
                    "containerRuntimeVersion": "docker://1.10.3",
                    "kernelVersion": "3.10.0-123.13.1.el7.x86_64",
                    "kubeProxyVersion": "v1.3.1-beta.0.6+fbf3f3e5292fb0",
                    "kubeletVersion": "v1.3.1-beta.0.6+fbf3f3e5292fb0",
                    "machineID": "b9597c4ae5f24494833d35e806e00b29",
                    "operatingSystem": "linux",
                    "osImage": "CentOS Linux 7 (Core)",
                    "systemUUID": "823EB67A-057E-4EFF-AE7F-A758140CD2F7"
                }
            }
        }
    ],
    "kind": "NodeList",
    "metadata": {
        "resourceVersion": "65",
        "selfLink": "/api/v1/nodes"
    }
}

我们可以看到，kubelet 收集了很多关于自身节点的信息，这些信息也会不断更新。这些信息里面不仅包含节点的系统信息（系统架构，操作系统版本，内核版本等）、还有镜像信息（节点上有哪些已经下载的 docker 镜像）、资源信息（Memory 和 Disk 的总量和可用量）、以及状态信息（是否正常，可以分配 pod等）。

和 API Server 通信

下面我们就通过 API Server 来创建 pod，而不是像上篇文章那样用拷贝文件的方式。我们把编写的 yaml 文件转换成 json 格式，保存到文件里。主要注意的是，我们指定了 nodeName 的名字，这个名字必须和之前通过 /api/v1/nodes 得到的结果中 metadata.labels.kubernetes.io/hostname 保持一致：

[root@localhost vagrant]# cat nginx_pod.yml
apiVersion: v1
kind: Pod
metadata:
  name: nginx-server
spec:
  nodeName: 192.168.8.100
  containers:
  - name: nginx-server
    image: 172.16.1.41:5000/nginx
    ports:
    - containerPort: 80
    volumeMounts:
    - mountPath: /var/log/nginx
      name: nginx-logs
  - name: log-output
    image: 172.16.1.41:5000/busybox
    command:
    - bin/sh
    args: [-c, 'tail -f /logdir/access.log']
    volumeMounts:
    - mountPath: /logdir
      name: nginx-logs
  volumes:
  - name: nginx-logs
    emptyDir: {}

使用 curl 执行 POST 请求，设置头部内容为 application/json，传过去文件中的 json 值，可以看到应答(其中 status 为 pending，表示以及接收到请求，正在准备处理)：

# curl -s -X POST -H "Content-Type: application/json" http://192.168.8.100:8080/api/v1/namespaces/default/pods --data @nginx_pod.json                           
{
  "kind": "Pod",
  "apiVersion": "v1",
  "metadata": {
    "name": "nginx-server",
    "namespace": "default",
    "selfLink": "/api/v1/namespaces/default/pods/nginx-server",
    "uid": "888e95d0-75a9-11e6-b463-080027c09e5b",
    "resourceVersion": "573",
    "creationTimestamp": "2016-09-08T09:49:28Z"
  },
  "spec": {
    "volumes": [
      {
        "name": "nginx-logs",
        "emptyDir": {}
      }
    ],
    "containers": [
      {
        "name": "nginx-server",
        "image": "172.16.1.41:5000/nginx",
        "ports": [
          {
            "containerPort": 80,
            "protocol": "TCP"
          }
        ],
        "resources": {},
        "volumeMounts": [
          {
            "name": "nginx-logs",
            "mountPath": "/var/log/nginx"
          }
        ],
        "terminationMessagePath": "/dev/termination-log",
        "imagePullPolicy": "Always"
      }
    ],
    "restartPolicy": "Always",
    "terminationGracePeriodSeconds": 30,
    "dnsPolicy": "ClusterFirst",
    "nodeName": "192.168.8.100",
    "securityContext": {}
  },
  "status": {
    "phase": "Pending"
  }
}

返回中包含了我们提交 pod 的信息，并且添加了 status、metadata 等额外信息。

等一段时间去查询 pod，就可以看到 pod 的状态已经更新了：

➜  http http://192.168.8.100:8080/api/v1/namespaces/default/pods
HTTP/1.1 200 OK
Content-Type: application/json
Date: Thu, 08 Sep 2016 09:51:29 GMT
Transfer-Encoding: chunked

{
    "apiVersion": "v1",
    "items": [
        {
            "metadata": {
                "creationTimestamp": "2016-09-08T09:49:28Z",
                "name": "nginx-server",
                "namespace": "default",
                "resourceVersion": "592",
                "selfLink": "/api/v1/namespaces/default/pods/nginx-server",
                "uid": "888e95d0-75a9-11e6-b463-080027c09e5b"
            },
            "spec": {
                "containers": [
                    {
                        "image": "172.16.1.41:5000/nginx",
                        "imagePullPolicy": "Always",
                        "name": "nginx-server",
                        "ports": [
                            {
                                "containerPort": 80,
                                "protocol": "TCP"
                            }
                        ],
                        "resources": {},
                        "terminationMessagePath": "/dev/termination-log",
                        "volumeMounts": [
                            {
                                "mountPath": "/var/log/nginx",
                                "name": "nginx-logs"
                            }
                        ]
                    },
                    {
                        "args": [
                            "-c",
                            "tail -f /logdir/access.log"
                        ],
                        "command": [
                            "bin/sh"
                        ],
                        "image": "172.16.1.41:5000/busybox",
                        "imagePullPolicy": "Always",
                        "name": "log-output",
                        "resources": {},
                        "terminationMessagePath": "/dev/termination-log",
                        "volumeMounts": [
                            {
                                "mountPath": "/logdir",
                                "name": "nginx-logs"
                            }
                        ]
                    }
                ],
                "dnsPolicy": "ClusterFirst",
                "nodeName": "192.168.8.100",
                "restartPolicy": "Always",
                "securityContext": {},
                "terminationGracePeriodSeconds": 30,
                "volumes": [
                    {
                        "emptyDir": {},
                        "name": "nginx-logs"
                    }
                ]
            },
            "status": {
                "conditions": [
                    {
                        "lastProbeTime": null,
                        "lastTransitionTime": "2016-09-08T09:49:28Z",
                        "status": "True",
                        "type": "Initialized"
                    },
                    {
                        "lastProbeTime": null,
                        "lastTransitionTime": "2016-09-08T09:49:44Z",
                        "status": "True",
                        "type": "Ready"
                    },
                    {
                        "lastProbeTime": null,
                        "lastTransitionTime": "2016-09-08T09:49:44Z",
                        "status": "True",
                        "type": "PodScheduled"
                    }
                ],
                "containerStatuses": [
                    {
                        "containerID": "docker://8b79eeea60f27b6d3f0a19cbd1b3ee3f83709bcf56574a6e1124c69a6376972d",
                        "image": "172.16.1.41:5000/busybox",
                        "imageID": "docker://sha256:8c566faa3abdaebc33d40c1b5e566374c975d17754c69370f78c00c162c1e075",
                        "lastState": {},
                        "name": "log-output",
                        "ready": true,
                        "restartCount": 0,
                        "state": {
                            "running": {
                                "startedAt": "2016-09-08T09:49:43Z"
                            }
                        }
                    },
                    {
                        "containerID": "docker://96e64cdba7b05d4e30710a20e958ff5b8f1f359c8d16d32622b36f0df0cb353c",
                        "image": "172.16.1.41:5000/nginx",
                        "imageID": "docker://sha256:51d764c1fd358ce81fd0e728436bd0175ff1f3fd85fc5d1a2f9ba3e7dc6bbaf6",
                        "lastState": {},
                        "name": "nginx-server",
                        "ready": true,
                        "restartCount": 0,
                        "state": {
                            "running": {
                                "startedAt": "2016-09-08T09:49:36Z"
                            }
                        }
                    }
                ],
                "hostIP": "192.168.8.100",
                "phase": "Running",
                "podIP": "172.17.0.2",
                "startTime": "2016-09-08T09:49:28Z"
            }
        }
    ],
    "kind": "PodList",
    "metadata": {
        "resourceVersion": "602",
        "selfLink": "/api/v1/namespaces/default/pods"
    }
}

可以看到 pod 已经在运行，并且给分配了 ip：172.17.0.2，通过 curl 也可以访问它的服务：

[root@localhost vagrant]# curl -s http://172.17.0.2 | head -n 5
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx on Debian!</title>
<style>

关于 API Server 提供的所有接口，可以参考官方的 [API 文档][http://kamalmarhubi.com/blog/2015/09/06/kubernetes-from-the-ground-up-the-api-server/]。

kubectl 命令

理论上，所有 kubernetes 提供的功能都能够直接通过 HTTP API 交互来实现，但是你也看到了，非常复杂。因此 kubernetes 提供了另外了 kubectl 命令行，它封装了 HTTP API 的交互过程，通过一系列的子命令来操作资源。比如我们上面创建 pod 的过程就可以通过

kubectl create -f nginx_pod.yml

一行命令实现，查看 pod 的信息也很简单：

kubectl -s http://ip:8080 get pods

删除已经创建的 pod，可以使用 delete 命令：

kubectl delete pods/nginx-server

kubectl 的用法也有详细的官方文档，这里就不多说了。

参考资料


liukuan73
关注
专栏目录
Kubernetes：API Server的核心角色
✨ 欢迎来到【Seal ^_^ 的CSDN博客】！这里是我记录技术心得、分享经验的地方。✨
09-06 3350
API Server提供REST API，让各组件轻松交互，确保集群稳定运行。它是Kubernetes的“大脑”，驱动集群发展。
Api-server.zip
09-18
Api-server.zip,一个简单的服务器，用于实时发送和接收每个websocket的消息。（包括一个流畅的web用户界面）gotify/server,一个api可以被认为是多个软件设备之间通信的指导手册。例如，api可用于web应用程序之间的数据库通信。通过提取实现并将数据放弃到对象中，api简化了编程。
K8s-api-server.06-2
Vv的博客
01-02 766
内容转载自：https://github.com/opsnull/follow-me-install-kubernetes-cluster/blob/master/06-2.api-server.md 上一篇：K8s-部署高可用组件.06-1 06-2.部署 kube-apiserver 组件 本文档讲解使用 keepalived 和 haproxy 部署一个 3 节点高可用 master ...
fluentd 简介，日志收集并导入BigQuery
最新发布
nvd11的专栏
09-06 1155
Fluentd 是一个开源的数据收集器，旨在实现日志数据的统一收集、处理和转发。它支持多种数据源和数据格式，并具有灵活性和可扩展性，使得在大规模分布式系统中处理日志数据变得更加容易。以下是 Fluentd 的一些关键特点和优势：多源数据收集：Fluentd 支持从各种数据源收集数据，包括日志文件、系统日志、应用程序日志、传感器数据等。数据格式转换：Fluentd 可以将不同格式的数据转换为统一的格式，使其更容易进行处理和分析。
API Server简介
u010453704的博客
12-05 1万+
API Server简介 一、API Server简介 1.1 API Server功能 k8s API Server提供了k8s各类资源对象（pod,RC,Service等）的增删改查及watch等HTTP Rest接口，是整个系统的数据总线和数据中心。 kubernetes API Server的功能： 1. 提供了集群管理的REST API接口(包括认证授权、数据校验以及集群状态变更)； 2. 提供其他模块之间的数据交互和通信的枢纽（其他模块通过API Server查询或修改数据，只.
K8s 核心组件——API Server
谦虚使人发胖的博客
07-23 2120
Kubernetes API Server（API Server）是 Kubernetes 的核心组件之一，负责暴露 Kubernetes API 给用户和客户端，接收和处理来自客户端的请求，并将其存储到 etcd 中。Kubernetes API Server 主要作用是提供 Kubernetes 各类资源对象（如 Pod、Deployment、Service等）的增、删、改、查及 Watch 等 HTTP REST 接口，是集群内各个功能模块直接数据交互和通信的中心枢纽，是整个系统的数据总线和数据中心。
[Kubernetes] API Server简介
959
04-27 1167
API Server简介
sample-apiserver:自定义Kubernetes API的apiserver的参考实现
04-29
注意：将此软件包打包或k8s.io/sample-apiserver为k8s.io/sample-apiserver 。 目的 如果要构建用于API聚合的扩展API服务器，或构建独立的Kubernetes风格的API服务器，则可以使用此代码。 但是，请考虑其他两个...
Easypack: Kubernetes 1.17.2 设定选项更新：ApiServer
知行合一 止于至善
02-01 6175
以目前最新的稳定版本1.17.2，总结更新ApiServer相关设定选项。
apiserver-builder-alpha：apiserver-builder-alpha实现了库和工具以快速轻松地构建Kubernetes apiserverscontrollers以支持基于APIServer Aggregation的自定义资源类型
02-03
除非绝对需要apiserver-aggregation，否则建议您使用而不是apiserver-builder来构建Kubernetes API。 Kubebuilder使用CRD构建API，并解决了apiserver-builder的局限性和反馈。 Apiserver Builder是使用Kubernetes ...
Kubernetes--API Server
GaoChuang_的博客
11-06 1342
一、Kubernetes API Server功能 Kubernetes API Server的核心功能是提供Kubernetes各类资源对象(如Pod、RC、Server等)的增、删、改、查及watch等HTTP REST接口，成为集群内各个功能模块之间数据交互和通信中心枢纽，是整个系统的数据总线和数据中心。除此之外，它还是集群管理的API入口，是资源配额控制的入口，提供了完备的集群安全机制。 二、Kubernetes API Server核心原理 通过curl 命令访问 API...
apiserver架构说明
09-28
项目的apiserver架构图。使用visio画的图。不够全面，后续持续更新。
api-server 源码学习
u014763610的博客
02-08 930
apiserver实现 server的实现 在apiserver/pkg/server/handler.go里的direct实现 使用go-restfule实现路由功能 所有的都是NewRESTStorage 资源创建，从main函数开始，到db层 kube-apiserver/apiserver.go里的main函数 kube-apiserver/app/server.go里的 NewAPIServerCommand函数 Run函数 CreateServerChain函数 cr
在kubernetes(k8s)集群内查看master节点api-server地址信息及服务证书key
u013659506的博客
08-30 8246
k8s集群部署后通常会用到apiserver和ca证书，供其他依赖k8s原生功能的应用调用
Kubernetes 核心组件：API Server 概念/功能
小楼一夜听春雨，深巷明朝卖杏花
07-10 2676
1. 认证2.鉴权3.准入4.限流5.API Server 对象的实现 所谓的api-server其实就是整个kubernetes集群控制面的api网关。针对于任何api网关，它都要做自我保护，第一你需要做认证，我要知道你这个请求来自哪里，鉴权我要知道一个请求有没有操作权限。任何的请求都会以一个对象，object形式发过来，发到apiserver这一端，我还要去校验你这个请求的合法性，除了我要知道你是谁，你有没有这个操作权限，还要看你的request是不是合法的，比如说你的属性设置错了，或者说需要对你的re
Kubernetes核心技术组件API Server解析
专注于数据库技术分享，包含但不限于Oracle，MySQL，PostgreSQL，ElasticSearch及国产数据库等
04-24 997
通过 API Aggregation，用户可以定义自己的资源类型（CRDs），并编写对应的控制器（Operator）来管理这些资源，从而将特定领域的知识和管理逻辑融入 Kubernetes 集群。
通过 swagger-ui 查看 kube-apiserver apis
qhh0205
07-11 1909
通过 swagger-ui 查看 kube-apiserver apis 从 k8s v1.14 开始，官方已经废弃了 swagger 接口，使用 openapi 规范，暴露出来的接口是: /openapi/v2，我们要想通过 swagger-ui 来查看 apiserver 接口，可以自己本地跑个 swagger-ui 服务，然后访问 kube-apiserver 地址的 openapi 接口地址即可，swagger-ui 来源支持 openapi 数据格式。 1.本地启动 swagger-ui 服务 d
k8s -- APIServer(主控节点)
yanghuadong的博客
02-10 773
部署kube-apiserver集群 集群规划 主机名 角色 ip HDSS1-21.host.com kube-apiserver 192.168.16.13 HDSS1-22.host.com kube-apiserver 192.168.16.14 HDSS1-11.host.com 4层负载均衡 192.168.16.11 HDSS1-12.host.com 4层负载均衡 192.168.16.12 注意：这里192.168.1.
Kubernetes核心原理（一）之API Server
热门推荐
胡伟煌的博客
07-21 1万+
1. API Server简介 k8s API Server提供了k8s各类资源对象（pod,RC,Service等）的增删改查及watch等HTTP Rest接口，是整个系统的数据总线和数据中心。 kubernetes API Server的功能： 提供了集群管理的REST API接口(包括认证授权、数据校验以及集群状态变更)；提供其他模块之间的数据交互和通信的枢纽（其他模块通
Kubernetes扩展开发：APIServer剖析与状态管理详解
- Kubernetes提供的工具链如apiserver-boot，帮助开发者快速搭建服务端和客户端。这些工具不仅简化了API的创建和管理，还提供了客户端的抽象，使得开发者能专注于业务逻辑，而不是底层细节。 5. 扩展开发实例： -...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值