使用k8s的api获取服务endpoint信息

本文详细介绍了如何在Mac上通过multipass和microk8s安装Kubernetes环境,然后配置kubectl并解决镜像拉取问题。接着,展示了如何使用kubectl命令和KubernetesAPI来获取服务的endpoint信息,包括从Pod内部和外部访问API的方法。最后,文章提供了一个小结,强调了k8sAPI在获取endpoint方面的功能。

本文主要研究一下如何使用k8s的api来获取服务endpoint信息

mac m2安装k8s

安装multipass

访问https://multipass.run/install,下载安装

创建实例

multipass launch --name primary --cpus 2 --disk 20G --memory 4G

安装microk8s

sudo snap install microk8s --classic
sudo usermod -a -G microk8s $USER
sudo chown -f -R $USER ~/.kube
microk8s status --wait-ready

配置alias(~/.bash_aliases)

alias kubectl='microk8s kubectl'

查看是否ready

kubectl get node

不ready的话,大概率是pause镜像拉取不到,使用pullk8s来修正一下,稍微改动下

#!/bin/bash

check(){
  if [ "$1"x == "--microk8s"x ]
  then
    logs=`microk8s kubectl get pod --all-namespaces|tail -n +2|grep -v Running|while read line
    do
     declare -a arr=( $line )
     microk8s kubectl describe pod ${arr[1]} --namespace=${arr[0]}
    done|grep -i "image"|sed -nr 's/.*(failed to pull|Back-off pulling) image \"([^\"]+)\".*/\2/p'|uniq`
    echo ${logs}
  fi
}

pull(){
  image=$1
  imageName=${image/#registry\.k8s\.io\//}
  if [ "$image"x == "$imageName"x ]
  then
    imageName=${image/#gcr\.io\/google_containers\//}
  fi
  echo Pull $imageName ...
  if [ "$image"x == "$imageName"x ]
  then
    echo Pull $imageName ...
    docker pull $image
    exit 0
  fi
  hubimage=${imageName//\//\-}

  if [ -n ”$hubimage“ ]
  then
    echo Pull $imageName ...
    docker pull opsdockerimage/$hubimage
    docker tag opsdockerimage/$hubimage $1
    docker rmi opsdockerimage/$hubimage
    if [ "$2"x == "--microk8s"x ]
    then
      saveImage=${1#:}
      docker save $saveImage > ~/.docker_image.tmp.tar
      microk8s ctr image import ~/.docker_image.tmp.tar
      rm ~/.docker_image.tmp.tar
    fi
  fi
}

然后执行

pullk8s check --microk8s
pullk8s pull registry.k8s.io/pause:3.7 --microk8s
microk8s stop
microk8s start

示例

创建nginx

kubectl create deployment nginx --image=nginx
kubectl expose deployment nginx --port=8000 --target-port=80 --name=ngsvc
kubectl scale deployment nginx --replicas=3

使用kubectl查看

kubectl get svc
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
kubernetes   ClusterIP   10.152.183.1    <none>        443/TCP    87m
ngsvc        ClusterIP   10.152.183.50   <none>        8000/TCP   3m44s

kubectl get pods
NAME                     READY   STATUS    RESTARTS   AGE
nginx-77b4fdf86c-xbd6s   1/1     Running   0          18m
nginx-77b4fdf86c-g9gt5   1/1     Running   0          2m35s
nginx-77b4fdf86c-xq76f   1/1     Running   0          2m35s

kubectl get endpoints
NAME         ENDPOINTS                                         AGE
kubernetes   192.168.64.2:16443                                85m
ngsvc        10.1.226.133:80,10.1.226.134:80,10.1.226.135:80   64s

pod中使用api查看

kubectl get pods
kubectl exec -it nginx-77b4fdf86c-xbd6s sh


# 指向内部 API 服务器的主机名
APISERVER=https://kubernetes.default.svc

# 服务账号令牌的路径
SERVICEACCOUNT=/var/run/secrets/kubernetes.io/serviceaccount

# 读取 Pod 的名字空间
NAMESPACE=$(cat ${SERVICEACCOUNT}/namespace)

# 读取服务账号的持有者令牌
TOKEN=$(cat ${SERVICEACCOUNT}/token)

# 引用内部证书机构(CA)
CACERT=${SERVICEACCOUNT}/ca.crt

# 使用令牌访问 API
curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/api/v1/namespaces/default/endpoints/ngsvc

返回如下:


{
  "kind": "Endpoints",
  "apiVersion": "v1",
  "metadata": {
    "name": "ngsvc",
    "namespace": "default",
    "uid": "bccd1acd-a8e2-419f-925e-8ae324bf2e8b",
    "resourceVersion": "5344",
    "creationTimestamp": "2023-07-22T05:57:24Z",
    "labels": {
      "app": "nginx"
    },
    "annotations": {
      "endpoints.kubernetes.io/last-change-trigger-time": "2023-07-22T05:58:26Z"
    },
    "managedFields": [
      {
        "manager": "kubelite",
        "operation": "Update",
        "apiVersion": "v1",
        "time": "2023-07-22T05:58:26Z",
        "fieldsType": "FieldsV1",
        "fieldsV1": {
          "f:metadata": {
            "f:annotations": {
              ".": {},
              "f:endpoints.kubernetes.io/last-change-trigger-time": {}
            },
            "f:labels": {
              ".": {},
              "f:app": {}
            }
          },
          "f:subsets": {}
        }
      }
    ]
  },
  "subsets": [
    {
      "addresses": [
        {
          "ip": "10.1.226.133",
          "nodeName": "primary",
          "targetRef": {
            "kind": "Pod",
            "namespace": "default",
            "name": "nginx-77b4fdf86c-xbd6s",
            "uid": "ebc83b51-a438-40a8-b543-17a14d98a267"
          }
        },
        {
          "ip": "10.1.226.134",
          "nodeName": "primary",
          "targetRef": {
            "kind": "Pod",
            "namespace": "default",
            "name": "nginx-77b4fdf86c-g9gt5",
            "uid": "956cda5b-1724-49f3-9bc6-96c523c3c946"
          }
        },
        {
          "ip": "10.1.226.135",
          "nodeName": "primary",
          "targetRef": {
            "kind": "Pod",
            "namespace": "default",
            "name": "nginx-77b4fdf86c-xq76f",
            "uid": "731f4544-2ccc-46c0-aeb6-610bd2a4fdf8"
          }
        }
      ],
      "ports": [
        {
          "port": 80,
          "protocol": "TCP"
        }
      ]
    }
  ]
}

容器外访问

获取api地址

kubectl get endpoints kubernetes
NAME         ENDPOINTS            AGE
kubernetes   192.168.64.2:16443   108m

查看token

/var/snap/microk8s/current/credentials/known_tokens.csv

获取admin的token

访问

curl -k --header "Authorization: Bearer ${token}" -X GET https://192.168.64.2:16443/api/v1/namespaces/default/endpoints/ngsvc

将上一步获取的token替换${token}即可

小结

k8s的api提供了获取endpoint的接口,可以根据service来获取对应pod的列表

doc

<think>嗯,用户现在想要详细了解KubernetesAPI,我之前已经回答过他们关于孤立删除的问题,现在需要继续提供深入的信息。首先,我需要回忆一下Kubernetes API的基础知识,确保覆盖所有关键点。用户可能是刚开始学习K8s,或者需要更深入的理解来解决问题,比如开发自定义控制器或Operator。 Kubernetes API的核心是声明式架构,用户通过API对象描述集群的期望状态,然后系统负责协调实际状态。API的结构应该从资源类型、API版本、HTTP RESTful接口开始介绍。需要提到API组,比如核心组(v1)和其他分组如apps/v1,这样用户能理解不同资源的归属。 接下来,API的HTTP路径可能需要详细说明,比如如何构造URL来访问不同的资源,包括命名空间资源和非命名空间资源。这部分对于开发者直接调用API很有帮助。 API请求处理流程也是一个重点,包括认证、鉴权、准入控制等步骤,这些步骤确保请求的安全性和有效性。用户可能需要了解整个流程来调试权限问题或扩展API的功能。 版本控制策略,比如Alpha、Beta、Stable版本的区别,这对用户选择API版本和规划升级路径很重要。需要提醒用户Alpha版本可能不稳定,不适合生产环境。 扩展机制,如CRD和聚合API,这部分对于高级用户想要自定义资源非常关键。用户可能想知道如何扩展Kubernetes的功能,添加自己的资源类型。 工具和客户端部分,比如kubectl、client-go、API探索工具,这些是日常操作和自动化中常用的,用户可能需要选择合适的工具进行开发或管理。 设计理念方面,声明式API、一致性、可扩展性,这些帮助用户理解Kubernetes的设计哲学,更好地利用其特性。 最后,使用场景和注意事项,提醒用户安全性和版本管理的重要性。特别是生产环境中需要注意的地方,避免常见错误。 在整理这些信息时,需要确保结构清晰,分点说明,避免技术术语过于晦涩,同时提供示例帮助理解。比如在API请求示例中,给出具体的curl命令,展示如何访问API,这样用户可以实际操作,加深理解。 可能还需要检查是否有最新的变化,比如Kubernetes版本更新带来的API变动,确保提供的信息准确。例如,某些API版本可能已被废弃,需要注明用户应使用的稳定版本。 总之,用户的需求是全面了解Kubernetes API,回答需要系统性地覆盖结构、功能、使用方法和最佳实践,同时结合实际用例和注意事项,帮助他们不仅理解概念,还能应用到实际工作中。</think>以下是Kubernetes API的详细说明,从核心概念到实际应用场景的完整解析: --- ### **Kubernetes API 核心概念** Kubernetes API是集群的**唯一入口和控制平面**,所有操作(资源管理、状态查询、扩缩容等)都通过API实现。其本质是一个**声明式、资源中心化的RESTful接口**。 --- ### **1. API 基本结构** #### **(1) 资源类型(Resource Types)** - Kubernetes将所有实体抽象为**API资源**,例如:Pod、Deployment、Service等。 - 每个资源对应一个**API端点(Endpoint)**,例如: - `/api/v1/namespaces/{namespace}/pods` - `/apis/apps/v1/namespaces/{namespace}/deployments` #### **(2) API 版本化(Versioning)** - **API组(API Groups)**:将资源按功能分组管理,例如: - **核心组**:`v1`(如Pod、Node、Namespace) - **扩展组**:`apps/v1`(Deployment)、`networking.k8s.io/v1`(Ingress) - **版本类型**: - **Alpha**(如`v1alpha1`):实验性功能,默认禁用 - **Beta**(如`v1beta1`):经过测试,但可能修改 - **Stable**(如`v1`):生产可用,长期支持 --- ### **2. API 的HTTP路径规则** Kubernetes API的URL路径遵循固定格式: ```bash # 核心组资源 /api/v1/namespaces/{namespace}/{resource-type}/{name} # 非核心组资源 /apis/{api-group}/{api-version}/namespaces/{namespace}/{resource-type}/{name} ``` **示例**: - 获取`default`命名空间下的所有Pod: `GET /api/v1/namespaces/default/pods` - 获取`kube-system`命名空间下名为`coredns`的Deployment: `GET /apis/apps/v1/namespaces/kube-system/deployments/coredns` --- ### **3. API 请求处理流程** 当请求到达API Server时,会经历以下阶段: 1. **认证(Authentication)** 验证客户端身份(如X.509证书、Bearer Token、ServiceAccount Token)。 2. **鉴权(Authorization)** 检查权限(通过RBAC、ABAC等机制)。 3. **准入控制(Admission Control)** 动态修改或验证请求(如`ResourceQuota`、`PodSecurityPolicy`)。 4. **持久化存储** 将资源状态写入etcd。 5. **资源控制器协调** 控制器(如Deployment Controller)监听API变化并触发协调逻辑。 --- ### **4. API 版本控制策略** - **兼容性规则**: - **Alpha → Beta**:可能破坏兼容性 - **Beta → Stable**:保证兼容性,仅允许字段废弃 - **多版本共存**: 同一资源可同时支持多个API版本(如`extensions/v1beta1`和`networking.k8s.io/v1`均提供Ingress)。 - **版本迁移**: 使用`kubectl convert`在不同API版本间转换资源定义。 --- ### **5. API 扩展机制** #### **(1) 自定义资源(CRD, Custom Resource Definitions)** 允许用户定义自己的资源类型: ```yaml apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: name: myresources.example.com spec: group: example.com scope: Namespaced # 或 Cluster names: plural: myresources singular: myresource kind: MyResource versions: - name: v1 served: true storage: true schema: {...} # 定义资源结构 ``` #### **(2) 聚合API(Aggregation Layer)** 将外部服务注册为Kubernetes API的子路径,实现深度集成。 --- ### **6. 常用API操作示例** #### **(1) 使用`curl`直接调用API** ```bash # 获取所有命名空间(需先配置kubeconfig代理) curl -k -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" \ https://kubernetes.default.svc/api/v1/namespaces ``` #### **(2) 使用`kubectl proxy`本地访问** ```bash kubectl proxy --port=8080 & curl http://localhost:8080/api/v1/pods ``` --- ### **7. API 设计理念** - **声明式设计**:用户描述期望状态,系统负责实现 - **强一致性**:所有组件通过Watch机制保持状态同步 - **可扩展性**:通过CRD和Webhook机制扩展功能 --- ### **8. 主要使用场景** 1. **集群管理**:创建/删除资源、扩缩容、滚动更新 2. **监控与日志**:查询资源状态、事件流 3. **自动化运维**:开发Operator、自定义控制器 4. **集成第三方系统**:CI/CD流水线、服务网格控制平面 --- ### **9. 注意事项** 1. **API访问限制**: - 默认QPS限制(可通过`--max-requests-inflight`调整) - 大列表查询建议分页(`?limit=500&continue=<token>`) 2. **安全实践**: - 最小权限原则(RBAC) - 启用审计日志(`--audit-log-path`) 3. **生产环境建议**: - 使用Stable版本API - 及时废弃旧API版本 --- ### **可视化工具推荐** - **API Explorer**:`kubectl api-resources` + `kubectl explain` - **Swagger UI**:通过`/openapi/v2`端点查看完整API文档 - **Kubernetes Dashboard**:官方Web UI 如果需要具体操作示例或深入某个技术点,可以进一步说明!
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值