Merge pull request #50098 from michellengnx/merged-main-dev-1.33
Merge main branch into dev-1.33pull/49749/head
Kubernetes Prow Robot
GitHub
commit
a1c493fe8d
|
|
@ -0,0 +1,157 @@
|
|||
---
|
||||
layout: blog
|
||||
title: "Spotlight on SIG Apps"
|
||||
slug: sig-apps-spotlight-2025
|
||||
canonicalUrl: https://www.kubernetes.dev/blog/2025/03/12/sig-apps-spotlight-2025
|
||||
date: 2025-03-12
|
||||
author: "Sandipan Panda (DevZero)"
|
||||
---
|
||||
|
||||
In our ongoing SIG Spotlight series, we dive into the heart of the Kubernetes project by talking to
|
||||
the leaders of its various Special Interest Groups (SIGs). This time, we focus on
|
||||
**[SIG Apps](https://github.com/kubernetes/community/tree/master/sig-apps#apps-special-interest-group)**,
|
||||
the group responsible for everything related to developing, deploying, and operating applications on
|
||||
Kubernetes. [Sandipan Panda](https://www.linkedin.com/in/sandipanpanda)
|
||||
([DevZero](https://www.devzero.io/)) had the opportunity to interview [Maciej
|
||||
Szulik](https://github.com/soltysh) ([Defense Unicorns](https://defenseunicorns.com/)) and [Janet
|
||||
Kuo](https://github.com/janetkuo) ([Google](https://about.google/)), the chairs and tech leads of
|
||||
SIG Apps. They shared their experiences, challenges, and visions for the future of application
|
||||
management within the Kubernetes ecosystem.
|
||||
|
||||
## Introductions
|
||||
|
||||
**Sandipan: Hello, could you start by telling us a bit about yourself, your role, and your journey
|
||||
within the Kubernetes community that led to your current roles in SIG Apps?**
|
||||
|
||||
**Maciej**: Hey, my name is Maciej, and I’m one of the leads for SIG Apps. Aside from this role, you
|
||||
can also find me helping
|
||||
[SIG CLI](https://github.com/kubernetes/community/tree/master/sig-cli#readme) and also being one of
|
||||
the Steering Committee members. I’ve been contributing to Kubernetes since late 2014 in various
|
||||
areas, including controllers, apiserver, and kubectl.
|
||||
|
||||
**Janet**: Certainly! I'm Janet, a Staff Software Engineer at Google, and I've been deeply involved
|
||||
with the Kubernetes project since its early days, even before the 1.0 launch in 2015. It's been an
|
||||
amazing journey!
|
||||
|
||||
My current role within the Kubernetes community is one of the chairs and tech leads of SIG Apps. My
|
||||
journey with SIG Apps started organically. I started with building the Deployment API and adding
|
||||
rolling update functionalities. I naturally gravitated towards SIG Apps and became increasingly
|
||||
involved. Over time, I took on more responsibilities, culminating in my current leadership roles.
|
||||
|
||||
## About SIG Apps
|
||||
|
||||
*All following answers were jointly provided by Maciej and Janet.*
|
||||
|
||||
**Sandipan: For those unfamiliar, could you provide an overview of SIG Apps' mission and objectives?
|
||||
What key problems does it aim to solve within the Kubernetes ecosystem?**
|
||||
|
||||
As described in our
|
||||
[charter](https://github.com/kubernetes/community/blob/master/sig-apps/charter.md#scope), we cover a
|
||||
broad area related to developing, deploying, and operating applications on Kubernetes. That, in
|
||||
short, means we’re open to each and everyone showing up at our bi-weekly meetings and discussing the
|
||||
ups and downs of writing and deploying various applications on Kubernetes.
|
||||
|
||||
**Sandipan: What are some of the most significant projects or initiatives currently being undertaken
|
||||
by SIG Apps?**
|
||||
|
||||
At this point in time, the main factors driving the development of our controllers are the
|
||||
challenges coming from running various AI-related workloads. It’s worth giving credit here to two
|
||||
working groups we’ve sponsored over the past years:
|
||||
|
||||
1. [The Batch Working Group](https://github.com/kubernetes/community/tree/master/wg-batch), which is
|
||||
looking at running HPC, AI/ML, and data analytics jobs on top of Kubernetes.
|
||||
2. [The Serving Working Group](https://github.com/kubernetes/community/tree/master/wg-serving), which
|
||||
is focusing on hardware-accelerated AI/ML inference.
|
||||
|
||||
## Best practices and challenges
|
||||
|
||||
**Sandipan: SIG Apps plays a crucial role in developing application management best practices for
|
||||
Kubernetes. Can you share some of these best practices and how they help improve application
|
||||
lifecycle management?**
|
||||
|
||||
1. Implementing [health checks and readiness probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)
|
||||
ensures that your applications are healthy and ready to serve traffic, leading to improved
|
||||
reliability and uptime. The above, combined with comprehensive logging, monitoring, and tracing
|
||||
solutions, will provide insights into your application's behavior, enabling you to identify and
|
||||
resolve issues quickly.
|
||||
|
||||
2. [Auto-scale your application](/docs/concepts/workloads/autoscaling/) based
|
||||
on resource utilization or custom metrics, optimizing resource usage and ensuring your
|
||||
application can handle varying loads.
|
||||
|
||||
3. Use Deployment for stateless applications, StatefulSet for stateful applications, Job
|
||||
and CronJob for batch workloads, and DaemonSet for running a daemon on each node. Use
|
||||
Operators and CRDs to extend the Kubernetes API to automate the deployment, management, and
|
||||
lifecycle of complex applications, making them easier to operate and reducing manual
|
||||
intervention.
|
||||
|
||||
**Sandipan: What are some of the common challenges SIG Apps faces, and how do you address them?**
|
||||
|
||||
The biggest challenge we’re facing all the time is the need to reject a lot of features, ideas, and
|
||||
improvements. This requires a lot of discipline and patience to be able to explain the reasons
|
||||
behind those decisions.
|
||||
|
||||
**Sandipan: How has the evolution of Kubernetes influenced the work of SIG Apps? Are there any
|
||||
recent changes or upcoming features in Kubernetes that you find particularly relevant or beneficial
|
||||
for SIG Apps?**
|
||||
|
||||
The main benefit for both us and the whole community around SIG Apps is the ability to extend
|
||||
kubernetes with [Custom Resource Definitions](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
|
||||
and the fact that users can build their own custom controllers leveraging the built-in ones to
|
||||
achieve whatever sophisticated use cases they might have and we, as the core maintainers, haven’t
|
||||
considered or weren’t able to efficiently resolve inside Kubernetes.
|
||||
|
||||
## Contributing to SIG Apps
|
||||
|
||||
**Sandipan: What opportunities are available for new contributors who want to get involved with SIG
|
||||
Apps, and what advice would you give them?**
|
||||
|
||||
We get the question, "What good first issue might you recommend we start with?" a lot :-) But
|
||||
unfortunately, there’s no easy answer to it. We always tell everyone that the best option to start
|
||||
contributing to core controllers is to find one you are willing to spend some time with. Read
|
||||
through the code, then try running unit tests and integration tests focusing on that
|
||||
controller. Once you grasp the general idea, try breaking it and the tests again to verify your
|
||||
breakage. Once you start feeling confident you understand that particular controller, you may want
|
||||
to search through open issues affecting that controller and either provide suggestions, explaining
|
||||
the problem users have, or maybe attempt your first fix.
|
||||
|
||||
Like we said, there are no shortcuts on that road; you need to spend the time with the codebase to
|
||||
understand all the edge cases we’ve slowly built up to get to the point where we are. Once you’re
|
||||
successful with one controller, you’ll need to repeat that same process with others all over again.
|
||||
|
||||
**Sandipan: How does SIG Apps gather feedback from the community, and how is this feedback
|
||||
integrated into your work?**
|
||||
|
||||
We always encourage everyone to show up and present their problems and solutions during our
|
||||
bi-weekly [meetings](https://github.com/kubernetes/community/tree/master/sig-apps#meetings). As long
|
||||
as you’re solving an interesting problem on top of Kubernetes and you can provide valuable feedback
|
||||
about any of the core controllers, we’re always happy to hear from everyone.
|
||||
|
||||
## Looking ahead
|
||||
|
||||
**Sandipan: Looking ahead, what are the key focus areas or upcoming trends in application management
|
||||
within Kubernetes that SIG Apps is excited about? How is the SIG adapting to these trends?**
|
||||
|
||||
Definitely the current AI hype is the major driving factor; as mentioned above, we have two working
|
||||
groups, each covering a different aspect of it.
|
||||
|
||||
**Sandipan: What are some of your favorite things about this SIG?**
|
||||
|
||||
Without a doubt, the people that participate in our meetings and on
|
||||
[Slack](https://kubernetes.slack.com/messages/sig-apps), who tirelessly help triage issues, pull
|
||||
requests and invest a lot of their time (very frequently their private time) into making kubernetes
|
||||
great!
|
||||
|
||||
---
|
||||
|
||||
SIG Apps is an essential part of the Kubernetes community, helping to shape how applications are
|
||||
deployed and managed at scale. From its work on improving Kubernetes' workload APIs to driving
|
||||
innovation in AI/ML application management, SIG Apps is continually adapting to meet the needs of
|
||||
modern application developers and operators. Whether you’re a new contributor or an experienced
|
||||
developer, there’s always an opportunity to get involved and make an impact.
|
||||
|
||||
If you’re interested in learning more or contributing to SIG Apps, be sure to check out their [SIG
|
||||
README](https://github.com/kubernetes/community/tree/master/sig-apps) and join their bi-weekly [meetings](https://github.com/kubernetes/community/tree/master/sig-apps#meetings).
|
||||
|
||||
- [SIG Apps Mailing List](https://groups.google.com/a/kubernetes.io/g/sig-apps)
|
||||
- [SIG Apps on Slack](https://kubernetes.slack.com/messages/sig-apps)
|
||||
|
|
@ -1,8 +1,7 @@
|
|||
---
|
||||
layout: blog
|
||||
title: "Kubernetes 1.32: Fresh Swap Features for Linux Users"
|
||||
date: 2025-01-15T10:00:00-08:00
|
||||
draft: true
|
||||
title: "Fresh Swap Features for Linux Users in Kubernetes 1.32"
|
||||
date: 2025-03-24T10:00:00-08:00
|
||||
slug: swap-linux-improvements
|
||||
author: >
|
||||
Itamar Holder (Red Hat)
|
||||
|
|
@ -33,9 +33,7 @@ presents a valid certificate signed by the cluster's certificate authority
|
|||
the username from the common name field in the 'subject' of the cert (e.g.,
|
||||
"/CN=bob"). From there, the role based access control (RBAC) sub-system would
|
||||
determine whether the user is authorized to perform a specific operation on a
|
||||
resource. For more details, refer to the normal users topic in
|
||||
[certificate request](/docs/reference/access-authn-authz/certificate-signing-requests/#normal-user)
|
||||
for more details about this.
|
||||
resource.
|
||||
|
||||
In contrast, service accounts are users managed by the Kubernetes API. They are
|
||||
bound to specific namespaces, and created automatically by the API server or
|
||||
|
|
@ -1815,5 +1813,6 @@ You can only make `SelfSubjectReview` requests if:
|
|||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* To learn about issuing certificates for users, read [Issue a Certificate for a Kubernetes API Client Using A CertificateSigningRequest](/docs/tasks/tls/certificate-issue-client-csr/)
|
||||
* Read the [client authentication reference (v1beta1)](/docs/reference/config-api/client-authentication.v1beta1/)
|
||||
* Read the [client authentication reference (v1)](/docs/reference/config-api/client-authentication.v1/)
|
||||
|
|
|
|||
|
|
@ -489,133 +489,10 @@ signer-unlinked ClusterTrustBundles **must not** contain a colon (`:`).
|
|||
The contents of ClusterTrustBundles can be injected into the container filesystem, similar to ConfigMaps and Secrets.
|
||||
See the [clusterTrustBundle projected volume source](/docs/concepts/storage/projected-volumes#clustertrustbundle) for more details.
|
||||
|
||||
<!-- TODO this should become a task page -->
|
||||
## How to issue a certificate for a user {#normal-user}
|
||||
|
||||
A few steps are required in order to get a normal user to be able to
|
||||
authenticate and invoke an API. First, this user must have a certificate issued
|
||||
by the Kubernetes cluster, and then present that certificate to the Kubernetes API.
|
||||
|
||||
### Create private key
|
||||
|
||||
The following scripts show how to generate PKI private key and CSR. It is
|
||||
important to set CN and O attribute of the CSR. CN is the name of the user and
|
||||
O is the group that this user will belong to. You can refer to
|
||||
[RBAC](/docs/reference/access-authn-authz/rbac/) for standard groups.
|
||||
|
||||
```shell
|
||||
openssl genrsa -out myuser.key 2048
|
||||
openssl req -new -key myuser.key -out myuser.csr -subj "/CN=myuser"
|
||||
```
|
||||
|
||||
### Create a CertificateSigningRequest {#create-certificatessigningrequest}
|
||||
|
||||
Create a [CertificateSigningRequest](/docs/reference/kubernetes-api/authentication-resources/certificate-signing-request-v1/)
|
||||
and submit it to a Kubernetes Cluster via kubectl. Below is a script to generate the
|
||||
CertificateSigningRequest.
|
||||
|
||||
```shell
|
||||
cat <<EOF | kubectl apply -f -
|
||||
apiVersion: certificates.k8s.io/v1
|
||||
kind: CertificateSigningRequest
|
||||
metadata:
|
||||
name: myuser
|
||||
spec:
|
||||
request: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0KTUlJQ1ZqQ0NBVDRDQVFBd0VURVBNQTBHQTFVRUF3d0dZVzVuWld4aE1JSUJJakFOQmdrcWhraUc5dzBCQVFFRgpBQU9DQVE4QU1JSUJDZ0tDQVFFQTByczhJTHRHdTYxakx2dHhWTTJSVlRWMDNHWlJTWWw0dWluVWo4RElaWjBOCnR2MUZtRVFSd3VoaUZsOFEzcWl0Qm0wMUFSMkNJVXBGd2ZzSjZ4MXF3ckJzVkhZbGlBNVhwRVpZM3ExcGswSDQKM3Z3aGJlK1o2MVNrVHF5SVBYUUwrTWM5T1Nsbm0xb0R2N0NtSkZNMUlMRVI3QTVGZnZKOEdFRjJ6dHBoaUlFMwpub1dtdHNZb3JuT2wzc2lHQ2ZGZzR4Zmd4eW8ybmlneFNVekl1bXNnVm9PM2ttT0x1RVF6cXpkakJ3TFJXbWlECklmMXBMWnoyalVnald4UkhCM1gyWnVVV1d1T09PZnpXM01LaE8ybHEvZi9DdS8wYk83c0x0MCt3U2ZMSU91TFcKcW90blZtRmxMMytqTy82WDNDKzBERHk5aUtwbXJjVDBnWGZLemE1dHJRSURBUUFCb0FBd0RRWUpLb1pJaHZjTgpBUUVMQlFBRGdnRUJBR05WdmVIOGR4ZzNvK21VeVRkbmFjVmQ1N24zSkExdnZEU1JWREkyQTZ1eXN3ZFp1L1BVCkkwZXpZWFV0RVNnSk1IRmQycVVNMjNuNVJsSXJ3R0xuUXFISUh5VStWWHhsdnZsRnpNOVpEWllSTmU3QlJvYXgKQVlEdUI5STZXT3FYbkFvczFqRmxNUG5NbFpqdU5kSGxpT1BjTU1oNndLaTZzZFhpVStHYTJ2RUVLY01jSVUyRgpvU2djUWdMYTk0aEpacGk3ZnNMdm1OQUxoT045UHdNMGM1dVJVejV4T0dGMUtCbWRSeEgvbUNOS2JKYjFRQm1HCkkwYitEUEdaTktXTU0xMzhIQXdoV0tkNjVoVHdYOWl4V3ZHMkh4TG1WQzg0L1BHT0tWQW9FNkpsYWFHdTlQVmkKdjlOSjVaZlZrcXdCd0hKbzZXdk9xVlA3SVFjZmg3d0drWm89Ci0tLS0tRU5EIENFUlRJRklDQVRFIFJFUVVFU1QtLS0tLQo=
|
||||
signerName: kubernetes.io/kube-apiserver-client
|
||||
expirationSeconds: 86400 # one day
|
||||
usages:
|
||||
- client auth
|
||||
EOF
|
||||
```
|
||||
|
||||
Some points to note:
|
||||
|
||||
- `usages` has to be '`client auth`'
|
||||
- `expirationSeconds` could be made longer (i.e. `864000` for ten days) or shorter (i.e. `3600` for one hour)
|
||||
- `request` is the base64 encoded value of the CSR file content.
|
||||
You can get the content using this command:
|
||||
|
||||
```shell
|
||||
cat myuser.csr | base64 | tr -d "\n"
|
||||
```
|
||||
|
||||
|
||||
### Approve the CertificateSigningRequest {#approve-certificate-signing-request}
|
||||
|
||||
Use kubectl to create a CSR and approve it.
|
||||
|
||||
Get the list of CSRs:
|
||||
|
||||
```shell
|
||||
kubectl get csr
|
||||
```
|
||||
|
||||
Approve the CSR:
|
||||
|
||||
```shell
|
||||
kubectl certificate approve myuser
|
||||
```
|
||||
|
||||
### Get the certificate
|
||||
|
||||
Retrieve the certificate from the CSR:
|
||||
|
||||
```shell
|
||||
kubectl get csr/myuser -o yaml
|
||||
```
|
||||
|
||||
The certificate value is in Base64-encoded format under `status.certificate`.
|
||||
|
||||
Export the issued certificate from the CertificateSigningRequest.
|
||||
|
||||
```shell
|
||||
kubectl get csr myuser -o jsonpath='{.status.certificate}'| base64 -d > myuser.crt
|
||||
```
|
||||
|
||||
### Create Role and RoleBinding
|
||||
|
||||
With the certificate created it is time to define the Role and RoleBinding for
|
||||
this user to access Kubernetes cluster resources.
|
||||
|
||||
This is a sample command to create a Role for this new user:
|
||||
|
||||
```shell
|
||||
kubectl create role developer --verb=create --verb=get --verb=list --verb=update --verb=delete --resource=pods
|
||||
```
|
||||
|
||||
This is a sample command to create a RoleBinding for this new user:
|
||||
|
||||
```shell
|
||||
kubectl create rolebinding developer-binding-myuser --role=developer --user=myuser
|
||||
```
|
||||
|
||||
### Add to kubeconfig
|
||||
|
||||
The last step is to add this user into the kubeconfig file.
|
||||
|
||||
First, you need to add new credentials:
|
||||
|
||||
```shell
|
||||
kubectl config set-credentials myuser --client-key=myuser.key --client-certificate=myuser.crt --embed-certs=true
|
||||
|
||||
```
|
||||
|
||||
Then, you need to add the context:
|
||||
|
||||
```shell
|
||||
kubectl config set-context myuser --cluster=kubernetes --user=myuser
|
||||
```
|
||||
|
||||
To test it, change the context to `myuser`:
|
||||
|
||||
```shell
|
||||
kubectl config use-context myuser
|
||||
```
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* Read [Manage TLS Certificates in a Cluster](/docs/tasks/tls/managing-tls-in-a-cluster/)
|
||||
* Read [Issue a Certificate for a Kubernetes API Client Using A CertificateSigningRequest](/docs/tasks/tls/certificate-issue-client-csr/)
|
||||
* View the source code for the kube-controller-manager built in
|
||||
[signer](https://github.com/kubernetes/kubernetes/blob/32ec6c212ec9415f604ffc1f4c1f29b782968ff1/pkg/controller/certificates/signer/cfssl_signer.go)
|
||||
* View the source code for the kube-controller-manager built in
|
||||
|
|
|
|||
|
|
@ -146,7 +146,7 @@ option. Your cluster requirements may need a different configuration.
|
|||
connection:
|
||||
|
||||
```shell
|
||||
nc -v <LOAD_BALANCER_IP> <PORT>
|
||||
nc -zv -w 2 <LOAD_BALANCER_IP> <PORT>
|
||||
```
|
||||
|
||||
A connection refused error is expected because the API server is not yet
|
||||
|
|
|
|||
|
|
@ -60,7 +60,7 @@ need to be open in order for Kubernetes components to communicate with each othe
|
|||
You can use tools like [netcat](https://netcat.sourceforge.net) to check if a port is open. For example:
|
||||
|
||||
```shell
|
||||
nc 127.0.0.1 6443 -v
|
||||
nc 127.0.0.1 6443 -zv -w 2
|
||||
```
|
||||
|
||||
The pod network plugin you use may also require certain ports to be
|
||||
|
|
|
|||
|
|
@ -0,0 +1,185 @@
|
|||
---
|
||||
title: Issue a Certificate for a Kubernetes API Client Using A CertificateSigningRequest
|
||||
api_metadata:
|
||||
- apiVersion: "certificates.k8s.io/v1"
|
||||
kind: "CertificateSigningRequest"
|
||||
override_link_text: "CSR v1"
|
||||
weight: 80
|
||||
|
||||
# Docs maintenance note
|
||||
#
|
||||
# If there is a future page /docs/tasks/tls/certificate-issue-client-manually/ then this page
|
||||
# should link there, and the new page should link back to this one.
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
Kubernetes lets you use a public key infrastructure (PKI) to authenticate to your cluster
|
||||
as a client.
|
||||
|
||||
A few steps are required in order to get a normal user to be able to
|
||||
authenticate and invoke an API. First, this user must have an [X.509](https://www.itu.int/rec/T-REC-X.509) certificate
|
||||
issued by an authority that your Kubernetes cluster trusts. The client must then present that certificate to the Kubernetes API.
|
||||
|
||||
You use a [CertificateSigningRequest](/concepts/security/certificate-signing-requests/)
|
||||
as part of this process, and either you or some other principal must approve the request.
|
||||
|
||||
|
||||
You will create a private key, and then get a certificate issued, and finally configure
|
||||
that private key for a client.
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
* {{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
* You need the `kubectl`, `openssl` and `base64` utilities.
|
||||
|
||||
This page assumes you are using Kubernetes {{< glossary_tooltip term_id="rbac" text="role based access control" >}} (RBAC).
|
||||
If you have alternative or additional security mechanisms around authorization, you need to account for those as well.
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Create private key
|
||||
|
||||
In this step, you create a private key. You need to keep this document secret; anyone who has it can impersonate the user.
|
||||
|
||||
```shell
|
||||
# Create a private key
|
||||
openssl genrsa -out myuser.key 3072
|
||||
```
|
||||
|
||||
## Create an X.509 certificate signing request {#create-x.509-certificatessigningrequest}
|
||||
|
||||
{{< note >}}
|
||||
This is not the same as the similarly-named CertificateSigningRequest API; the file you generate here goes into the
|
||||
CertificateSigningRequest.
|
||||
{{< /note >}}
|
||||
|
||||
It is important to set CN and O attribute of the CSR. CN is the name of the user and O is the group that this user will belong to.
|
||||
You can refer to [RBAC](/docs/reference/access-authn-authz/rbac/) for standard groups.
|
||||
|
||||
```shell
|
||||
# Change the common name "myuser" to the actual username that you want to use
|
||||
openssl req -new -key myuser.key -out myuser.csr -subj "/CN=myuser"
|
||||
```
|
||||
|
||||
## Create a Kubernetes CertificateSigningRequest {#create-k8s-certificatessigningrequest}
|
||||
|
||||
Encode the CSR document using this command:
|
||||
|
||||
```shell
|
||||
cat myuser.csr | base64 | tr -d "\n"
|
||||
```
|
||||
|
||||
Create a [CertificateSigningRequest](/docs/reference/kubernetes-api/authentication-resources/certificate-signing-request-v1/)
|
||||
and submit it to a Kubernetes Cluster via kubectl. Below is a snippet of shell that you can use to generate the
|
||||
CertificateSigningRequest.
|
||||
|
||||
```shell
|
||||
cat <<EOF | kubectl apply -f -
|
||||
apiVersion: certificates.k8s.io/v1
|
||||
kind: CertificateSigningRequest
|
||||
metadata:
|
||||
name: myuser # example
|
||||
spec:
|
||||
# This is an encoded CSR. Change this to the base64-encoded contents of myuser.csr
|
||||
request: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0KTUlJQ1ZqQ0NBVDRDQVFBd0VURVBNQTBHQTFVRUF3d0dZVzVuWld4aE1JSUJJakFOQmdrcWhraUc5dzBCQVFFRgpBQU9DQVE4QU1JSUJDZ0tDQVFFQTByczhJTHRHdTYxakx2dHhWTTJSVlRWMDNHWlJTWWw0dWluVWo4RElaWjBOCnR2MUZtRVFSd3VoaUZsOFEzcWl0Qm0wMUFSMkNJVXBGd2ZzSjZ4MXF3ckJzVkhZbGlBNVhwRVpZM3ExcGswSDQKM3Z3aGJlK1o2MVNrVHF5SVBYUUwrTWM5T1Nsbm0xb0R2N0NtSkZNMUlMRVI3QTVGZnZKOEdFRjJ6dHBoaUlFMwpub1dtdHNZb3JuT2wzc2lHQ2ZGZzR4Zmd4eW8ybmlneFNVekl1bXNnVm9PM2ttT0x1RVF6cXpkakJ3TFJXbWlECklmMXBMWnoyalVnald4UkhCM1gyWnVVV1d1T09PZnpXM01LaE8ybHEvZi9DdS8wYk83c0x0MCt3U2ZMSU91TFcKcW90blZtRmxMMytqTy82WDNDKzBERHk5aUtwbXJjVDBnWGZLemE1dHJRSURBUUFCb0FBd0RRWUpLb1pJaHZjTgpBUUVMQlFBRGdnRUJBR05WdmVIOGR4ZzNvK21VeVRkbmFjVmQ1N24zSkExdnZEU1JWREkyQTZ1eXN3ZFp1L1BVCkkwZXpZWFV0RVNnSk1IRmQycVVNMjNuNVJsSXJ3R0xuUXFISUh5VStWWHhsdnZsRnpNOVpEWllSTmU3QlJvYXgKQVlEdUI5STZXT3FYbkFvczFqRmxNUG5NbFpqdU5kSGxpT1BjTU1oNndLaTZzZFhpVStHYTJ2RUVLY01jSVUyRgpvU2djUWdMYTk0aEpacGk3ZnNMdm1OQUxoT045UHdNMGM1dVJVejV4T0dGMUtCbWRSeEgvbUNOS2JKYjFRQm1HCkkwYitEUEdaTktXTU0xMzhIQXdoV0tkNjVoVHdYOWl4V3ZHMkh4TG1WQzg0L1BHT0tWQW9FNkpsYWFHdTlQVmkKdjlOSjVaZlZrcXdCd0hKbzZXdk9xVlA3SVFjZmg3d0drWm89Ci0tLS0tRU5EIENFUlRJRklDQVRFIFJFUVVFU1QtLS0tLQo=
|
||||
signerName: kubernetes.io/kube-apiserver-client
|
||||
expirationSeconds: 86400 # one day
|
||||
usages:
|
||||
- client auth
|
||||
EOF
|
||||
```
|
||||
|
||||
Some points to note:
|
||||
|
||||
- `usages` has to be `client auth`
|
||||
- `expirationSeconds` could be made longer (i.e. `864000` for ten days) or shorter (i.e. `3600` for one hour).
|
||||
You cannot request a duration shorter than 10 minutes.
|
||||
- `request` is the base64 encoded value of the CSR file content.
|
||||
|
||||
## Approve the CertificateSigningRequest {#approve-certificate-signing-request}
|
||||
|
||||
Use kubectl to find the CSR you made, and manually approve it.
|
||||
|
||||
Get the list of CSRs:
|
||||
|
||||
```shell
|
||||
kubectl get csr
|
||||
```
|
||||
|
||||
Approve the CSR:
|
||||
|
||||
```shell
|
||||
kubectl certificate approve myuser
|
||||
```
|
||||
|
||||
## Get the certificate
|
||||
|
||||
Retrieve the certificate from the CSR, to check it looks OK.
|
||||
|
||||
```shell
|
||||
kubectl get csr/myuser -o yaml
|
||||
```
|
||||
|
||||
The certificate value is in Base64-encoded format under `.status.certificate`.
|
||||
|
||||
Export the issued certificate from the CertificateSigningRequest.
|
||||
|
||||
```shell
|
||||
kubectl get csr myuser -o jsonpath='{.status.certificate}'| base64 -d > myuser.crt
|
||||
```
|
||||
|
||||
## Configure the certificate into kubeconfig
|
||||
|
||||
The next step is to add this user into the kubeconfig file.
|
||||
|
||||
First, you need to add new credentials:
|
||||
|
||||
```shell
|
||||
kubectl config set-credentials myuser --client-key=myuser.key --client-certificate=myuser.crt --embed-certs=true
|
||||
|
||||
```
|
||||
|
||||
Then, you need to add the context:
|
||||
|
||||
```shell
|
||||
kubectl config set-context myuser --cluster=kubernetes --user=myuser
|
||||
```
|
||||
|
||||
To test it:
|
||||
|
||||
```shell
|
||||
kubectl --context myuser auth whoami
|
||||
```
|
||||
|
||||
You should see output confirming that you are “myuser“.
|
||||
|
||||
## Create Role and RoleBinding
|
||||
|
||||
{{< note >}}
|
||||
If you don't use Kubernetes RBAC, skip this step and make the appropriate changes for the authorization mechanism
|
||||
your cluster actually uses.
|
||||
{{< /note >}}
|
||||
|
||||
With the certificate created it is time to define the Role and RoleBinding for
|
||||
this user to access Kubernetes cluster resources.
|
||||
|
||||
This is a sample command to create a Role for this new user:
|
||||
|
||||
```shell
|
||||
kubectl create role developer --verb=create --verb=get --verb=list --verb=update --verb=delete --resource=pods
|
||||
```
|
||||
|
||||
This is a sample command to create a RoleBinding for this new user:
|
||||
|
||||
```shell
|
||||
kubectl create rolebinding developer-binding-myuser --role=developer --user=myuser
|
||||
```
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* Read [Manage TLS Certificates in a Cluster](/docs/tasks/tls/managing-tls-in-a-cluster/)
|
||||
* For details of X.509 itself, refer to [RFC 5280](https://tools.ietf.org/html/rfc5280#section-3.1) section 3.1
|
||||
* For information on the syntax of PKCS#10 certificate signing requests, refer to [RFC 2986](https://tools.ietf.org/html/rfc2986)
|
||||
* Read about [ClusterTrustBundles](/docs/reference/access-authn-authz/certificate-signing-requests/#cluster-trust-bundles)
|
||||
|
|
@ -5,4 +5,5 @@ cluster, you can create one by using
|
|||
or you can use one of these Kubernetes playgrounds:
|
||||
|
||||
* [Killercoda](https://killercoda.com/playgrounds/scenario/kubernetes)
|
||||
* [KodeKloud](https://kodekloud.com/public-playgrounds)
|
||||
* [Play with Kubernetes](https://labs.play-with-k8s.com/)
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ In the summer of 2014, Box was feeling the pain of a decade's worth of hardware
|
|||
|
||||
<p>Box's cloud native journey accelerated that June, when Ghods attended <a href="https://www.docker.com/events/dockercon">DockerCon</a>. The company had come to the realization that it could no longer run its applications only off bare metal, and was researching containerizing with Docker, virtualizing with OpenStack, and supporting public cloud.</p>
|
||||
|
||||
<p>At that conference, Google announced the release of its Kubernetes container management system, and Ghods was won over. "We looked at a lot of different options, but Kubernetes really stood out, especially because of the incredibly strong team of <a href="https://research.google.com/pubs/pub43438.html">Borg</a> veterans and the vision of having a completely infrastructure-agnostic way of being able to run cloud software," he says, referencing Google's internal container orchestrator Borg. "The fact that on day one it was designed to run on bare metal just as well as <a href="https://cloud.google.com/">Google Cloud</a> meant that we could actually migrate to it inside of our data centers, and then use those same tools and concepts to run across public cloud providers as well."</p>
|
||||
<p>At that conference, Google announced the release of its Kubernetes container management system, and Ghods was won over. "We looked at a lot of different options, but Kubernetes really stood out, especially because of the incredibly strong team of <a href="https://research.google/pubs/large-scale-cluster-management-at-google-with-borg/">Borg</a> veterans and the vision of having a completely infrastructure-agnostic way of being able to run cloud software," he says, referencing Google's internal container orchestrator Borg. "The fact that on day one it was designed to run on bare metal just as well as <a href="https://cloud.google.com/">Google Cloud</a> meant that we could actually migrate to it inside of our data centers, and then use those same tools and concepts to run across public cloud providers as well."</p>
|
||||
|
||||
<p>Another plus: Ghods liked that <a href="https://kubernetes.io/">Kubernetes</a> has a universal set of API objects like pod, service, replica set and deployment object, which created a consistent surface to build tooling against. "Even PaaS layers like <a href="https://www.openshift.com/">OpenShift</a> or <a href="http://deis.io/">Deis</a> that build on top of Kubernetes still treat those objects as first-class principles," he says. "We were excited about having these abstractions shared across the entire ecosystem, which would result in a lot more momentum than we saw in other potential solutions."</p>
|
||||
|
||||
|
|
|
|||
|
|
@ -345,7 +345,7 @@ _프로브_는 컨테이너의 kubelet에 의해 주기적으로 실행되는
|
|||
쿠버네티스가 다른 리소스({{< glossary_tooltip text="스테이트풀셋" term_id="statefulset" >}}이나 {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}}와 같은)에서 공통 파드 API를 래핑하는 이유에 대한 콘텍스트를 이해하기 위해서, 다음과 같은 선행 기술에 대해 읽어볼 수 있다.
|
||||
|
||||
* [Aurora](https://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)
|
||||
* [Borg](https://research.google.com/pubs/pub43438.html)
|
||||
* [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html)
|
||||
* [Borg](https://research.google/pubs/large-scale-cluster-management-at-google-with-borg/)
|
||||
* [Marathon](https://github.com/d2iq-archive/marathon)
|
||||
* [Omega](https://research.google/pubs/pub41684/)
|
||||
* [Tupperware](https://engineering.fb.com/data-center-engineering/tupperware/).
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ weight: 30
|
|||
|
||||
이 가이드는 [Kubespray](https://github.com/kubernetes-sigs/kubespray)를 이용하여 GCE, Azure, OpenStack, AWS, vSphere, Equinix Metal(전 Packet), Oracle Cloud infrastructure(실험적) 또는 베어메탈 등에서 운영되는 쿠버네티스 클러스터를 설치하는 과정을 보여준다.
|
||||
|
||||
Kubespray는 [Ansible](https://docs.ansible.com/) 플레이북, [인벤토리](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md#inventory), 프로비저닝 도구와 일반적인 운영체제, 쿠버네티스 클러스터의 설정 관리 작업에 대한 도메인 지식의 결합으로 만들어졌다. Kubespray는 아래와 같은 기능을 제공한다.
|
||||
Kubespray는 [Ansible](https://docs.ansible.com/) 플레이북, [인벤토리](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible/inventory.md), 프로비저닝 도구와 일반적인 운영체제, 쿠버네티스 클러스터의 설정 관리 작업에 대한 도메인 지식의 결합으로 만들어졌다. Kubespray는 아래와 같은 기능을 제공한다.
|
||||
|
||||
Kubespray 지원 사항
|
||||
* 고가용성을 지닌 클러스터
|
||||
|
|
|
|||
|
|
@ -68,7 +68,6 @@ CNCF 프로젝트가 아닌 완전한 메트릭 파이프라인 프로젝트는
|
|||
다음과 같은 추가 디버깅 도구에 대해 더 알아본다.
|
||||
|
||||
* [로깅](/ko/docs/concepts/cluster-administration/logging/)
|
||||
* [모니터링](/ko/docs/tasks/debug/debug-cluster/resource-usage-monitoring/)
|
||||
* [`exec`를 통해 컨테이너에 접속하기](/ko/docs/tasks/debug/debug-application/get-shell-running-container/)
|
||||
* [프록시를 통해 컨테이너에 연결하기](/ko/docs/tasks/extend-kubernetes/http-proxy-access-api/)
|
||||
* [포트 포워딩을 사용해서 클러스터 내 애플리케이션에 접근하기](/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)
|
||||
|
|
|
|||
|
|
@ -0,0 +1,218 @@
|
|||
---
|
||||
title: Typy treści
|
||||
content_type: concept
|
||||
weight: 80
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
Dokumentacja Kubernetesa obejmuje kilka typów treści stron:
|
||||
|
||||
- Pojęcia i koncepcje (ang. Concept)
|
||||
- Zadanie (ang. Task)
|
||||
- Samouczek (ang. Tutorial)
|
||||
- Materiały źródłowe (ang. Reference)
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Sekcje treści {#content-sections}
|
||||
|
||||
Każdy typ strony zawiera szereg sekcji zdefiniowanych przez
|
||||
komentarze Markdown i nagłówki HTML. Możesz dodać nagłówki
|
||||
do swojej strony za pomocą kodu `heading`. Komentarze i
|
||||
nagłówki pomagają utrzymać odpowiednią strukturę strony dla danego typu.
|
||||
|
||||
Przykłady komentarzy w Markdown definiujących sekcje strony:
|
||||
|
||||
```markdown
|
||||
<!-- overview -->
|
||||
```
|
||||
|
||||
```markdown
|
||||
<!-- body -->
|
||||
```
|
||||
|
||||
Aby utworzyć typowe nagłówki na swoich
|
||||
stronach, użyj kodu `heading` z nazwą nagłówka.
|
||||
|
||||
Przykłady nazw nagłówków:
|
||||
|
||||
- whatsnext - co dalej
|
||||
- prerequisites - wymagania wstępne
|
||||
- objectives - cele
|
||||
- cleanup - sprzątanie
|
||||
- synopsis - streszczenie
|
||||
- seealso - zobacz także
|
||||
- options - opcje
|
||||
|
||||
Na przykład, aby utworzyć nagłówek `whatsnext`, dodaj kod nagłówka z nazwą "whatsnext":
|
||||
|
||||
```none
|
||||
## {{%/* heading "whatsnext" */%}}
|
||||
```
|
||||
|
||||
Możesz zadeklarować nagłówek `prerequisites` w następujący sposób:
|
||||
|
||||
```none
|
||||
## {{%/* heading "prerequisites" */%}}
|
||||
```
|
||||
|
||||
Kod `heading` oczekuje jednego parametru typu
|
||||
string. Ten parametr nagłówka odpowiada prefiksowi zmiennej
|
||||
w plikach `i18n/<lang>.toml`. Na przykład:
|
||||
|
||||
`` `i18n/en.toml`:` ``
|
||||
|
||||
```toml
|
||||
[whatsnext_heading]
|
||||
other = "What's next"
|
||||
```
|
||||
|
||||
`i18n/ko.toml`:
|
||||
|
||||
```toml
|
||||
[whatsnext_heading]
|
||||
other = "다음 내용"
|
||||
```
|
||||
|
||||
## Typy zawartości {#content-types}
|
||||
|
||||
Każdy typ zawartości nieformalnie definiuje swoją oczekiwaną strukturę
|
||||
strony. Twórz zawartość strony, korzystając z sugerowanych sekcji strony.
|
||||
|
||||
### Pojęcie (ang. Concept) {#concept}
|
||||
|
||||
Strona z pojęciami wyjaśnia określony aspekt Kubernetesa. Na
|
||||
przykład, strona koncepcyjna może opisywać obiekt Deployment w
|
||||
Kubernetesie i wyjaśniać jego rolę jako aplikacji po wdrożeniu,
|
||||
skalowaniu i aktualizacji. Zazwyczaj strony koncepcyjne nie
|
||||
zawierają instrukcji krok po kroku, lecz odsyłają do zadań lub samouczków.
|
||||
|
||||
Aby napisać nową stronę z pojęciem, utwórz plik Markdown w
|
||||
podkatalogu katalogu `/content/en/docs/concepts`, z następującymi sekcjami:
|
||||
|
||||
Strony koncepcyjne są podzielone na trzy sekcje:
|
||||
|
||||
| Sekcja strony |
|
||||
|------------------------------|
|
||||
| overview - przegląd |
|
||||
| body - treść |
|
||||
| whatsnext - co dalej |
|
||||
|
||||
Sekcje `overview` i `body` pojawiają się jako komentarze na stronie z
|
||||
koncepcjami. Możesz dodać sekcję `whatsnext` do swojej strony za pomocą kodu `heading`.
|
||||
|
||||
Wypełnij każdą sekcję treścią. Postępuj zgodnie z tymi wytycznymi:
|
||||
|
||||
- Organizuj treści za pomocą nagłówków H2 i H3.
|
||||
- Dla `overview`, ustaw kontekst tematu za pomocą pojedynczego akapitu.
|
||||
- Dla `body` wyjaśnij koncepcję.
|
||||
- Dla `whatsnext`, podaj wypunktowaną listę tematów (maksymalnie 5), aby dowiedzieć się więcej o koncepcji.
|
||||
|
||||
Strona [adnotacje](/docs/concepts/overview/working-with-objects/annotations/) jest opublikowanym przykładem strony koncepcyjnej.
|
||||
|
||||
### Zadanie (ang. Task) {#task}
|
||||
|
||||
Strony opisujące wykonywanie zadań zawierają minimum
|
||||
wyjaśnień, ale zwykle podają odnośniki do
|
||||
dokumentacji objaśniającej pojęcia i szerszy kontekst danego tematu.
|
||||
|
||||
Aby napisać nową stronę zadania, utwórz plik Markdown w
|
||||
podkatalogu katalogu `/content/en/docs/tasks`, z następującymi sekcjami:
|
||||
|
||||
| Sekcja strony |
|
||||
|------------------------------|
|
||||
| overview - przegląd |
|
||||
| prerequisites - wymagania wstępne |
|
||||
| steps - kroki |
|
||||
| discussion - dyskusja |
|
||||
| whatsnext - co dalej |
|
||||
|
||||
Sekcje `overview`, `steps` i `discussion` pojawiają się jako komentarze
|
||||
na stronie zadania. Możesz dodać sekcje
|
||||
`prerequisites` i `whatsnext` do swojej strony za pomocą kodu `heading`.
|
||||
|
||||
Każdą sekcję uzupełnij treścią. Użyj następujących wytycznych:
|
||||
|
||||
- Użyj nagłówków poziomu H2 lub niższego (z dwoma wiodącymi
|
||||
znakami `#`). Sekcje są automatycznie tytułowane przez szablon.
|
||||
- Dla `overview` użyj akapitu, aby ustawić kontekst dla całego tematu.
|
||||
- Dla `prerequisites` używaj list punktowanych, kiedy to możliwe. Zaczynaj dodawać dodatkowe
|
||||
wymagania wstępne poniżej `include`. Domyślne wymagania wstępne obejmują działający klaster Kubernetes.
|
||||
- Dla `steps` używaj numerowanych list.
|
||||
- Do omówienia użyj standardowej treści, aby rozwinąć
|
||||
informacje zawarte w sekcji `steps`.
|
||||
- Dla `whatsnext`, podaj listę punktowaną z maksymalnie 5 tematami,
|
||||
które mogą zainteresować czytelnika jako kolejne tematy do przeczytania.
|
||||
|
||||
Przykład opublikowanego tematu zadania to [Korzystanie z proxy HTTP do uzyskania dostępu do API Kubernetesa](/docs/tasks/extend-kubernetes/http-proxy-access-api/).
|
||||
|
||||
### Samouczek (ang. Tutorial) {#tutorial}
|
||||
|
||||
Strona samouczka pokazuje, jak osiągnąć cel, który jest bardziej złożony
|
||||
niż pojedyncze zadanie. Zazwyczaj strona samouczka składa się z kilku
|
||||
sekcji, z których każda zawiera sekwencję kroków. Na przykład samouczek może
|
||||
przeprowadzać użytkownika przez przykładowy kod ilustrujący określoną
|
||||
funkcję Kubernetesa. Samouczki mogą zawierać ogólne wyjaśnienia, ale powinny
|
||||
odsyłać do powiązanych tematów koncepcyjnych w celu dogłębnego omówienia zagadnienia.
|
||||
|
||||
Aby napisać nową stronę samouczka, utwórz plik Markdown w
|
||||
podkatalogu katalogu `/content/en/docs/tutorials`, z następującymi sekcjami:
|
||||
|
||||
| Sekcja strony |
|
||||
|------------------------------|
|
||||
| overview - przegląd |
|
||||
| prerequisites - wymagania wstępne |
|
||||
| objectives - cele |
|
||||
| lessoncontent - treść lekcji |
|
||||
| cleanup - sprzątanie |
|
||||
| whatsnext - co dalej |
|
||||
|
||||
Sekcje `overview`, `objectives` i `lessoncontent` pojawiają się
|
||||
jako komentarze na stronie samouczka. Możesz dodać sekcje
|
||||
`prerequisites`, `cleanup` i `whatsnext` do swojej strony za pomocą kodu `heading`.
|
||||
|
||||
Każdą sekcję uzupełnij treścią. Użyj następujących wytycznych:
|
||||
|
||||
- Użyj nagłówków poziomu H2 lub niższego (z dwoma wiodącymi
|
||||
znakami `#`). Sekcje są automatycznie tytułowane przez szablon.
|
||||
- Dla `overview` użyj akapitu, aby ustawić kontekst dla całego tematu.
|
||||
- W przypadku `prerequisites` używaj, jeśli to możliwe, list
|
||||
punktowanych. Dodaj dodatkowe wymagania wstępne poniżej tych domyślnie uwzględnionych.
|
||||
- Dla `objectives`, używaj list wypunktowanych.
|
||||
- Dla `lessoncontent`, użyj mieszanki list
|
||||
numerowanych i treści narracyjnej w zależności od potrzeb.
|
||||
- W przypadku `cleanup`, użyj numerowanych list, aby opisać
|
||||
kroki niezbędne do posprzątania stanu klastra po zakończeniu zadania.
|
||||
- Dla `whatsnext`, podaj listę punktowaną z maksymalnie 5 tematami,
|
||||
które mogą zainteresować czytelnika jako kolejne tematy do przeczytania.
|
||||
|
||||
Przykładem opublikowanego tematu samouczka jest
|
||||
[Uruchamianie aplikacji bezstanowej przy użyciu Deployment](/docs/tasks/run-application/run-stateless-application-deployment/).
|
||||
|
||||
### Materiały źródłowe (ang. Reference) {#reference}
|
||||
|
||||
Każde narzędzie Kubernetesa ma swoją stronę materiałów źródłowych (ang. reference page), gdzie można znaleźć jego opis i
|
||||
listę dostępnych opcji. Dokumentacja ta jest generowana przez skrypty, które automatycznie pobierają informacje z poleceń narzędzia.
|
||||
|
||||
Strona z odniesieniem do narzędzia ma kilka możliwych sekcji:
|
||||
|
||||
| Sekcja strony |
|
||||
|------------------------------|
|
||||
| streszczenie |
|
||||
| opcje |
|
||||
| opcje z nadrzędnych poleceń |
|
||||
| przykłady |
|
||||
| zobacz także |
|
||||
|
||||
Przykłady opublikowanych stron referencyjnych narzędzi to:
|
||||
|
||||
- [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/)
|
||||
- [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/)
|
||||
- [kubectl](/docs/reference/kubectl/kubectl/)
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
- Dowiedz się więcej o [Przewodniku stylu](/docs/contribute/style/style-guide/)
|
||||
- Dowiedz się więcej o [Przewodniku treści](/docs/contribute/style/content-guide/)
|
||||
- Dowiedz się więcej o [organizacji treści](/docs/contribute/style/content-organization/)
|
||||
|
|
@ -3,48 +3,64 @@ title: "Instale as ferramentas"
|
|||
description: Configure as ferramentas do Kubernetes no seu computador.
|
||||
weight: 10
|
||||
no_list: true
|
||||
card:
|
||||
name: tasks
|
||||
weight: 20
|
||||
anchors:
|
||||
- anchor: "#kubectl"
|
||||
title: Instale o kubectl
|
||||
---
|
||||
|
||||
## kubectl
|
||||
|
||||
<!-- overview -->
|
||||
A ferramenta de linha de comando do Kubernetes, [kubectl](/docs/reference/kubectl/kubectl/), permite que você execute comandos nos clusters Kubernetes.
|
||||
Você pode usar o kubectl para instalar aplicações, inspecionar e gerenciar recursos de cluster e visualizar os logs.
|
||||
Para obter mais informações, incluindo uma lista completa de operações kubectl, consulte a [documentação de referência `kubectl`](/docs/reference/kubectl/).
|
||||
A ferramenta de linha de comando do Kubernetes, [kubectl](/docs/reference/kubectl/kubectl/),
|
||||
permite que você execute comandos nos clusters Kubernetes.
|
||||
Você pode usar o kubectl para instalar aplicações, inspecionar e gerenciar recursos
|
||||
de cluster e visualizar os logs.
|
||||
Para obter mais informações, incluindo uma lista completa de operações kubectl,
|
||||
consulte a [documentação de referência do `kubectl`](/docs/reference/kubectl/).
|
||||
|
||||
Kubectl é instalável em uma variedade de plataformas tais como Linux, macOS e Windows.
|
||||
Kubectl é instalável em uma variedade de plataformas Linux, macOS e Windows.
|
||||
Encontre seu sistema operacional preferido abaixo.
|
||||
|
||||
- [Instale o kubectl no Linux](/pt-br/docs/tasks/tools/install-kubectl-linux)
|
||||
- [Instale o kubectl no Linux](/docs/tasks/tools/install-kubectl-linux)
|
||||
- [Instale o kubectl no macOS](/docs/tasks/tools/install-kubectl-macos)
|
||||
- [Instale o kubectl no Windows](/docs/tasks/tools/install-kubectl-windows)
|
||||
|
||||
## kind
|
||||
|
||||
O [`kind`](https://kind.sigs.k8s.io/) permite que você execute o Kubernetes no seu computador local.
|
||||
Esta ferramenta requer que você tenha o [Docker](https://docs.docker.com/get-docker/) instalado e configurado.
|
||||
O [`kind`](https://kind.sigs.k8s.io/) permite que você execute o Kubernetes no
|
||||
seu computador local. Esta ferramenta requer que você tenha o
|
||||
[Docker](https://docs.docker.com/get-docker/) instalado e configurado.
|
||||
|
||||
A página de [Início Rápido](https://kind.sigs.k8s.io/docs/user/quick-start/) mostra o que você precisa fazer para começar a trabalhar com o `kind`.
|
||||
A página de [Início Rápido](https://kind.sigs.k8s.io/docs/user/quick-start/) mostra
|
||||
o que você precisa fazer para começar a trabalhar com o `kind`.
|
||||
|
||||
<a class="btn btn-primary" href="https://kind.sigs.k8s.io/docs/user/quick-start/" role="button" aria-label="Acesse o guia de início rápido do kind">Acesse o guia de início rápido do kind</a>
|
||||
|
||||
## minikube
|
||||
|
||||
Assim como o `kind`, o [`minikube`](https://minikube.sigs.k8s.io/) é uma ferramenta que permite executar o Kubernetes localmente.
|
||||
O `minikube` executa um cluster Kubernetes local com tudo-em-um ou com vários nós no seu computador pessoal (incluindo PCs Windows, macOS e Linux) para que você possa experimentar o Kubernetes ou para o trabalho de desenvolvimento diário.
|
||||
Assim como o `kind`, o [`minikube`](https://minikube.sigs.k8s.io/) é uma ferramenta
|
||||
que permite executar o Kubernetes localmente. O `minikube` executa um cluster Kubernetes
|
||||
local tudo-em-um ou com vários nós no seu computador pessoal
|
||||
(incluindo PCs Windows, macOS e Linux) para que você possa experimentar o Kubernetes
|
||||
ou para o trabalho de desenvolvimento diário.
|
||||
|
||||
Você pode seguir o [guia de início oficial](https://minikube.sigs.k8s.io/docs/start/) se o seu foco é instalar a ferramenta.
|
||||
Você pode seguir o [guia de início oficial](https://minikube.sigs.k8s.io/docs/start/)
|
||||
se o seu foco é instalar a ferramenta.
|
||||
|
||||
<a class="btn btn-primary" href="https://minikube.sigs.k8s.io/docs/start/" role="button" aria-label="Acesse o guia de início">Acesse o guia de início</a>
|
||||
|
||||
Depois de instalar o `minikube`, você pode usá-lo para executar uma [aplicação exemplo](/pt-br/docs/tutorials/hello-minikube/).
|
||||
Depois de instalar o `minikube`, você pode usá-lo para [executar uma aplicação de exemplo](/pt-br/docs/tutorials/hello-minikube/).
|
||||
|
||||
## kubeadm
|
||||
|
||||
Você pode usar a ferramenta {{< glossary_tooltip term_id="kubeadm" text="kubeadm" >}} para criar e gerenciar clusters Kubernetes.
|
||||
Ela executa as ações necessárias para obter um cluster mínimo viável e seguro em funcionamento de maneira amigável ao usuário.
|
||||
Você pode usar a ferramenta {{< glossary_tooltip term_id="kubeadm" text="kubeadm" >}}
|
||||
para criar e gerenciar clusters Kubernetes. Esta ferramenta executa as ações necessárias
|
||||
para obter um cluster mínimo viável e seguro em funcionamento de maneira amigável ao usuário.
|
||||
|
||||
[Instalando a ferramenta kubeadm](/pt-br/docs/setup/production-environment/tools/kubeadm/install-kubeadm/) mostra como instalar o kubeadm.
|
||||
[Instalando a ferramenta kubeadm](/pt-br/docs/setup/production-environment/tools/kubeadm/install-kubeadm/) mostra como instalar o kubeadm.
|
||||
Uma vez instalado, você pode usá-lo para [criar um cluster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/).
|
||||
|
||||
<a class="btn btn-primary" href="/pt-br/docs/setup/production-environment/tools/kubeadm/install-kubeadm/" role="button" aria-label="Acesse o guia instalando a ferramenta kubeadm">Acesse o guia instalando a ferramenta kubeadm</a>
|
||||
|
|
|
|||
|
|
@ -2,10 +2,6 @@
|
|||
title: Instale e configure o kubectl no Linux
|
||||
content_type: task
|
||||
weight: 10
|
||||
card:
|
||||
name: tasks
|
||||
weight: 20
|
||||
title: Install kubectl on Linux
|
||||
---
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
|
|
|||
|
|
@ -0,0 +1,32 @@
|
|||
---
|
||||
linktitle: Lịch sử phát hành các phiên bản
|
||||
title: Phát hành phiên bản
|
||||
type: docs
|
||||
layout: release-info
|
||||
notoc: true
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
Kubernetes duy trì các nhánh phát hành cho ba bản phát hành phụ gần đây nhất: ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}).
|
||||
|
||||
Kubernetes phiên bản 1.19 trở lên sẽ nhận được hỗ trợ bản vá trong [khoảng một năm](/releases/patch-releases/#support-period).
|
||||
Các phiên bản Kubernetes trước 1.18 được hỗ trợ bản vá trong khoảng chín tháng.
|
||||
|
||||
Phiên bản Kubernetes được biểu thị dưới dạng **x.y.z**.
|
||||
Ở đây, **x** chỉ phiên bản chính (major), **y** chỉ phiên bản phụ (minor) và **z** chỉ phiên bản vá (patch), theo thuật ngữ Phiên bản ngữ nghĩa.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Lịch sử phát hành các phiên bản
|
||||
|
||||
{{< release-data >}}
|
||||
|
||||
## Lịch phát hành các phiên bản tiếp theo
|
||||
|
||||
Tham khảo [lịch phát hành](https://github.com/kubernetes/sig-release/tree/master/releases/release-{{< skew nextMinorVersion >}}) để biết thêm về phiên bản **{{< skew nextMinorVersion >}}** phát hành sắp tới của Kubernetes!
|
||||
|
||||
## Thông tin liên hệ
|
||||
|
||||
Tham khảo thêm về [Nhóm phát hành Kubernetes](https://github.com/kubernetes/sig-release/tree/master/release-team)
|
||||
để biết thêm thông tin về vai trò và quy trình phát hành.
|
||||
|
|
@ -196,7 +196,7 @@ Message: Pod was terminated in response to imminent node shutdown.
|
|||
To provide more flexibility during graceful node shutdown around the ordering
|
||||
of pods during shutdown, graceful node shutdown honors the PriorityClass for
|
||||
Pods, provided that you enabled this feature in your cluster. The feature
|
||||
allows cluster administers to explicitly define the ordering of pods
|
||||
allows cluster administrators to explicitly define the ordering of pods
|
||||
during graceful node shutdown based on
|
||||
[priority classes](/docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass).
|
||||
-->
|
||||
|
|
|
|||
|
|
@ -868,7 +868,7 @@ common use cases and suggested solutions.
|
|||
- Or, run an internal private registry behind your firewall with open read access.
|
||||
- No Kubernetes configuration is required.
|
||||
- Use a hosted container image registry service that controls image access
|
||||
- It will work better with cluster autoscaling than manual node configuration.
|
||||
- It will work better with Node autoscaling than manual node configuration.
|
||||
- Or, on a cluster where changing the node configuration is inconvenient, use `imagePullSecrets`.
|
||||
-->
|
||||
2. 集群运行一些专有镜像，这些镜像需要对公司外部隐藏，对所有集群用户可见
|
||||
|
|
@ -877,7 +877,7 @@ common use cases and suggested solutions.
|
|||
- 或者，在防火墙内运行一个组织内部的私有仓库，并开放读取权限
|
||||
- 不需要配置 Kubernetes
|
||||
- 使用控制镜像访问的托管容器镜像仓库服务
|
||||
- 与手动配置节点相比，这种方案能更好地处理集群自动扩缩容
|
||||
- 与手动配置节点相比，这种方案能更好地处理节点自动扩缩容
|
||||
- 或者，在不方便更改节点配置的集群中，使用 `imagePullSecrets`
|
||||
|
||||
<!--
|
||||
|
|
|
|||
|
|
@ -234,7 +234,7 @@ Pod 的入站流量还是来自所选 Pod 的出站流量，或两者兼有。
|
|||
指定，第二个通过 `namespaceSelector` 指定，第三个通过 `podSelector` 指定。
|
||||
|
||||
**egress**：每个 NetworkPolicy 可包含一个 `egress` 规则的白名单列表。
|
||||
每个规则都允许匹配 `to` 和 `port` 部分的流量。该示例策略包含一条规则，
|
||||
每个规则都允许匹配 `to` 和 `ports` 部分的流量。该示例策略包含一条规则，
|
||||
该规则将指定端口上的流量匹配到 `10.0.0.0/24` 中的任何目的地。
|
||||
|
||||
<!--
|
||||
|
|
|
|||
|
|
@ -82,7 +82,7 @@ CertificateSigningRequest 资源类型允许客户端基于签名请求申请发
|
|||
CertificateSigningRequest 对象在 `spec.request` 字段中包含一个 PEM 编码的 PKCS#10 签名请求。
|
||||
CertificateSigningRequest 使用 `spec.signerName` 字段标示签名者（请求的接收方）。
|
||||
注意，`spec.signerName` 在 `certificates.k8s.io/v1` 之后的 API 版本是必填项。
|
||||
在 Kubernetes v1.22 和以后的版本，客户可以设置 `spec.expirationSeconds`
|
||||
在 Kubernetes v1.22 及更高版本中，客户可以设置 `spec.expirationSeconds`
|
||||
字段（可选）来为颁发的证书设定一个特定的有效期。该字段的最小有效值是 `600`，也就是 10 分钟。
|
||||
|
||||
<!--
|
||||
|
|
@ -878,206 +878,11 @@ See the [clusterTrustBundle projected volume source](/docs/concepts/storage/proj
|
|||
ClusterTrustBundle 的内容可以注入到容器文件系统，这与 ConfigMap 和 Secret 类似。
|
||||
更多细节参阅 [ClusterTrustBundle 投射卷源](/zh-cn/docs/concepts/storage/projected-volumes#clustertrustbundle)。
|
||||
|
||||
<!-- TODO this should become a task page -->
|
||||
|
||||
<!--
|
||||
## How to issue a certificate for a user {#normal-user}
|
||||
|
||||
A few steps are required in order to get a normal user to be able to
|
||||
authenticate and invoke an API. First, this user must have a certificate issued
|
||||
by the Kubernetes cluster, and then present that certificate to the Kubernetes API.
|
||||
-->
|
||||
## 如何为用户签发证书 {#normal-user}
|
||||
|
||||
为了让普通用户能够通过认证并调用 API，需要执行几个步骤。
|
||||
首先，该用户必须拥有 Kubernetes 集群签发的证书，
|
||||
然后将该证书提供给 Kubernetes API。
|
||||
|
||||
<!--
|
||||
### Create private key
|
||||
|
||||
The following scripts show how to generate PKI private key and CSR. It is
|
||||
important to set CN and O attribute of the CSR. CN is the name of the user and
|
||||
O is the group that this user will belong to. You can refer to
|
||||
[RBAC](/docs/reference/access-authn-authz/rbac/) for standard groups.
|
||||
-->
|
||||
### 创建私钥 {#create-private-key}
|
||||
|
||||
下面的脚本展示了如何生成 PKI 私钥和 CSR。
|
||||
设置 CSR 的 CN 和 O 属性很重要。CN 是用户名，O 是该用户归属的组。
|
||||
你可以参考 [RBAC](/zh-cn/docs/reference/access-authn-authz/rbac/) 了解标准组的信息。
|
||||
|
||||
```shell
|
||||
openssl genrsa -out myuser.key 2048
|
||||
openssl req -new -key myuser.key -out myuser.csr -subj "/CN=myuser"
|
||||
```
|
||||
|
||||
<!--
|
||||
### Create a CertificateSigningRequest {#create-certificatessigningrequest}
|
||||
|
||||
Create a [CertificateSigningRequest](/docs/reference/kubernetes-api/authentication-resources/certificate-signing-request-v1/)
|
||||
and submit it to a Kubernetes Cluster via kubectl. Below is a script to generate the
|
||||
CertificateSigningRequest. a CertificateSigningRequest and submit it to a Kubernetes Cluster via kubectl. Below is a script to generate the CertificateSigningRequest.
|
||||
-->
|
||||
### 创建 CertificateSigningRequest {#create-certificatesigningrequest}
|
||||
|
||||
创建一个 [CertificateSigningRequest](/zh-cn/docs/reference/kubernetes-api/authentication-resources/certificate-signing-request-v1/)，
|
||||
并通过 kubectl 将其提交到 Kubernetes 集群。
|
||||
下面是生成 CertificateSigningRequest 的脚本。
|
||||
|
||||
```shell
|
||||
cat <<EOF | kubectl apply -f -
|
||||
apiVersion: certificates.k8s.io/v1
|
||||
kind: CertificateSigningRequest
|
||||
metadata:
|
||||
name: myuser
|
||||
spec:
|
||||
request: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0KTUlJQ1ZqQ0NBVDRDQVFBd0VURVBNQTBHQTFVRUF3d0dZVzVuWld4aE1JSUJJakFOQmdrcWhraUc5dzBCQVFFRgpBQU9DQVE4QU1JSUJDZ0tDQVFFQTByczhJTHRHdTYxakx2dHhWTTJSVlRWMDNHWlJTWWw0dWluVWo4RElaWjBOCnR2MUZtRVFSd3VoaUZsOFEzcWl0Qm0wMUFSMkNJVXBGd2ZzSjZ4MXF3ckJzVkhZbGlBNVhwRVpZM3ExcGswSDQKM3Z3aGJlK1o2MVNrVHF5SVBYUUwrTWM5T1Nsbm0xb0R2N0NtSkZNMUlMRVI3QTVGZnZKOEdFRjJ6dHBoaUlFMwpub1dtdHNZb3JuT2wzc2lHQ2ZGZzR4Zmd4eW8ybmlneFNVekl1bXNnVm9PM2ttT0x1RVF6cXpkakJ3TFJXbWlECklmMXBMWnoyalVnald4UkhCM1gyWnVVV1d1T09PZnpXM01LaE8ybHEvZi9DdS8wYk83c0x0MCt3U2ZMSU91TFcKcW90blZtRmxMMytqTy82WDNDKzBERHk5aUtwbXJjVDBnWGZLemE1dHJRSURBUUFCb0FBd0RRWUpLb1pJaHZjTgpBUUVMQlFBRGdnRUJBR05WdmVIOGR4ZzNvK21VeVRkbmFjVmQ1N24zSkExdnZEU1JWREkyQTZ1eXN3ZFp1L1BVCkkwZXpZWFV0RVNnSk1IRmQycVVNMjNuNVJsSXJ3R0xuUXFISUh5VStWWHhsdnZsRnpNOVpEWllSTmU3QlJvYXgKQVlEdUI5STZXT3FYbkFvczFqRmxNUG5NbFpqdU5kSGxpT1BjTU1oNndLaTZzZFhpVStHYTJ2RUVLY01jSVUyRgpvU2djUWdMYTk0aEpacGk3ZnNMdm1OQUxoT045UHdNMGM1dVJVejV4T0dGMUtCbWRSeEgvbUNOS2JKYjFRQm1HCkkwYitEUEdaTktXTU0xMzhIQXdoV0tkNjVoVHdYOWl4V3ZHMkh4TG1WQzg0L1BHT0tWQW9FNkpsYWFHdTlQVmkKdjlOSjVaZlZrcXdCd0hKbzZXdk9xVlA3SVFjZmg3d0drWm89Ci0tLS0tRU5EIENFUlRJRklDQVRFIFJFUVVFU1QtLS0tLQo=
|
||||
signerName: kubernetes.io/kube-apiserver-client
|
||||
expirationSeconds: 86400 # one day
|
||||
usages:
|
||||
- client auth
|
||||
EOF
|
||||
```
|
||||
|
||||
<!--
|
||||
Some points to note:
|
||||
|
||||
- `usages` has to be '`client auth`'
|
||||
- `expirationSeconds` could be made longer (i.e. `864000` for ten days) or shorter (i.e. `3600` for one hour)
|
||||
- `request` is the base64 encoded value of the CSR file content.
|
||||
You can get the content using this command:
|
||||
-->
|
||||
需要注意的几点：
|
||||
|
||||
- `usage` 字段必须是 '`client auth`'
|
||||
- `expirationSeconds` 可以设置为更长（例如 `864000` 是十天）或者更短（例如 `3600` 是一个小时）
|
||||
- `request` 字段是 CSR 文件内容的 base64 编码值，
|
||||
要得到该值，可以执行命令：
|
||||
|
||||
```shell
|
||||
cat myuser.csr | base64 | tr -d "\n"
|
||||
```
|
||||
|
||||
<!--
|
||||
### Approve the CertificateSigningRequest {#approve-certificate-signing-request}
|
||||
|
||||
Use kubectl to create a CSR and approve it.
|
||||
|
||||
Get the list of CSRs:
|
||||
-->
|
||||
### 批准 CertificateSigningRequest {#approve-certificate-signing-request}
|
||||
|
||||
使用 kubectl 创建 CSR 并批准。
|
||||
|
||||
获取 CSR 列表：
|
||||
|
||||
```shell
|
||||
kubectl get csr
|
||||
```
|
||||
|
||||
<!--
|
||||
Approve the CSR:
|
||||
-->
|
||||
批准 CSR：
|
||||
|
||||
```shell
|
||||
kubectl certificate approve myuser
|
||||
```
|
||||
|
||||
<!--
|
||||
### Get the certificate
|
||||
|
||||
Retrieve the certificate from the CSR:
|
||||
-->
|
||||
### 取得证书 {#get-the-certificate}
|
||||
|
||||
从 CSR 取得证书：
|
||||
|
||||
```shell
|
||||
kubectl get csr/myuser -o yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
The certificate value is in Base64-encoded format under `status.certificate`.
|
||||
|
||||
Export the issued certificate from the CertificateSigningRequest.
|
||||
-->
|
||||
证书的内容使用 base64 编码，存放在字段 `status.certificate`。
|
||||
|
||||
从 CertificateSigningRequest 导出颁发的证书：
|
||||
|
||||
```shell
|
||||
kubectl get csr myuser -o jsonpath='{.status.certificate}'| base64 -d > myuser.crt
|
||||
```
|
||||
|
||||
<!--
|
||||
### Create Role and RoleBinding
|
||||
|
||||
With the certificate created it is time to define the Role and RoleBinding for
|
||||
this user to access Kubernetes cluster resources.
|
||||
|
||||
This is a sample command to create a Role for this new user:
|
||||
-->
|
||||
### 创建角色和角色绑定 {#create-role-and-role-binding}
|
||||
|
||||
创建了证书之后，为了让这个用户能访问 Kubernetes 集群资源，现在就要创建
|
||||
Role 和 RoleBinding 了。
|
||||
|
||||
下面是为这个新用户创建 Role 的示例命令：
|
||||
|
||||
```shell
|
||||
kubectl create role developer --verb=create --verb=get --verb=list --verb=update --verb=delete --resource=pods
|
||||
```
|
||||
|
||||
<!--
|
||||
This is a sample command to create a RoleBinding for this new user:
|
||||
-->
|
||||
下面是为这个新用户创建 RoleBinding 的示例命令：
|
||||
|
||||
```shell
|
||||
kubectl create rolebinding developer-binding-myuser --role=developer --user=myuser
|
||||
```
|
||||
|
||||
<!--
|
||||
### Add to kubeconfig
|
||||
|
||||
The last step is to add this user into the kubeconfig file.
|
||||
|
||||
First, you need to add new credentials:
|
||||
-->
|
||||
### 添加到 kubeconfig {#add-to-kubeconfig}
|
||||
|
||||
最后一步是将这个用户添加到 kubeconfig 文件。
|
||||
|
||||
首先，你需要添加新的凭据：
|
||||
|
||||
```shell
|
||||
kubectl config set-credentials myuser --client-key=myuser.key --client-certificate=myuser.crt --embed-certs=true
|
||||
```
|
||||
|
||||
<!--
|
||||
Then, you need to add the context:
|
||||
-->
|
||||
然后，你需要添加上下文：
|
||||
|
||||
```shell
|
||||
kubectl config set-context myuser --cluster=kubernetes --user=myuser
|
||||
```
|
||||
|
||||
<!--
|
||||
To test it, change the context to `myuser`:
|
||||
-->
|
||||
来测试一下，把上下文切换为 `myuser`：
|
||||
|
||||
```shell
|
||||
kubectl config use-context myuser
|
||||
```
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
* Read [Manage TLS Certificates in a Cluster](/docs/tasks/tls/managing-tls-in-a-cluster/)
|
||||
* Read [Issue a Certificate for a Kubernetes API Client Using A CertificateSigningRequest](/docs/tasks/tls/certificate-issue-client-csr/)
|
||||
* View the source code for the kube-controller-manager built in
|
||||
[signer](https://github.com/kubernetes/kubernetes/blob/32ec6c212ec9415f604ffc1f4c1f29b782968ff1/pkg/controller/certificates/signer/cfssl_signer.go)
|
||||
* View the source code for the kube-controller-manager built in
|
||||
|
|
@ -1088,6 +893,7 @@ kubectl config use-context myuser
|
|||
* {{< page-api-reference kind="ClusterTrustBundle" >}}
|
||||
-->
|
||||
* 参阅[管理集群中的 TLS 认证](/zh-cn/docs/tasks/tls/managing-tls-in-a-cluster/)
|
||||
* 参阅[使用 CertificateSigningRequest 为 Kubernetes API 客户端颁发证书](/zh-cn/docs/tasks/tls/certificate-issue-client-csr/)
|
||||
* 查看 kube-controller-manager 中[签名者](https://github.com/kubernetes/kubernetes/blob/32ec6c212ec9415f604ffc1f4c1f29b782968ff1/pkg/controller/certificates/signer/cfssl_signer.go)部分的源代码
|
||||
* 查看 kube-controller-manager 中[批准者](https://github.com/kubernetes/kubernetes/blob/32ec6c212ec9415f604ffc1f4c1f29b782968ff1/pkg/controller/certificates/approver/sarapprove.go)部分的源代码
|
||||
* 有关 X.509 本身的详细信息，请参阅 [RFC 5280](https://tools.ietf.org/html/rfc5280#section-3.1) 第 3.1 节
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ tags:
|
|||
<!--
|
||||
Device plugins run on worker
|
||||
{{< glossary_tooltip term_id="node" text="Nodes">}} and provide
|
||||
{{< glossary_tooltip term_id="pod" text="Pods ">}} with access to resources,
|
||||
{{< glossary_tooltip term_id="pod" text="Pods">}} with access to resources,
|
||||
such as local hardware, that require vendor-specific initialization or setup
|
||||
steps.
|
||||
-->
|
||||
|
|
|
|||
|
|
@ -370,7 +370,5 @@ The output is similar to this:
|
|||
|
||||
<!--
|
||||
* [Learn more about `crictl`](https://github.com/kubernetes-sigs/cri-tools).
|
||||
* [Map `docker` CLI commands to `crictl`](/docs/reference/tools/map-crictl-dockercli/).
|
||||
-->
|
||||
* [进一步了解 `crictl`](https://github.com/kubernetes-sigs/cri-tools)
|
||||
* [将 `docker` CLI 命令映射到 `crictl`](/zh-cn/docs/reference/tools/map-crictl-dockercli/)
|
||||
|
|
|
|||
Loading…
Reference in New Issue