는 Kubernetes API 집계는 무엇인가

발 2020-02-28 01:01:03 독서 시간: null

먼저, 집계 API 서버 것입니다

1.1 개요

Aggregated（聚合的）API server원래 API 서버에이 돌 (모 놀리 식) 애플리케이션이 API 서버 디커플링 할 수 있으므로, 코드를 직접 수정는 Kubernetes 공식 저장소없이 자신의 API 서버가 통합 개발 사용자의 편의를 위해 오픈 분할, 사용자 친화적 인 실험적인 기능입니다. 이 API 서버는 이제 할 수 core API server도 관리 할 수 있습니다 kubectl를 사용하여, 원활까지 연결합니다.

에서 1.7+버전 및 중합체 층의 KUBE-apiserver으로 실행합니다. 자원의 확장을 등록 할 전에, 중합체 층이 API를 등록, 작업을 수행하지 않고, 사용자가 추가해야 APIServiceURL 경로는 Kubernetes API를 선언해야 객체를, 폴리머 층은 API 경로 (예 : / API를 / 내 Extension로 전송됩니다 .mycompany.io / V1 / ...) APIService 모든 개체의 등록 에이전트.

일반적으로, 그것은 클러스터의 포드를 통해 실행 extension-apiserverAPIService을 달성하기 위해. 자원이 활성화 된 관리가 필요에 추가 된 경우, 일반적으로 확장-apiserver와 페어링 하나 이상의 컨트롤러를 필요로한다.

1.2 설계 개념

  • API의 확장 성 : 개발자가 원하는 API 서버에 자신의 공개 API를 쓸 수 있도록 K8S. 클러스터 관리자는 핵심 라이브러리 저장소에 대한 변경이 필요없이이 서비스를 사용할 수 있어야합니다.
  • 인리 치드의 API : 코어는 Kubernetes 팀은 새로운 API 제안을 많이 방지. 필요가 복잡 커뮤니티를 검토하지 할 수 있도록 핵심 라이브러리를 변경하기 클러스터에 개발자와 관리자를 허용하여 별도의 서버로 공개 API는 저장소를 사용하지 않을
  • 실험 API 장소의 단계적 개발 : 새로운 API가이 안정되어 별도의 집계 서버에 개발 될 수있다, 그 다음 다른 클러스터 설치를 패키징하는 것은 매우 쉽습니다.
  • 새로운 API가는 Kubernetes 규칙을 다음과 있는지 확인하십시오 : 여기에 제안 된 메커니즘이없는 경우, 지역 사회의 구성원 또는는 Kubernetes 규칙을 따르지 않을 수도 있습니다 자신의 일을 시작하도록 강요 할 수있다.

는 Kubernetes 스타일의 API 서버 어 그리 게이터 : 동적 등록, 검색 요약, 보안 프록시

둘째, 인증 과정

2.1 일

정의 자원 정의와 (CRD) 다른 표준의 apiserver는 Kubernetes 이외에 집계 API는 또 다른 서버에 관한 것이다 Extension apiserver. apiserver apiserver는 Kubernetes은 확장하고 확장 apiserver도는 Kubernetes의 apiserver와 통신 할 필요와 통신해야합니다. 이 통신, 확장 apiserver 인증으로는 Kubernetes apiserver 사용 X509 인증서의 안전을 보장합니다.

  1. 요청하여 인증 요청 사용자 인증는 Kubernetes의 apiserver : 및 API 실행 경로
  2. 는 Kubernetes의 apiserver (집계) 확장 apiserver에 전달 요청 (집계 apiserver)
  3. 확장 apiserver 다음는 Kubernetes의 apiserver에서 인증 요청
  4. 확장 apiserver : 사용자 인증에서 원래 요청
  5. 확장 apiserver : 실행

화상 20,200,225,102,139,429

2.2는 Kubernetes Apiserver 인증 및 승인

假设我们已经在 Kubernetes apiserver 注册了 Extension apiserver。

当用户请求访问 path ，Kubernetes apiserver 使用它的标准认证和授权配置来对用户认证，以及对特定 path 的鉴权，到目前为止，所有内容都是标准的 Kubernetes API 请求，认证与鉴权，接下来 Kubernetes apiserver 现在准备将请求发送到 Extension apiserver。

2.3、Kubernetes Apiserver 代理请求

Kubernetes apiserver 现在将请求发送或代理到注册以处理该请求的 Extension apiserver。为此，它需要了解几件事：

  1. Kubernetes apiserver 应该如何向 Extension apiserver 认证，以通知 Extension apiserver 通过网络发出的请求来自有效的 Kubernetes apiserver？
  2. Kubernetes apiserver 应该如何通知 Extension apiserver 原始请求已通过认证的用户名和组？

简而言之，就是 Kubernetes apiserver 已经认证和鉴权用户的请求，怎么这这些信息传递给 Extension apiserver，为提供这两条信息，我们必须使用若干标志来配置 Kubernetes apiserver。

2.3.1、Kubernetes Apiserver 客户端认证

Kubernetes apiserver 通过 TLS 连接到 Extension apiserver，并使用客户端证书认证，这里 Kubernetes apiserver (aggregator or proxy) 是 Extension apiserver 的客户端。必须在启动时使用提供的标志向 Kubernetes apiserver 提供以下内容：

  • 通过 --proxy-client-key-file 指定私钥文件
  • 通过 --proxy-client-cert-file 签名的客户端证书文件
  • 通过 --requestheader-client-ca-file 签署客户端证书文件的 CA 证书
  • 通过 --requestheader-allowed-names 在签署的客户证书中有效的公用名（CN）

Kubernetes apiserver 将使用由 –proxy-client-*-file 指示的文件来通过 Extension apiserver 验证。为了使合规的 Extension apiserver 能够将该请求视为有效，必须满足以下条件：

  1. 连接必须使用由 CA 签署的客户端证书，该证书的证书位于 --requestheader-client-ca-file 中。
  2. 连接必须使用客户端证书，该客户端证书的 CN 是 --requestheader-allowed-names 中列出的证书之一。 注意：您可以将此选项设置为空白，即为--requestheader-allowed-names=""。这将向扩展 apiserver 指示任何 CN 是可接受的。

使用这些选项启动时，Kubernetes apiserver 将：

  1. 使用它们来通过 Extension apiserver 的认证。
  2. 在名为 kube-system 命名空间中创建一个 configmap extension-apiserver-authentication ，它将在其中放置 CA 证书和允许的 CN。反过来，Extension apiserver 可以检索这些内容以验证请求。

2.3.2、原始请求用户名和组

当 Kubernetes apiserver 将请求代理到 Extension apiserver 时，它将向 Extension apiserver 通知原始请求已成功通过其验证的用户名和组。它在其代理请求的 http 标头中提供这些。您必须将要使用的标头名称告知 Kubernetes apiserver。

  • 通过--requestheader-username-headers 标明用来保存用户名的头部
  • 通过--requestheader-group-headers 标明用来保存 group 的头部
  • 通过--requestheader-extra-headers-prefix 标明用来保存拓展信息前缀的头部

这些标头名称也放置在extension-apiserver-authentication 的 configmap 中，因此 Extension apiserver 可以检索和使用它们。

2.4、Extension apiserver 认证

Extension apiserver 在收到来自 Kubernetes apiserver 的代理请求后，必须验证该请求确实确实来自有效的身份验证代理，该认证代理由 Kubernetes apiserver 履行。Extension apiserver 通过以下方式对其认证：

  1. 如上所述，从kube-system中的 configmap 中检索以下内容：
  • 客户端 CA 证书 --requestheader-client-ca-file。
  • 允许名称（CN）列表 --requestheader-allowed-names。
  • 用户名，组和其他信息的头部。
  1. 使用以下证书检查 TLS 连接是否已通过认证：
  • 由其证书与检索到的 CA 证书匹配的 CA 签名。
  • 在允许的 CN 列表中有一个 CN，除非列表为空，在这种情况下允许所有 CN。
  • 从适当的头部中提取用户名和组。

如果以上均通过，则该请求是来自合法认证代理（在本例中为 Kubernetes apiserver）的有效代理请求。

为了具有检索 configmap 的权限，Extension apiserver 需要适当的角色。在 kube-system 名字空间中有一个默认角色extension-apiserver-authentication-reader 可用于设置。

2.5、Extension apiserver 对请求鉴权

Extension apiserver 现在可以验证从标头检索的user/group是否有权执行给定请求。通过向 Kubernetes apiserver 发送标准 SubjectAcce***eview 请求来实现。

SubjectAcce***eview 是 authorization.k8s.io API 组的一部分资源，它将 API 服务器授权公开给外部服务。该 API 组中的其他资源可以通过如下命令查看：

kubectl get --raw /apis/authorization.k8s.io/v1/

为了使 Extension apiserver 本身被鉴权可以向 Kubernetes apiserver 提交 SubjectAcce***eview 请求，它需要正确的权限。Kubernetes 包含一个具有相应权限的名为system：auth-delegator 的默认 ClusterRole，可以将其授予 Extension apiserver 的服务帐户。

2.6、Extension apiserver 执行

如果SubjectAcce***eview通过，则扩展 apiserver 执行请求。

三、部署过程

3.1、安装 cfssl

wget https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 -O /usr/local/bin/cfssl
wget https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64 -O /usr/local/bin/cfssljson
wget https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64 -O /usr/local/bin/cfssl-certinfo
cd /usr/local/bin/
chmod +x cfssl cfssljson cfssl-certinfo

3.2、创建 CA

3.2.3、CA 配置文件

$ cat > aggregator-ca-config.json <<EOF
{
  "signing": {
    "default": {
      "expiry": "87600h"
    },
    "profiles": {
      "aggregator": {
        "usages": [
            "signing",
            "key encipherment",
            "server auth",
            "client auth"
        ],
        "expiry": "87600h"
      }
    }
  }
}
EOF
  • profiles : 可以定义多个 profiles，分别指定不同的过期时间、使用场景等参数；后续在签名证书时使用某个 profile。
  • signing ：表示该证书可用于签名其它证书；生成的 aggregator-ca.pem 证书中 CA=TRUE。
  • server auth ：表示 Client 可以用该 CA 对 Server 提供的证书进行验证。
  • client auth ：表示 Server 可以用该 CA 对 Client 提供的证书进行验证。

3.2.3、创建 CA 证书签名请求

$ cat > aggregator-ca-csr.json <<EOF
{
  "CN": "aggregator",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "CN",
      "ST": "Shanghai",
      "L": "Shanghai",
      "O": "k8s",
      "OU": "wzlinux"
    }
  ],
    "ca": {
       "expiry": "87600h"
    }
}
  • “CN” ：Common Name，kube-apiserver 从证书中提取该字段作为请求的用户名 (User Name)；浏览器使用该字段验证网站是否合法。
  • "O"는 : OrganizationKUBE-apiserver 요청이 인증에서 사용자의 그룹 (그룹)으로 필드를 추출;

3.2.4 생성 된 CA 인증서 및 개인 키

cfssl gencert -initca aggregator-ca-csr.json | cfssljson -bare aggregator-ca

3.3는 Kubernetes 인증서를 만들

애그리 게이터 (aggregator) 인증서 서명 요청 만들기 3.3.1

$ cat > aggregator-csr.json <<EOF
{
    "CN": "aggregator",
    "hosts": [
      "127.0.0.1",
      "172.18.0.101",
      "172.18.0.102",
      "172.18.0.103",
      "10.96.0.1",
      "kubernetes",
      "kubernetes.default",
      "kubernetes.default.svc",
      "kubernetes.default.svc.cluster",
      "kubernetes.default.svc.cluster.local"
    ],
    "key": {
        "algo": "rsa",
        "size": 2048
    },
    "names": [
        {
            "C": "CN",
            "ST": "Shanghai",
            "L": "Shanghai",
            "O": "k8s",
            "OU": "wzlinux"
        }
    ]
}

호스트 필드는 인증서 이후는 Kubernetes 마스터 클러스터를 사용하기 때문에 IP 또는 인증서의 도메인 이름 목록을 사용할 수있는 권한 지정할 필요가 비어 있지 않은 경우 위의 지정된 때문에 kubernetes master서비스 IP 호스트 IP와는 Kubernetes 서비스 클러스터 (일반적으로 KUBE-apiserver 지정된 service-cluster-ip-range네트워크 10.96.0.1 같은 IP의 처음 부분).

3.3.2 생성 aggreagtor 인증서 및 개인 키

cfssl gencert -ca=aggregator-ca.pem -ca-key=aggregator-ca-key.pem -config=aggregator-ca-config.json -profile=aggregator aggregator-csr.json | cfssljson -bare aggregator

3.3.3, 배포 인증서

생성 된 비밀 키와 인증서 파일 (접미사가 .pem) 마스터 노드가 복사됩니다 /etc/kubernetes/pki백업 디렉토리.

3.4 고분자 층을 오픈 API

kube-apiserver 다음과 같은 구성을 추가합니다 :

--requestheader-client-ca-file=/etc/kubernetes/pki/aggregator-ca.pem
--requestheader-allowed-names=aggregator
--requestheader-extra-headers-prefix=X-Remote-Extra-
--requestheader-group-headers=X-Remote-Group
--requestheader-username-headers=X-Remote-User
--proxy-client-cert-file=/etc/kubernetes/pki/aggregator.pem
--proxy-client-key-file=/etc/kubernetes/pki/aggregator-key.pem

인증서는 이전에 생성 한 CN필드 값과 매개 변수가 있어야합니다 –requestheader-allowed-names의 값을 지정 aggregator동일합니다.

다시 시작 KUBE-apiserver :

$ systemctl daemon-reload
$ systemctl restart kube-apiserver

경우 kube-proxy위의 마스터를 실행하지 않는, kube-proxy또한 당신은 구성을 추가해야합니다 :

--enable-aggregator-routing=true

참고

자세한 내용은 해당 스캔 코드에 오신 것을 환영합니다

는 Kubernetes API 집계는 무엇인가

추천

출처blog.51cto.com/wzlinux/2474075
추천
행
.netcoreapi 컨테이너와 컨테이너의 MySQL을 고정 표시기-구성
com.google.firebase.database.DatabaseException는 : 롱 타입 java.lang.String의 값을 변환하는 데 실패
국내 휴대전화 왕이 미국 통신사 시장 1위를 차지했지만 국내 휴대전화 4위는 아니다.
트랜잭션 격리 수준의 네 가지
오늘 chatgpt 시도
부하 분산
【FFMpeg】源码编译
우분투 sudo를 무료로 접착
자바 8 스트림 API - 어떤 상태 중간 동작을 보증 새로운 소스 수집합니까?
CF161BDiscounts
아카이브
기타
2020-04-08(1460)
2020-04-07(1517)
2020-04-06(1499)
2020-04-05(1440)
2020-04-04(1629)
2020-04-03(1644)
2020-04-02(1572)
2020-04-01(1665)
2020-03-31(1639)
2020-03-30(1334)

코드 세계

© 2018 codetd.com