Shulou(Shulou.com)06/01 Report--

This article is to share with you about what Kubernetes API Aggregator is, the editor thinks it is very practical, so I share it with you to learn. I hope you can get something after reading this article.

What is Aggregated API Server1.1, Overview

The purpose of Aggregated (aggregated) API server is to separate the original monolithic application of API server, and to facilitate users to develop their own API server integration without directly modifying the code of the official Kubernetes warehouse, so as to decouple API server and facilitate users to use experimental features. These API server can be seamlessly connected to core API server, and they can be managed using kubectl.

In version 1.7 +, the aggregation layer runs with kube-apiserver. Before the extended resource is registered, the aggregation layer does not perform any operations. To register its API, the user must add an APIService object, which needs to declare the URL path in the Kubernetes API, and the aggregation layer will be sent to the API path (e.g. / apis/myextension.mycompany.io/v1/...) Proxies all objects of to the registered APIService

Typically, APIService is implemented by running an extension-apiserver in a Pod in the cluster. If the added resource needs to be actively managed, the extension-apiserver usually needs to be paired with one or more controllers.

1.2. Design concept

Api extensibility: so that K8s developers can write their own API servers to expose the API they want. Cluster administrators should be able to use these services without making any changes to the core inventory repository.

Enriched APIs: the core kubernetes team blocked many new API proposals. By allowing developers to expose their API as a separate server and allowing cluster administrators to use them without making any changes to the core inventory repository, there is no need for cumbersome community scrutiny

Where to develop a phased experimental API: the new API can be developed in a separate aggregation server, and when it is stable, it is easy to package them and install them into other clusters.

Make sure the new API follows the kubernetes convention: without the mechanism proposed here, community members may be forced to launch their own stuff, which may or may not follow the kubernetes convention.

Aggregator for Kubernetes-style API servers: dynamic registration, discovery summarization, secure proxy II, certification process 2.1, working mode

Unlike a custom resource definition (CRD), in addition to the standard Kubernetes apiserver, Aggregation API involves another server: Extension apiserver. Kubernetes apiserver will need to communicate with your Extension apiserver, and your Extension apiserver will need to communicate with Kubernetes apiserver. To secure this communication, Kubernetes apiserver uses an x509 certificate to authenticate to Extension apiserver.

Kubernetes apiserver: authenticates the user who made the request and authenticates the requested API path

Kubernetes apiserver (aggregator): forwards the request to Extension apiserver (aggregated apiserver)

Extension apiserver: authenticate the request from Kubernetes apiserver

Extension apiserver: authenticates requests from the original user

Extension apiserver: execution

Kubernetes Apiserver Certification and Authorization

Suppose we have registered Extension apiserver with Kubernetes apiserver.

When a user requests access to path, Kubernetes apiserver uses its standard authentication and authorization configuration to authenticate users, as well as to authenticate specific path. So far, all content is standard Kubernetes API requests, authentication and authentication, and then Kubernetes apiserver is now ready to send the request to Extension apiserver.

2.3.The Kubernetes Apiserver proxy request

Kubernetes apiserver now sends or proxies the request to the Extension apiserver that registered to process the request. To do this, it needs to know a few things:

How should Kubernetes apiserver authenticate to Extension apiserver to inform Extension apiserver that requests made over the network are from a valid Kubernetes apiserver?

How should Kubernetes apiserver notify Extension apiserver of the authenticated username and group of the original request?

In short, Kubernetes apiserver has authenticated and authenticated the user's request, how this information is passed to Extension apiserver, in order to provide these two messages, we must use a number of flags to configure Kubernetes apiserver.

2.3.1. Kubernetes Apiserver client authentication

Kubernetes apiserver connects to Extension apiserver through TLS and authenticates using a client certificate, where Kubernetes apiserver (aggregator or proxy) is the client of Extension apiserver. The following must be provided to the Kubernetes apiserver at startup using the supplied flags:

Specify the private key file through-- proxy-client-key-file

Client certificate file signed by-- proxy-client-cert-file

Sign the CA certificate of the client certificate file through-- requestheader-client-ca-file

Pass-- requestheader-allowed-names 's valid common name (CN) in the signed customer certificate

Kubernetes apiserver will use the file indicated by-proxy-client-*-file to pass the Extension apiserver verification. In order for a compliant Extension apiserver to treat the request as valid, the following conditions must be met:

The connection must use a client certificate signed by CA, whose certificate is located in-- requestheader-client-ca-file.

The connection must use a client certificate whose CN is one of the certificates listed in-- requestheader-allowed-names. Note: you can set this option to blank, that is,-- requestheader-allowed-names= "". This will indicate to the extended apiserver that any CN is acceptable.

When you start with these options, Kubernetes apiserver will:

Use them to pass Extension apiserver authentication.

Create a configmap extension-apiserver-authentication in the namespace named kube-system, where it will place the CA certificate and the allowed CN. In turn, Extension apiserver can retrieve this content to validate the request.

2.3.2, original request user name and group

When Kubernetes apiserver proxies the request to Extension apiserver, it notifies Extension apiserver of the username and group that the original request has successfully authenticated. It provides these in the http header of its proxy request. You must tell Kubernetes apiserver the name of the header you are going to use.

Use-- requestheader-username-headers to indicate the header used to save the user name

Use-- requestheader-group-headers to indicate the header used to save the group

Use-- requestheader-extra-headers-prefix to indicate the header used to save the prefix of the extension information

These header names are also placed in extension-apiserver-authentication 's configmap, so Extension apiserver can retrieve and use them.

2.4.The Extension apiserver certification

After receiving an agent request from Kubernetes apiserver, Extension apiserver must verify that the request is indeed from a valid authentication agent, which is the reason for Kubernetes apiserver fulfillment. Extension apiserver authenticates it in the following ways:

As mentioned above, retrieve the following from configmap in kube-system:

Client CA certificate-requestheader-client-ca-file.

List of allowed names (CN)-requestheader-allowed-names.

Headers for user names, groups, and other information.

Check that the TLS connection is authenticated using the following certificate:

The CA signature whose certificate matches the retrieved CA certificate.

There is a CN in the allowed CN list unless the list is empty, in which case all CN are allowed.

Extract the user name and group from the appropriate header.

If all of the above passes, the request is a valid proxy request from a legitimate authentication agent (in this case, Kubernetes apiserver).

In order to have permission to retrieve configmap, Extension apiserver needs the appropriate role. There is a default role extension-apiserver-authentication-reader in the kube-system namespace that can be set up.

2.5. Extension apiserver authenticates the request

Extension apiserver can now verify that the user/group retrieved from the header is authorized to execute the given request. This is achieved by sending a standard SubjectAcce***eview request to Kubernetes apiserver.

SubjectAcce***eview is part of the resource of the authorization.k8s.io API group, which exposes API server authorization to external services. Other resources in this API group can be viewed with the following command:

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

In order for Extension apiserver itself to be authenticated to submit an SubjectAcce***eview request to Kubernetes apiserver, it needs the correct permissions. Kubernetes contains a default ClusterRole named system:auth-delegator with the appropriate permissions, which can be granted to the service account of Extension apiserver.

2.6.Enforcement of Extension apiserver

If the SubjectAcce***eview passes, the extension apiserver executes the request.

3. Deployment process 3. 1. Install cfsslwget https://pkg.cfssl.org/R1.2/cfssl_linux-amd64-O / usr/local/bin/cfsslwget https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64-O / usr/local/bin/cfssljsonwget https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64-O / usr/local/bin/cfssl-certinfocd / usr/local/bin/chmod + x cfssl cfssljson cfssl-certinfo3.2, create CA3.2.3, CA configuration file $cat > aggregator-ca-config.json

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.