Replace redirections in the reference section
This PR removes the redirections used in the reference section and fixes some bad links.pull/23014/head
Qiming Teng
parent
664464806c
commit
d592baed54
|
|
@ -35,7 +35,7 @@ client libraries:
|
|||
## CLI Reference
|
||||
|
||||
* [kubectl](/docs/reference/kubectl/overview/) - Main CLI tool for running commands and managing Kubernetes clusters.
|
||||
* [JSONPath](/docs/reference/kubectl/jsonpath/) - Syntax guide for using [JSONPath expressions](http://goessner.net/articles/JsonPath/) with kubectl.
|
||||
* [JSONPath](/docs/reference/kubectl/jsonpath/) - Syntax guide for using [JSONPath expressions](https://goessner.net/articles/JsonPath/) with kubectl.
|
||||
* [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) - CLI tool to easily provision a secure Kubernetes cluster.
|
||||
|
||||
## Components Reference
|
||||
|
|
@ -50,6 +50,8 @@ client libraries:
|
|||
|
||||
## Design Docs
|
||||
|
||||
An archive of the design docs for Kubernetes functionality. Good starting points are [Kubernetes Architecture](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) and [Kubernetes Design Overview](https://git.k8s.io/community/contributors/design-proposals).
|
||||
An archive of the design docs for Kubernetes functionality. Good starting points are
|
||||
[Kubernetes Architecture](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) and
|
||||
[Kubernetes Design Overview](https://git.k8s.io/community/contributors/design-proposals).
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ Attribute-based access control (ABAC) defines an access control paradigm whereby
|
|||
|
||||
To enable `ABAC` mode, specify `--authorization-policy-file=SOME_FILENAME` and `--authorization-mode=ABAC` on startup.
|
||||
|
||||
The file format is [one JSON object per line](http://jsonlines.org/). There
|
||||
The file format is [one JSON object per line](https://jsonlines.org/). There
|
||||
should be no enclosing list or map, just one map per line.
|
||||
|
||||
Each line is a "policy object", where each such object is a map with the following
|
||||
|
|
@ -127,7 +127,7 @@ up the verbosity:
|
|||
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"group": "system:unauthenticated", "readonly": true, "nonResourcePath": "*"}}
|
||||
```
|
||||
|
||||
[Complete file example](http://releases.k8s.io/{{< param "githubbranch" >}}/pkg/auth/authorizer/abac/example_policy_file.jsonl)
|
||||
[Complete file example](https://releases.k8s.io/{{< param "githubbranch" >}}/pkg/auth/authorizer/abac/example_policy_file.jsonl)
|
||||
|
||||
## A quick note on service accounts
|
||||
|
||||
|
|
|
|||
|
|
@ -25,8 +25,8 @@ is authenticated and authorized. The controllers consist of the
|
|||
`kube-apiserver` binary, and may only be configured by the cluster
|
||||
administrator. In that list, there are two special controllers:
|
||||
MutatingAdmissionWebhook and ValidatingAdmissionWebhook. These execute the
|
||||
mutating and validating (respectively) [admission control
|
||||
webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)
|
||||
mutating and validating (respectively)
|
||||
[admission control webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)
|
||||
which are configured in the API.
|
||||
|
||||
Admission controllers may be "validating", "mutating", or both. Mutating
|
||||
|
|
@ -351,7 +351,10 @@ plugins:
|
|||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
The ImagePolicyWebhook config file must reference a [kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) formatted file which sets up the connection to the backend. It is required that the backend communicate over TLS.
|
||||
The ImagePolicyWebhook config file must reference a
|
||||
[kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
|
||||
formatted file which sets up the connection to the backend.
|
||||
It is required that the backend communicate over TLS.
|
||||
|
||||
The kubeconfig file's cluster field must point to the remote service, and the user field must contain the returned authorizer.
|
||||
|
||||
|
|
@ -371,7 +374,8 @@ users:
|
|||
client-key: /path/to/key.pem # key matching the cert
|
||||
```
|
||||
|
||||
For additional HTTP configuration, refer to the [kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) documentation.
|
||||
For additional HTTP configuration, refer to the
|
||||
[kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) documentation.
|
||||
|
||||
#### Request Payloads
|
||||
|
||||
|
|
@ -454,7 +458,8 @@ your Kubernetes deployment, you MUST use this admission controller to enforce th
|
|||
be used to apply default resource requests to Pods that don't specify any; currently, the default LimitRanger
|
||||
applies a 0.1 CPU requirement to all Pods in the `default` namespace.
|
||||
|
||||
See the [limitRange design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) and the [example of Limit Range](/docs/tasks/configure-pod-container/limit-range/) for more details.
|
||||
See the [limitRange design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md)
|
||||
and the [example of Limit Range](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/) for more details.
|
||||
|
||||
### MutatingAdmissionWebhook {#mutatingadmissionwebhook}
|
||||
|
||||
|
|
@ -731,16 +736,30 @@ for more information.
|
|||
|
||||
### SecurityContextDeny {#securitycontextdeny}
|
||||
|
||||
This admission controller will deny any pod that attempts to set certain escalating [SecurityContext](/docs/user-guide/security-context) fields. This should be enabled if a cluster doesn't utilize [pod security policies](/docs/user-guide/pod-security-policy) to restrict the set of values a security context can take.
|
||||
This admission controller will deny any pod that attempts to set certain escalating
|
||||
[SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core)
|
||||
fields, as shown in the
|
||||
[Configure a Security Context for a Pod or Container](/docs/tasks/configure-pod-container/security-context/)
|
||||
task.
|
||||
This should be enabled if a cluster doesn't utilize
|
||||
[pod security policies](/docs/concepts/policy/pod-security-policy/)
|
||||
to restrict the set of values a security context can take.
|
||||
|
||||
### ServiceAccount {#serviceaccount}
|
||||
|
||||
This admission controller implements automation for [serviceAccounts](/docs/user-guide/service-accounts).
|
||||
This admission controller implements automation for
|
||||
[serviceAccounts](/docs/tasks/configure-pod-container/configure-service-account/).
|
||||
We strongly recommend using this admission controller if you intend to make use of Kubernetes `ServiceAccount` objects.
|
||||
|
||||
### StorageObjectInUseProtection
|
||||
|
||||
The `StorageObjectInUseProtection` plugin adds the `kubernetes.io/pvc-protection` or `kubernetes.io/pv-protection` finalizers to newly created Persistent Volume Claims (PVCs) or Persistent Volumes (PV). In case a user deletes a PVC or PV the PVC or PV is not removed until the finalizer is removed from the PVC or PV by PVC or PV Protection Controller. Refer to the [Storage Object in Use Protection](/docs/concepts/storage/persistent-volumes/#storage-object-in-use-protection) for more detailed information.
|
||||
The `StorageObjectInUseProtection` plugin adds the `kubernetes.io/pvc-protection` or `kubernetes.io/pv-protection`
|
||||
finalizers to newly created Persistent Volume Claims (PVCs) or Persistent Volumes (PV).
|
||||
In case a user deletes a PVC or PV the PVC or PV is not removed until the finalizer is removed
|
||||
from the PVC or PV by PVC or PV Protection Controller.
|
||||
Refer to the
|
||||
[Storage Object in Use Protection](/docs/concepts/storage/persistent-volumes/#storage-object-in-use-protection)
|
||||
for more detailed information.
|
||||
|
||||
### TaintNodesByCondition {#taintnodesbycondition}
|
||||
|
||||
|
|
|
|||
|
|
@ -29,7 +29,15 @@ It is assumed that a cluster-independent service manages normal users in the fol
|
|||
In this regard, _Kubernetes does not have objects which represent normal user
|
||||
accounts._ Normal users cannot be added to a cluster through an API call.
|
||||
|
||||
Even though normal user cannot be added via an API call, but any user that presents a valid certificate signed by the cluster’s certificate authority (CA) is considered authenticated. In this configuration, Kubernetes determines 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. You can refer to [creating user certificate request](/docs/reference/access-authn-authz/certificate-signing-requests/#user-csr) for more details about this.
|
||||
Even though normal user cannot be added via an API call, but any user that
|
||||
presents a valid certificate signed by the cluster’s certificate authority
|
||||
(CA) is considered authenticated. In this configuration, Kubernetes determines
|
||||
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.
|
||||
|
||||
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
|
||||
|
|
@ -338,8 +346,12 @@ wish to utilize multiple OAuth clients should explore providers which support th
|
|||
tokens on behalf of another.
|
||||
|
||||
Kubernetes does not provide an OpenID Connect Identity Provider.
|
||||
You can use an existing public OpenID Connect Identity Provider (such as Google, or [others](http://connect2id.com/products/nimbus-oauth-openid-connect-sdk/openid-connect-providers)).
|
||||
Or, you can run your own Identity Provider, such as CoreOS [dex](https://github.com/coreos/dex), [Keycloak](https://github.com/keycloak/keycloak), CloudFoundry [UAA](https://github.com/cloudfoundry/uaa), or Tremolo Security's [OpenUnison](https://github.com/tremolosecurity/openunison).
|
||||
You can use an existing public OpenID Connect Identity Provider (such as Google, or
|
||||
[others](https://connect2id.com/products/nimbus-oauth-openid-connect-sdk/openid-connect-providers)).
|
||||
Or, you can run your own Identity Provider, such as CoreOS [dex](https://github.com/coreos/dex),
|
||||
[Keycloak](https://github.com/keycloak/keycloak),
|
||||
CloudFoundry [UAA](https://github.com/cloudfoundry/uaa), or
|
||||
Tremolo Security's [OpenUnison](https://github.com/tremolosecurity/openunison).
|
||||
|
||||
For an identity provider to work with Kubernetes it must:
|
||||
|
||||
|
|
@ -423,7 +435,7 @@ Webhook authentication is a hook for verifying bearer tokens.
|
|||
* `--authentication-token-webhook-config-file` a configuration file describing how to access the remote webhook service.
|
||||
* `--authentication-token-webhook-cache-ttl` how long to cache authentication decisions. Defaults to two minutes.
|
||||
|
||||
The configuration file uses the [kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)
|
||||
The configuration file uses the [kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
|
||||
file format. Within the file, `clusters` refers to the remote service and
|
||||
`users` refers to the API server webhook. An example would be:
|
||||
|
||||
|
|
|
|||
|
|
@ -589,7 +589,7 @@ Example of a response to forbid a request, customizing the HTTP status code and
|
|||
When allowing a request, a mutating admission webhook may optionally modify the incoming object as well.
|
||||
This is done using the `patch` and `patchType` fields in the response.
|
||||
The only currently supported `patchType` is `JSONPatch`.
|
||||
See [JSON patch](http://jsonpatch.com/) documentation for more details.
|
||||
See [JSON patch](https://jsonpatch.com/) documentation for more details.
|
||||
For `patchType: JSONPatch`, the `patch` field contains a base64-encoded array of JSON patch operations.
|
||||
|
||||
As an example, a single patch operation that would set `spec.replicas` would be `[{"op": "add", "path": "/spec/replicas", "value": 3}]`
|
||||
|
|
|
|||
|
|
@ -10,8 +10,8 @@ weight: 50
|
|||
---
|
||||
|
||||
<!-- overview -->
|
||||
This is a Cluster Administrator guide to service accounts. It assumes knowledge of
|
||||
the [User Guide to Service Accounts](/docs/user-guide/service-accounts).
|
||||
This is a Cluster Administrator guide to service accounts. You should be familiar with
|
||||
[configuring Kubernetes service accounts](/docs/tasks/configure-pod-container/configure-service-account/).
|
||||
|
||||
Support for authorization and user accounts is planned but incomplete. Sometimes
|
||||
incomplete features are referred to in order to better describe service accounts.
|
||||
|
|
|
|||
|
|
@ -389,11 +389,11 @@ Each feature gate is designed for enabling/disabling a specific feature:
|
|||
- `CustomResourceDefaulting`: Enable CRD support for default values in OpenAPI v3 validation schemas.
|
||||
- `CustomResourcePublishOpenAPI`: Enables publishing of CRD OpenAPI specs.
|
||||
- `CustomResourceSubresources`: Enable `/status` and `/scale` subresources
|
||||
on resources created from [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/).
|
||||
on resources created from [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
|
||||
- `CustomResourceValidation`: Enable schema based validation on resources created from
|
||||
[CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/).
|
||||
[CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
|
||||
- `CustomResourceWebhookConversion`: Enable webhook-based conversion
|
||||
on resources created from [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/).
|
||||
on resources created from [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
|
||||
troubleshoot a running Pod.
|
||||
- `DevicePlugins`: Enable the [device-plugins](/docs/concepts/cluster-administration/device-plugins/)
|
||||
based resource provisioning on nodes.
|
||||
|
|
@ -436,8 +436,11 @@ Each feature gate is designed for enabling/disabling a specific feature:
|
|||
- `KubeletPodResources`: Enable the kubelet's pod resources grpc endpoint.
|
||||
See [Support Device Monitoring](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/compute-device-assignment.md) for more details.
|
||||
- `LegacyNodeRoleBehavior`: When disabled, legacy behavior in service load balancers and node disruption will ignore the `node-role.kubernetes.io/master` label in favor of the feature-specific labels.
|
||||
- `LocalStorageCapacityIsolation`: Enable the consumption of [local ephemeral storage](/docs/concepts/configuration/manage-compute-resources-container/) and also the `sizeLimit` property of an [emptyDir volume](/docs/concepts/storage/volumes/#emptydir).
|
||||
- `LocalStorageCapacityIsolationFSQuotaMonitoring`: When `LocalStorageCapacityIsolation` is enabled for [local ephemeral storage](/docs/concepts/configuration/manage-compute-resources-container/) and the backing filesystem for [emptyDir volumes](/docs/concepts/storage/volumes/#emptydir) supports project quotas and they are enabled, use project quotas to monitor [emptyDir volume](/docs/concepts/storage/volumes/#emptydir) storage consumption rather than filesystem walk for better performance and accuracy.
|
||||
- `LocalStorageCapacityIsolation`: Enable the consumption of [local ephemeral storage](/docs/concepts/configuration/manage-resources-containers/) and also the `sizeLimit` property of an [emptyDir volume](/docs/concepts/storage/volumes/#emptydir).
|
||||
- `LocalStorageCapacityIsolationFSQuotaMonitoring`: When `LocalStorageCapacityIsolation` is enabled for
|
||||
[local ephemeral storage](/docs/concepts/configuration/manage-resources-containers/) and the backing filesystem for
|
||||
[emptyDir volumes](/docs/concepts/storage/volumes/#emptydir) supports project quotas and they are enabled, use project quotas to monitor
|
||||
[emptyDir volume](/docs/concepts/storage/volumes/#emptydir) storage consumption rather than filesystem walk for better performance and accuracy.
|
||||
- `MountContainers`: Enable using utility containers on host as the volume mounter.
|
||||
- `MountPropagation`: Enable sharing volume mounted by one container to other containers or pods.
|
||||
For more details, please see [mount propagation](/docs/concepts/storage/volumes/#mount-propagation).
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ A tool that lets you use OCI container runtimes with Kubernetes CRI.
|
|||
CRI-O is an implementation of the {{< glossary_tooltip term_id="cri" >}}
|
||||
to enable using {{< glossary_tooltip text="container" term_id="container" >}}
|
||||
runtimes that are compatible with the Open Container Initiative (OCI)
|
||||
[runtime spec](http://www.github.com/opencontainers/runtime-spec).
|
||||
[runtime spec](https://www.github.com/opencontainers/runtime-spec).
|
||||
|
||||
Deploying CRI-O allows Kubernetes to use any OCI-compliant runtime as the container
|
||||
runtime for running {{< glossary_tooltip text="Pods" term_id="pod" >}}, and to fetch
|
||||
|
|
|
|||
|
|
@ -14,4 +14,9 @@ tags:
|
|||
|
||||
<!--more-->
|
||||
|
||||
Some examples of Managed Services are AWS EC2, Azure SQL Database, and GCP Pub/Sub, but they can be any software offering that can be used by an application. [Service Catalog](/docs/concepts/service-catalog/) provides a way to list, provision, and bind with Managed Services offered by {{< glossary_tooltip text="Service Brokers" term_id="service-broker" >}}.
|
||||
Some examples of Managed Services are AWS EC2, Azure SQL Database, and
|
||||
GCP Pub/Sub, but they can be any software offering that can be used by an application.
|
||||
[Service Catalog](/docs/concepts/extend-kubernetes/service-catalog/) provides a way to
|
||||
list, provision, and bind with Managed Services offered by
|
||||
{{< glossary_tooltip text="Service Brokers" term_id="service-broker" >}}.
|
||||
|
||||
|
|
|
|||
|
|
@ -14,5 +14,10 @@ tags:
|
|||
|
||||
<!--more-->
|
||||
|
||||
A platform developer may, for example, use [Custom Resources](/docs/concepts/api-extension/custom-resources/) or [Extend the Kubernetes API with the aggregation layer](/docs/concepts/api-extension/apiserver-aggregation/) to add functionality to their instance of Kubernetes, specifically for their application. Some Platform Developers are also {{< glossary_tooltip text="contributors" term_id="contributor" >}} and develop extensions which are contributed to the Kubernetes community. Others develop closed-source commercial or site-specific extensions.
|
||||
A platform developer may, for example, use [Custom Resources](/docs/concepts/extend-Kubernetes/api-extension/custom-resources/) or
|
||||
[Extend the Kubernetes API with the aggregation layer](/docs/concepts/extend-Kubernetes/api-extension/apiserver-aggregation/)
|
||||
to add functionality to their instance of Kubernetes, specifically for their application.
|
||||
Some Platform Developers are also {{< glossary_tooltip text="contributors" term_id="contributor" >}} and
|
||||
develop extensions which are contributed to the Kubernetes community.
|
||||
Others develop closed-source commercial or site-specific extensions.
|
||||
|
||||
|
|
|
|||
|
|
@ -14,4 +14,9 @@ tags:
|
|||
|
||||
<!--more-->
|
||||
|
||||
{{< glossary_tooltip text="Service Brokers" term_id="service-broker" >}} implement the [Open Service Broker API spec](https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md) and provide a standard interface for applications to use their Managed Services. [Service Catalog](/docs/concepts/service-catalog/) provides a way to list, provision, and bind with Managed Services offered by Service Brokers.
|
||||
{{< glossary_tooltip text="Service Brokers" term_id="service-broker" >}} implement the
|
||||
[Open Service Broker API spec](https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md)
|
||||
and provide a standard interface for applications to use their Managed Services.
|
||||
[Service Catalog](/docs/concepts/extend-kubernetes/service-catalog/) provides a way to
|
||||
list, provision, and bind with Managed Services offered by Service Brokers.
|
||||
|
||||
|
|
|
|||
|
|
@ -10,11 +10,16 @@ card:
|
|||
---
|
||||
|
||||
<!-- overview -->
|
||||
The kubectl command line tool lets you control Kubernetes clusters. For configuration, `kubectl` looks for a file named `config` in the `$HOME/.kube` directory. You can specify other [kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) files by setting the KUBECONFIG environment variable or by setting the [`--kubeconfig`](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) flag.
|
||||
|
||||
This overview covers `kubectl` syntax, describes the command operations, and provides common examples. For details about each command, including all the supported flags and subcommands, see the [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) reference documentation. For installation instructions see [installing kubectl](/docs/tasks/kubectl/install/).
|
||||
|
||||
The kubectl command line tool lets you control Kubernetes clusters.
|
||||
For configuration, `kubectl` looks for a file named `config` in the `$HOME/.kube` directory.
|
||||
You can specify other [kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
|
||||
files by setting the KUBECONFIG environment variable or by setting the
|
||||
[`--kubeconfig`](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) flag.
|
||||
|
||||
This overview covers `kubectl` syntax, describes the command operations, and provides common examples.
|
||||
For details about each command, including all the supported flags and subcommands, see the
|
||||
[kubectl](/docs/reference/generated/kubectl/kubectl-commands/) reference documentation.
|
||||
For installation instructions see [installing kubectl](/docs/tasks/tools/install-kubectl/).
|
||||
|
||||
<!-- body -->
|
||||
|
||||
|
|
@ -28,9 +33,12 @@ kubectl [command] [TYPE] [NAME] [flags]
|
|||
|
||||
where `command`, `TYPE`, `NAME`, and `flags` are:
|
||||
|
||||
* `command`: Specifies the operation that you want to perform on one or more resources, for example `create`, `get`, `describe`, `delete`.
|
||||
* `command`: Specifies the operation that you want to perform on one or more resources,
|
||||
for example `create`, `get`, `describe`, `delete`.
|
||||
|
||||
* `TYPE`: Specifies the [resource type](#resource-types). Resource types are case-insensitive and you can specify the singular, plural, or abbreviated forms. For example, the following commands produce the same output:
|
||||
* `TYPE`: Specifies the [resource type](#resource-types). Resource types are case-insensitive and
|
||||
you can specify the singular, plural, or abbreviated forms.
|
||||
For example, the following commands produce the same output:
|
||||
|
||||
```shell
|
||||
kubectl get pod pod1
|
||||
|
|
@ -208,11 +216,13 @@ In this example, the following command outputs the details for a single pod as a
|
|||
kubectl get pod web-pod-13je7 -o yaml
|
||||
```
|
||||
|
||||
Remember: See the [kubectl](/docs/user-guide/kubectl/) reference documentation for details about which output format is supported by each command.
|
||||
Remember: See the [kubectl](/docs/reference/kubectl/kubectl/) reference documentation
|
||||
for details about which output format is supported by each command.
|
||||
|
||||
#### Custom columns
|
||||
|
||||
To define custom columns and output only the details that you want into a table, you can use the `custom-columns` option. You can choose to define the custom columns inline or use a template file: `-o custom-columns=<spec>` or `-o custom-columns-file=<filename>`.
|
||||
To define custom columns and output only the details that you want into a table, you can use the `custom-columns` option.
|
||||
You can choose to define the custom columns inline or use a template file: `-o custom-columns=<spec>` or `-o custom-columns-file=<filename>`.
|
||||
|
||||
##### Examples
|
||||
|
||||
|
|
@ -496,12 +506,8 @@ kubectl whoami
|
|||
Current user: plugins-user
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* Start using the [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) commands.
|
||||
|
||||
* To find out more about plugins, take a look at the [example cli plugin](https://github.com/kubernetes/sample-cli-plugin).
|
||||
|
|
|
|||
|
|
@ -84,7 +84,7 @@ Currently, there are several API groups in use:
|
|||
* The named groups are at REST path `/apis/$GROUP_NAME/$VERSION`, and use `apiVersion: $GROUP_NAME/$VERSION`
|
||||
(for example, `apiVersion: batch/v1`). You can find the full list of supported API groups in [Kubernetes API reference](/docs/reference/).
|
||||
|
||||
The two paths that support extending the API with [custom resources](/docs/concepts/api-extension/custom-resources/) are:
|
||||
The two paths that support extending the API with [custom resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) are:
|
||||
|
||||
- [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)
|
||||
for basic CRUD needs.
|
||||
|
|
|
|||
|
|
@ -19,13 +19,13 @@ You can use a client library for the programming language you are using.
|
|||
Client libraries often handle common tasks such as authentication for you.
|
||||
Most client libraries can discover and use the Kubernetes Service Account to
|
||||
authenticate if the API client is running inside the Kubernetes cluster, or can
|
||||
understand the [kubeconfig file](/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig/)
|
||||
understand the [kubeconfig file](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
|
||||
format to read the credentials and the API Server address.
|
||||
|
||||
## Officially-supported Kubernetes client libraries
|
||||
|
||||
The following client libraries are officially maintained by [Kubernetes SIG API
|
||||
Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery).
|
||||
The following client libraries are officially maintained by
|
||||
[Kubernetes SIG API Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery).
|
||||
|
||||
|
||||
| Language | Client Library | Sample Programs |
|
||||
|
|
|
|||
|
|
@ -289,8 +289,7 @@ API versions are supported in a series of subsequent releases.
|
|||
### REST resources (aka API objects)
|
||||
|
||||
Consider a hypothetical REST resource named Widget, which was present in API v1
|
||||
in the above timeline, and which needs to be deprecated. We
|
||||
[document](/docs/reference/deprecation-policy/) and
|
||||
in the above timeline, and which needs to be deprecated. We document and
|
||||
[announce](https://groups.google.com/forum/#!forum/kubernetes-announce) the
|
||||
deprecation in sync with release X+1. The Widget resource still exists in API
|
||||
version v1 (deprecated) but not in v2alpha1. The Widget resource continues to
|
||||
|
|
|
|||
Loading…
Reference in New Issue