Kubernetes Handbook
  • Kubernetes 中文指南/云原生应用架构实践手册
  • 前言
    • 序言
  • 云原生
    • 云原生(Cloud Native)的定义
    • 云原生的设计哲学
    • Play with Kubernetes
    • 快速部署一个云原生本地实验环境
    • 使用Rancher在阿里云上部署Kubenretes集群
    • Kubernetes与云原生应用概览
    • 云原生应用之路——从Kubernetes到Cloud Native
    • 云原生编程语言
      • 云原生编程语言Ballerina
      • 云原生编程语言Pulumi
    • 云原生的未来
  • 概念与原理
    • Kubernetes架构
      • 设计理念
      • Etcd解析
      • 开放接口
        • CRI - Container Runtime Interface(容器运行时接口)
        • CNI - Container Network Interface(容器网络接口)
        • CSI - Container Storage Interface(容器存储接口)
    • Kubernetes中的网络
      • Kubernetes中的网络解析——以flannel为例
      • Kubernetes中的网络解析——以calico为例
      • 具备API感知的网络和安全性管理开源软件Cilium
        • Cilium架构设计与概念解析
    • 资源对象与基本概念解析
    • Pod状态与生命周期管理
      • Pod概览
      • Pod解析
      • Init容器
      • Pause容器
      • Pod安全策略
      • Pod的生命周期
      • Pod Hook
      • Pod Preset
      • Pod中断与PDB(Pod中断预算)
    • 集群资源管理
      • Node
      • Namespace
      • Label
      • Annotation
      • Taint和Toleration(污点和容忍)
      • 垃圾收集
    • 控制器
      • Deployment
      • StatefulSet
      • DaemonSet
      • ReplicationController和ReplicaSet
      • Job
      • CronJob
      • Horizontal Pod Autoscaling
        • 自定义指标HPA
      • 准入控制器(Admission Controller)
    • 服务发现
      • Service
      • Ingress
        • Traefik Ingress Controller
    • 身份与权限控制
      • ServiceAccount
      • RBAC——基于角色的访问控制
      • NetworkPolicy
    • 存储
      • Secret
      • ConfigMap
        • ConfigMap的热更新
      • Volume
      • Persistent Volume(持久化卷)
      • Storage Class
      • 本地持久化存储
    • 集群扩展
      • 使用自定义资源扩展API
      • 使用CRD扩展Kubernetes API
      • Aggregated API Server
      • APIService
      • Service Catalog
    • 资源调度
      • QoS(服务质量等级)
  • 用户指南
    • 用户指南
    • 资源对象配置
      • 配置Pod的liveness和readiness探针
      • 配置Pod的Service Account
      • Secret配置
      • 管理namespace中的资源配额
    • 命令使用
      • Docker用户过渡到kubectl命令行指南
      • kubectl命令概览
      • kubectl命令技巧大全
      • 使用etcdctl访问kubernetes数据
    • 集群安全性管理
      • 管理集群中的TLS
      • kubelet的认证授权
      • TLS bootstrap
      • 创建用户认证授权的kubeconfig文件
      • IP伪装代理
      • 使用kubeconfig或token进行用户身份认证
      • Kubernetes中的用户与身份认证授权
      • Kubernetes集群安全性配置最佳实践
    • 访问Kubernetes集群
      • 访问集群
      • 使用kubeconfig文件配置跨集群认证
      • 通过端口转发访问集群中的应用程序
      • 使用service访问群集中的应用程序
      • 从外部访问Kubernetes中的Pod
      • Cabin - Kubernetes手机客户端
      • Kubernetic - Kubernetes桌面客户端
      • Kubernator - 更底层的Kubernetes UI
    • 在Kubernetes中开发部署应用
      • 适用于kubernetes的应用开发部署流程
      • 迁移传统应用到Kubernetes中——以Hadoop YARN为例
      • 使用StatefulSet部署用状态应用
  • 最佳实践
    • 最佳实践概览
    • 在CentOS上部署Kubernetes集群
      • 创建TLS证书和秘钥
      • 创建kubeconfig文件
      • 创建高可用etcd集群
      • 安装kubectl命令行工具
      • 部署master节点
      • 安装flannel网络插件
      • 部署node节点
      • 安装kubedns插件
      • 安装dashboard插件
      • 安装heapster插件
      • 安装EFK插件
    • 生产级的Kubernetes简化管理工具kubeadm
      • 使用kubeadm在Ubuntu Server 16.04上快速构建测试集群
    • 服务发现与负载均衡
      • 安装Traefik ingress
      • 分布式负载测试
      • 网络和集群性能测试
      • 边缘节点配置
      • 安装Nginx ingress
      • 安装配置DNS
        • 安装配置Kube-dns
        • 安装配置CoreDNS
    • 运维管理
      • Master节点高可用
      • 服务滚动升级
      • 应用日志收集
      • 配置最佳实践
      • 集群及应用监控
      • 数据持久化问题
      • 管理容器的计算资源
      • 集群联邦
    • 存储管理
      • GlusterFS
        • 使用GlusterFS做持久化存储
        • 使用Heketi作为Kubernetes的持久存储GlusterFS的external provisioner
        • 在OpenShift中使用GlusterFS做持久化存储
      • GlusterD-2.0
      • Ceph
        • 用Helm托管安装Ceph集群并提供后端存储
        • 使用Ceph做持久化存储
        • 使用rbd-provisioner提供rbd持久化存储
      • OpenEBS
        • 使用OpenEBS做持久化存储
      • Rook
      • NFS
        • 利用NFS动态提供Kubernetes后端存储卷
    • 集群与应用监控
      • Heapster
        • 使用Heapster获取集群和对象的metric数据
      • Prometheus
        • 使用Prometheus监控kubernetes集群
        • Prometheus查询语言PromQL使用说明
      • 使用Vistio监控Istio服务网格中的流量
    • 分布式跟踪
      • OpenTracing
    • 服务编排管理
      • 使用Helm管理Kubernetes应用
      • 构建私有Chart仓库
    • 持续集成与发布
      • 使用Jenkins进行持续集成与发布
      • 使用Drone进行持续集成与发布
    • 更新与升级
      • 手动升级Kubernetes集群
      • 升级dashboard
  • 领域应用
    • 领域应用概览
    • 微服务架构
      • 微服务中的服务发现
      • 使用Java构建微服务并发布到Kubernetes平台
        • Spring Boot快速开始指南
    • Service Mesh 服务网格
      • 企业级服务网格架构
        • Service Mesh基础
        • Service Mesh技术对比
        • 采纳和演进
        • 定制和集成
        • 总结
      • Istio
        • 安装并试用Istio service mesh
        • 配置请求的路由规则
        • 安装和拓展Istio service mesh
        • 集成虚拟机
        • Istio中sidecar的注入规范及示例
        • 如何参与Istio社区及注意事项
        • Istio教程
        • Istio免费学习资源汇总
        • 深入理解Istio Service Mesh中的Envoy Sidecar注入与流量劫持
        • 深入理解Istio Service Mesh中的Envoy Sidecar代理的路由转发
      • Linkerd
        • Linkerd 使用指南
      • Conduit
        • Condiut概览
        • 安装Conduit
      • Envoy
        • Envoy的架构与基本术语
        • Envoy作为前端代理
        • Envoy mesh教程
      • SOFAMesh
        • SOFAMesh中的Dubbo on x-protocol
      • MOSN
        • 使用 MOSN 构建 SOFAMesh
    • 大数据
      • Spark standalone on Kubernetes
      • 运行支持Kubernetes原生调度的Spark程序
    • Serverless架构
      • 理解Serverless
      • FaaS-函数即服务
        • OpenFaaS快速入门指南
    • 边缘计算
    • 人工智能
  • 开发指南
    • 开发指南概览
    • SIG和工作组
    • 开发环境搭建
      • 本地分布式开发环境搭建(使用Vagrant和Virtualbox)
    • 单元测试和集成测试
    • client-go示例
    • Operator
      • operator-sdk
    • kubebuilder
    • 高级开发指南
    • 社区贡献
    • Minikube
  • CNCF(云原生计算基金会)
    • CNCF - 云原生计算基金会简介
    • CNCF章程
    • CNCF特别兴趣小组(SIG)说明
    • 开源项目加入CNCF Sandbox的要求
    • CNCF中的项目治理
    • CNCF Ambassador
  • 附录
    • 附录说明
    • Kubernetes中的应用故障排查
    • Kubernetes相关资讯和情报链接
    • Docker最佳实践
    • 使用技巧
    • 问题记录
    • Kubernetes版本更新日志
      • Kubernetes1.7更新日志
      • Kubernetes1.8更新日志
      • Kubernetes1.9更新日志
      • Kubernetes1.10更新日志
      • Kubernetes1.11更新日志
      • Kubernetes1.12更新日志
      • Kubernetes1.13更新日志
      • Kubernetes1.14更新日志
      • Kubernetes1.15更新日志
    • Kubernetes及云原生年度总结及展望
      • Kubernetes与云原生2017年年终总结及2018年展望
      • Kubernetes与云原生2018年年中总结及2019年展望
    • CNCF年度报告解读
      • CNCF 2018年年度报告解读
    • Kubernetes认证服务提供商(KCSP)说明
    • 认证Kubernetes管理员(CKA)说明
Powered by GitBook
On this page
  • 第一次使用 kubectl 访问
  • 直接访问 REST API
  • 使用 kubectl proxy
  • 不使用 kubectl proxy(1.3.x 以前版本)
  • 不使用 kubectl proxy(1.3.x 以后版本)
  • 编程访问 API
  • Go 客户端
  • Python 客户端
  • 其他语言
  • 在 Pod 中访问 API
  • 访问集群中运行的 service
  • 连接的方式
  • 访问内置服务
  • 请求重定向
  • 多种代理

Was this helpful?

  1. 用户指南
  2. 访问Kubernetes集群

访问集群

第一次使用 kubectl 访问

如果您是第一次访问 Kubernetes API 的话,我们建议您使用 Kubernetes 命令行工具:kubectl。

为了访问集群,您需要知道集群的地址,并且需要有访问它的凭证。通常,如果您完成了入门指南那么这些将会自动设置,或者其他人为您部署的集群提供并给您凭证和集群地址。

使用下面的命令检查 kubectl 已知的集群的地址和凭证:

$ kubectl config view

直接访问 REST API

Kubectl 处理对 apiserver 的定位和认证。如果您想直接访问 REST API,可以使用像 curl、wget 或浏览器这样的 http 客户端,有以下几种方式来定位和认证:

  • 以 proxy 模式运行 kubectl。

    • 推荐方法。

    • 使用已保存的 apiserver 位置信息。

    • 使用自签名证书验证 apiserver 的身份。 没有 MITM(中间人攻击)的可能。

    • 认证到 apiserver。

    • 将来,可能会做智能的客户端负载均衡和故障转移。

  • 直接向 http 客户端提供位置和凭据。

    • 替代方法。

    • 适用于通过使用代理而混淆的某些类型的客户端代码。

    • 需要将根证书导入浏览器以防止 MITM。

使用 kubectl proxy

以下命令作为反向代理的模式运行 kubectl。 它处理对 apiserver 的定位并进行认证。

像这样运行:

$ kubectl proxy --port=8080 &

然后您可以使用 curl、wget 或者浏览器来访问 API,如下所示:

$ curl http://localhost:8080/api/
{
  "versions": [
    "v1"
  ]
}

不使用 kubectl proxy(1.3.x 以前版本)

通过将认证 token 直接传递给 apiserver 的方式,可以避免使用 kubectl proxy,如下所示:

$ APISERVER=$(kubectl config view | grep server | cut -f 2- -d ":" | tr -d " ")
$ TOKEN=$(kubectl config view | grep token | cut -f 2 -d ":" | tr -d " ")
$ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
{
  "versions": [
    "v1"
  ]
}

不使用 kubectl proxy(1.3.x 以后版本)

在 Kubernetes 1.3 或更高版本中,kubectl config view 不再显示 token。 使用 kubectl describe secret … 获取 default service account 的 token,如下所示:

$ APISERVER=$(kubectl config view | grep server | cut -f 2- -d ":" | tr -d " ")
$ TOKEN=$(kubectl describe secret $(kubectl get secrets | grep default | cut -f1 -d ' ') | grep -E '^token' | cut -f2 -d':' | tr -d '\t')
$ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
{
  "kind": "APIVersions",
  "versions": [
    "v1"
  ],
  "serverAddressByClientCIDRs": [
    {
      "clientCIDR": "0.0.0.0/0",
      "serverAddress": "10.0.1.149:443"
    }
  ]
}

以上示例使用--insecure 标志。 这使得它容易受到 MITM 攻击。 当 kubectl 访问集群时,它使用存储的根证书和客户端证书来访问服务器。 (这些安装在~/.kube目录中)。 由于集群证书通常是自签名的,因此可能需要特殊配置才能让您的 http 客户端使用根证书。

编程访问 API

Go 客户端

  • 使用 client-go 客户端编程。请注意,client-go 定义了自己的 API 对象,因此如果需要,请从 client-go 而不是从主存储库导入 API 定义,例如导入 k8s.io/client-go/1.4/pkg/api/v1 是正确的。

Python 客户端

其他语言

还有更多的客户端库可以用来访问 API。有关其他库的验证方式,请参阅文档。

在 Pod 中访问 API

在 Pod 中访问 API 时,定位和认证到 API server 的方式有所不同。在 Pod 中找到 apiserver 地址的推荐方法是使用kubernetes DNS 名称,将它解析为服务 IP,后者又将被路由到 apiserver。

如果可用,证书包将位于每个容器的文件系统树的 /var/run/secrets/kubernetes.io/serviceaccount/ca.crt 位置,并用于验证 apiserver 的服务证书。

最后,用于 namespace API 操作的默认 namespace 放在每个容器中的 /var/run/secrets/kubernetes.io/serviceaccount/namespace 中。

在 pod 中,连接到 API 的推荐方法是:

  • 将 kubectl proxy 作为 pod 中的一个容器来运行,或作为在容器内运行的后台进程。它将 Kubernetes API 代理到 pod 的本地主机接口,以便其他任何 pod 中的容器内的进程都可以访问它。

  • 使用 Go 客户端库,并使用 rest.InClusterConfig() 和 kubernetes.NewForConfig() 函数创建一个客户端。

在以上的几种情况下,都需要使用 pod 的凭据与 apiserver 进行安全通信。

访问集群中运行的 service

连接的方式

您可以选择以下几种方式从集群外部连接到 node、pod 和 service:

  • 通过 public IP 访问 service。

    • 使用 NodePort 和 LoadBalancer 类型的 service,以使 service 能够在集群外部被访问到。

    • 根据您的群集环境,这可能会将服务暴露给您的公司网络,或者可能会将其暴露在互联网上。想想暴露的服务是否安全。它是否自己进行身份验证?

    • 将 pod 放在服务后面。 要从一组副本(例如为了调试)访问一个特定的 pod,请在 pod 上放置一个唯一的 label,并创建一个选择该 label 的新服务。

    • 在大多数情况下,应用程序开发人员不需要通过 node IP 直接访问节点。

  • 通过 Proxy 规则访问 service、node、pod。

    • 在访问远程服务之前,请执行 apiserver 认证和授权。 如果服务不够安全,无法暴露给互联网,或者为了访问节点 IP 上的端口或进行调试,请使用这种方式。

    • 代理可能会导致某些 Web 应用程序出现问题。

    • 仅适用于 HTTP/HTTPS。

  • 在集群内访问 node 和 pod。

    • 运行一个 pod,然后使用 kubectl exec 命令连接到 shell。从该 shell 中连接到其他 node、pod 和 service。

    • 有些集群可能允许 ssh 到集群上的某个节点。 从那个节点您可以访问到集群中的服务。这是一个非标准的方法,它可能将在某些集群上奏效,而在某些集群不行。这些节点上可能安装了浏览器和其他工具也可能没有。群集 DNS 可能无法正常工作。

访问内置服务

通常集群内会有几个在 kube-system 中启动的服务。使用 kubectl cluster-info 命令获取该列表:

$ kubectl cluster-info

  Kubernetes master is running at https://104.197.5.247
  elasticsearch-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy
  kibana-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kibana-logging/proxy
  kube-dns is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kube-dns/proxy
  grafana is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy
  heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy

这显示了访问每个服务的代理 URL。

例如,此集群启用了集群级日志记录(使用Elasticsearch),如果传入合适的凭据,可以在该地址 https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/ 访问到,或通过 kubectl 代理,例如:http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/。

手动构建 apiserver 代理 URL

如上所述,您可以使用 kubectl cluster-info 命令来检索服务的代理 URL。要创建包含服务端点、后缀和参数的代理 URL,您只需附加到服务的代理URL:

http://kubernetes_master_address/api/v1/namespaces/namespace_name/services/service_name[:port_name]/proxy

如果您没有指定 port 的名字,那么您不必在 URL 里指定 port_name。

示例

  • 要想访问 Elasticsearch 的服务端点 _search?q=user:kimchy,您需要使用:http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy

  • 要想访问 Elasticsearch 的集群健康信息 _cluster/health?pretty=true,您需要使用:https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true

  {
    "cluster_name" : "kubernetes_logging",
    "status" : "yellow",
    "timed_out" : false,
    "number_of_nodes" : 1,
    "number_of_data_nodes" : 1,
    "active_primary_shards" : 5,
    "active_shards" : 5,
    "relocating_shards" : 0,
    "initializing_shards" : 0,
    "unassigned_shards" : 5
  }

使用 web 浏览器来访问集群中运行的服务

您可以将 apiserver 代理网址放在浏览器的地址栏中。 然而:

  • Web 浏览器通常不能传递 token,因此您可能需要使用基本(密码)认证。 Apiserver 可以配置为接受基本认证,但您的集群可能未配置为接受基本认证。

  • 某些网络应用程序可能无法正常工作,特别是那些在不知道代理路径前缀的情况下构造 URL 的客户端 JavaScript。

请求重定向

重定向功能已被弃用和删除。 请改用代理(见下文)。

多种代理

在使用 kubernetes 的时候您可能会遇到许多种不同的代理:

    • 在用户桌面或 pod 中运行

    • 从 localhost 地址到 Kubernetes apiserver 的代理

    • 客户端到代理使用 HTTP

    • apiserver 的代理使用 HTTPS

    • 定位 apiserver

    • 添加身份验证 header

    • 将一个堡垒机作为 apiserver

    • 将群集之外的用户连接到群集IP,否则可能无法访问

    • 在 apiserver 进程中运行

    • 客户端到代理使用 HTTPS(或 http,如果 apiserver 如此配置)

    • 根据代理目标的可用信息由代理选择使用 HTTP 或 HTTPS

    • 可用于访问 node、pod 或 service

    • 用于访问 service 时进行负载均衡

    • 在每个节点上运行

    • 代理 UDP 和 TCP

    • 不支持 HTTP

    • 提供负载均衡

    • 只是用来访问 service

  1. apiserver 前面的代理/负载均衡器:

    • 存在和实现因群集而异(例如 nginx)

    • 位于所有客户端和一个或多个 apiserver 之间

    • 作为负载均衡器,如果有多个 apiserver

  2. 外部服务的云负载均衡器:

    • 由一些云提供商提供(例如 AWS ELB,Google Cloud Load Balancer)

    • 当 Kubernetes service 类型为 LoadBalancer 时,会自动创建

    • 仅使用 UDP/TCP

    • 实施方式因云提供商而异

Previous访问Kubernetes集群Next使用kubeconfig文件配置跨集群认证

Last updated 5 years ago

Was this helpful?

对于某些群集,apiserver 可能不需要身份验证;可以选择在本地主机上服务,或者使用防火墙保护。 对此还没有一个标准。 描述了群集管理员如何配置此操作。 这种方法可能与未来的高可用性支持相冲突。

Kubernetes 支持 和 客户端库。

要获取该库,请运行以下命令:go get k8s.io/client-go/<version number>/kubernetes 请参阅 以查看支持哪些版本。

Go 客户端可以使用与 kubectl 命令行工具相同的 来定位和验证 apiserver。参考官方 和 。

如果应用程序在群集中以 Pod 的形式部署,请参考 。

要使用 ,请运行以下命令:pip install kubernetes。查看 获取更多的安装选择。

Python 客户端可以使用与 kubectl 命令行工具相同的 来定位和验证 apiserver。

向 apiserver 认证的推荐方法是使用 凭据。通过 kube-system,pod 与 service account 相关联,并且将该 service account 的凭据(token)放入该 pod 中每个容器的文件系统树中,位于 /var/run/secrets/kubernetes.io/serviceaccount/token。

他们处理对 apiserver 的定位和认证。

上一节是关于连接到 kubernetes API server。这一节是关于连接到 kubernetes 集群中运行的 service。在 Kubernetes 中,、 和 都有它们自己的 IP。很多情况下,集群中 node 的 IP、Pod 的 IP、service 的 IP 都是不可路由的,因此在集群外面的机器就无法访问到它们,例如从您自己的笔记本电脑。

。

(有关如何传递凭据和使用 kubectl 代理,请 )

:

:

:

配置对API的访问
Go
Python
https://github.com/kubernetes/client-go
kubeconfig 文件
示例
client-go 示例
下一节
Python client
Python 客户端库页面
kubeconfig 文件
service account
示例
node
pod
services
见此描述
参阅上文
kubectl 代理
apiserver 代理
kube 代理