Fix nits in markdown links
This PR fixes a few "bad links" identified by the `scripts/linkchecker.py` script.pull/38276/head
Qiming Teng
parent
64f03032cd
commit
a437285212
|
|
@ -12,7 +12,8 @@ The Kubernetes API server is the main point of entry to a cluster for external p
|
|||
(users and services) interacting with it.
|
||||
|
||||
As part of this role, the API server has several key built-in security controls, such as
|
||||
audit logging and {{< glossary_tooltip text="admission controllers" term_id="admission-controller" >}}. However, there are ways to modify the configuration
|
||||
audit logging and {{< glossary_tooltip text="admission controllers" term_id="admission-controller" >}}.
|
||||
However, there are ways to modify the configuration
|
||||
or content of the cluster that bypass these controls.
|
||||
|
||||
This page describes the ways in which the security controls built into the
|
||||
|
|
@ -65,7 +66,8 @@ every container running on the node.
|
|||
|
||||
When Kubernetes cluster users have RBAC access to `Node` object sub-resources, that access
|
||||
serves as authorization to interact with the kubelet API. The exact access depends on
|
||||
which sub-resource access has been granted, as detailed in [kubelet authorization](https://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/#kubelet-authorization).
|
||||
which sub-resource access has been granted, as detailed in
|
||||
[kubelet authorization](/docs/reference/access-authn-authz/kubelet-authn-authz/#kubelet-authorization).
|
||||
|
||||
Direct access to the kubelet API is not subject to admission control and is not logged
|
||||
by Kubernetes audit logging. An attacker with direct access to this API may be able to
|
||||
|
|
@ -80,11 +82,12 @@ The default anonymous access doesn't make this assertion with the control plane.
|
|||
### Mitigations
|
||||
|
||||
- Restrict access to sub-resources of the `nodes` API object using mechanisms such as
|
||||
[RBAC](/docs/reference/access-authn-authz/rbac/). Only grant this access when required,
|
||||
such as by monitoring services.
|
||||
[RBAC](/docs/reference/access-authn-authz/rbac/). Only grant this access when required,
|
||||
such as by monitoring services.
|
||||
- Restrict access to the kubelet port. Only allow specified and trusted IP address
|
||||
ranges to access the port.
|
||||
- [Ensure that kubelet authentication is set to webhook or certificate mode](/docs/reference/access-authn-authz/kubelet-authn-authz/#kubelet-authentication).
|
||||
ranges to access the port.
|
||||
- Ensure that [kubelet authentication](/docs/reference/access-authn-authz/kubelet-authn-authz/#kubelet-authentication).
|
||||
is set to webhook or certificate mode.
|
||||
- Ensure that the unauthenticated "read-only" Kubelet port is not enabled on the cluster.
|
||||
|
||||
## The etcd API
|
||||
|
|
|
|||
|
|
@ -388,7 +388,8 @@ You must configure FC SAN Zoning to allocate and mask those LUNs (volumes) to th
|
|||
beforehand so that Kubernetes hosts can access them.
|
||||
{{< /note >}}
|
||||
|
||||
See the [fibre channel example](https://github.com/kubernetes/examples/tree/master/staging/volumes/fibre_channel) for more details.
|
||||
See the [fibre channel example](https://github.com/kubernetes/examples/tree/master/staging/volumes/fibre_channel)
|
||||
for more details.
|
||||
|
||||
### gcePersistentDisk (deprecated) {#gcepersistentdisk}
|
||||
|
||||
|
|
@ -515,7 +516,9 @@ and the kubelet, set the `InTreePluginGCEUnregister` flag to `true`.
|
|||
### gitRepo (deprecated) {#gitrepo}
|
||||
|
||||
{{< warning >}}
|
||||
The `gitRepo` volume type is deprecated. To provision a container with a git repo, mount an [EmptyDir](#emptydir) into an InitContainer that clones the repo using git, then mount the [EmptyDir](#emptydir) into the Pod's container.
|
||||
The `gitRepo` volume type is deprecated. To provision a container with a git repo, mount an
|
||||
[EmptyDir](#emptydir) into an InitContainer that clones the repo using git, then mount the
|
||||
[EmptyDir](#emptydir) into the Pod's container.
|
||||
{{< /warning >}}
|
||||
|
||||
A `gitRepo` volume is an example of a volume plugin. This plugin
|
||||
|
|
@ -785,10 +788,13 @@ spec:
|
|||
{{< note >}}
|
||||
You must have your own NFS server running with the share exported before you can use it.
|
||||
|
||||
Also note that you can't specify NFS mount options in a Pod spec. You can either set mount options server-side or use [/etc/nfsmount.conf](https://man7.org/linux/man-pages/man5/nfsmount.conf.5.html). You can also mount NFS volumes via PersistentVolumes which do allow you to set mount options.
|
||||
Also note that you can't specify NFS mount options in a Pod spec. You can either set mount options server-side or
|
||||
use [/etc/nfsmount.conf](https://man7.org/linux/man-pages/man5/nfsmount.conf.5.html).
|
||||
You can also mount NFS volumes via PersistentVolumes which do allow you to set mount options.
|
||||
{{< /note >}}
|
||||
|
||||
See the [NFS example](https://github.com/kubernetes/examples/tree/master/staging/volumes/nfs) for an example of mounting NFS volumes with PersistentVolumes.
|
||||
See the [NFS example](https://github.com/kubernetes/examples/tree/master/staging/volumes/nfs)
|
||||
for an example of mounting NFS volumes with PersistentVolumes.
|
||||
|
||||
### persistentVolumeClaim {#persistentvolumeclaim}
|
||||
|
||||
|
|
@ -1163,7 +1169,7 @@ persistent volume:
|
|||
volume expansion, the kubelet passes that data via the `NodeExpandVolume()`
|
||||
call to the CSI driver. In order to use the `nodeExpandSecretRef` field, your
|
||||
cluster should be running Kubernetes version 1.25 or later and you must enable
|
||||
the [feature gate](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
the [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
named `CSINodeExpandSecret` for each kube-apiserver and for the kubelet on every
|
||||
node. You must also be using a CSI driver that supports or requires secret data during
|
||||
node-initiated storage resize operations.
|
||||
|
|
|
|||
|
|
@ -382,8 +382,6 @@ troubleshooting ideas prior to creating a ticket.
|
|||
|
||||
The kubeadm tool helps you to deploy a Kubernetes cluster, providing the control
|
||||
plane to manage the cluster it, and nodes to run your workloads.
|
||||
[Adding Windows nodes](/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/)
|
||||
explains how to deploy Windows nodes to your cluster using kubeadm.
|
||||
|
||||
The Kubernetes [cluster API](https://cluster-api.sigs.k8s.io/) project also provides means to automate deployment of Windows nodes.
|
||||
|
||||
|
|
|
|||
|
|
@ -22,12 +22,11 @@ This guide walks you through the steps to configure and deploy Windows container
|
|||
|
||||
## Before you begin
|
||||
|
||||
* Create a Kubernetes cluster that includes a
|
||||
control plane and a [worker node running Windows Server](/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/)
|
||||
* Create a Kubernetes cluster that includes a control plane and a worker node running Windows Server
|
||||
* It is important to note that creating and deploying services and workloads on Kubernetes
|
||||
behaves in much the same way for Linux and Windows containers.
|
||||
[Kubectl commands](/docs/reference/kubectl/) to interface with the cluster are identical.
|
||||
The example in the section below is provided to jumpstart your experience with Windows containers.
|
||||
behaves in much the same way for Linux and Windows containers.
|
||||
[Kubectl commands](/docs/reference/kubectl/) to interface with the cluster are identical.
|
||||
The example in the section below is provided to jumpstart your experience with Windows containers.
|
||||
|
||||
## Getting Started: Deploying a Windows container
|
||||
|
||||
|
|
|
|||
|
|
@ -14,8 +14,6 @@ no_list: true
|
|||
|
||||
This section of the Kubernetes documentation contains references.
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## API Reference
|
||||
|
|
@ -44,7 +42,7 @@ client libraries:
|
|||
## CLI
|
||||
|
||||
* [kubectl](/docs/reference/kubectl/) - Main CLI tool for running commands and managing Kubernetes clusters.
|
||||
* [JSONPath](/docs/reference/kubectl/jsonpath/) - Syntax guide for using [JSONPath expressions](https://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/) - CLI tool to easily provision a secure Kubernetes cluster.
|
||||
|
||||
## Components
|
||||
|
|
@ -55,16 +53,18 @@ client libraries:
|
|||
* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) -
|
||||
REST API that validates and configures data for API objects such as pods,
|
||||
services, replication controllers.
|
||||
* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) - Daemon that embeds the core control loops shipped with Kubernetes.
|
||||
* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) -
|
||||
Daemon that embeds the core control loops shipped with Kubernetes.
|
||||
* [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) - Can
|
||||
do simple TCP/UDP stream forwarding or round-robin TCP/UDP forwarding across
|
||||
a set of back-ends.
|
||||
* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/) - Scheduler that manages availability, performance, and capacity.
|
||||
* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/) -
|
||||
Scheduler that manages availability, performance, and capacity.
|
||||
|
||||
* [Scheduler Policies](/docs/reference/scheduling/policies)
|
||||
* [Scheduler Profiles](/docs/reference/scheduling/config#profiles)
|
||||
|
||||
* List of [ports and protocols](/docs/reference/ports-and-protocols/) that
|
||||
* List of [ports and protocols](/docs/reference/networking/ports-and-protocols/) that
|
||||
should be open on control plane and worker nodes
|
||||
|
||||
## Config APIs
|
||||
|
|
|
|||
|
|
@ -13,8 +13,8 @@ However, a GA'ed or a deprecated feature gate is still recognized by the corresp
|
|||
components although they are unable to cause any behavior differences in a cluster.
|
||||
|
||||
For feature gates that are still recognized by the Kubernetes components, please refer to
|
||||
the [Alpha/Beta feature gate table](/docs/reference/command-line-tools/reference/feature-gates/#feature-gates-for-alpha-or-beta-features)
|
||||
or the [Graduated/Deprecated feature gate table](/docs/reference/command-line-tools/reference/feature-gates/#feature-gates-for-graduated-or-deprecated-features)
|
||||
the [Alpha/Beta feature gate table](/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-alpha-or-beta-features)
|
||||
or the [Graduated/Deprecated feature gate table](/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-graduated-or-deprecated-features)
|
||||
|
||||
### Feature gates that are removed
|
||||
|
||||
|
|
|
|||
|
|
@ -14,7 +14,6 @@ mechanism for {{< glossary_tooltip term_id="service" text="Services">}}
|
|||
of `type` other than
|
||||
[`ExternalName`](/docs/concepts/services-networking/service/#externalname).
|
||||
|
||||
|
||||
A question that pops up every now and then is why Kubernetes relies on
|
||||
proxying to forward inbound traffic to backends. What about other
|
||||
approaches? For example, would it be possible to configure DNS records that
|
||||
|
|
@ -39,7 +38,6 @@ network proxying service on a computer. Although the `kube-proxy` executable su
|
|||
`cleanup` function, this function is not an official feature and thus is only available
|
||||
to use as-is.
|
||||
|
||||
|
||||
<a id="example"></a>
|
||||
Some of the details in this reference refer to an example: the back end Pods for a stateless
|
||||
image-processing workload, running with three replicas. Those replicas are
|
||||
|
|
@ -47,7 +45,6 @@ fungible—frontends do not care which backend they use. While the actual P
|
|||
compose the backend set may change, the frontend clients should not need to be aware of that,
|
||||
nor should they need to keep track of the set of backends themselves.
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Proxy modes
|
||||
|
|
@ -282,4 +279,5 @@ You can also:
|
|||
|
||||
* Read about [Services](/docs/concepts/services-networking/service/) as a concept
|
||||
* Read about [Ingresses](/docs/concepts/services-networking/ingress/) as a concept
|
||||
* Read the [API reference](/docs/reference/kubernetes-api/service-resources/service-v1/) for the Service API
|
||||
* Read the [API reference](/docs/reference/kubernetes-api/service-resources/service-v1/) for the Service API
|
||||
|
||||
|
|
|
|||
|
|
@ -12,13 +12,15 @@ card:
|
|||
|
||||
<img src="/images/kubeadm-stacked-color.png" align="right" width="150px"></img>
|
||||
This page shows how to install the `kubeadm` toolbox.
|
||||
For information on how to create a cluster with kubeadm once you have performed this installation process, see the [Creating a cluster with kubeadm](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) page.
|
||||
For information on how to create a cluster with kubeadm once you have performed this installation process,
|
||||
see the [Creating a cluster with kubeadm](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) page.
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
* A compatible Linux host. The Kubernetes project provides generic instructions for Linux distributions based on Debian and Red Hat, and those distributions without a package manager.
|
||||
* A compatible Linux host. The Kubernetes project provides generic instructions for Linux distributions
|
||||
based on Debian and Red Hat, and those distributions without a package manager.
|
||||
* 2 GB or more of RAM per machine (any less will leave little room for your apps).
|
||||
* 2 CPUs or more.
|
||||
* Full network connectivity between all machines in the cluster (public or private network is fine).
|
||||
|
|
@ -26,8 +28,6 @@ For information on how to create a cluster with kubeadm once you have performed
|
|||
* Certain ports are open on your machines. See [here](#check-required-ports) for more details.
|
||||
* Swap disabled. You **MUST** disable swap in order for the kubelet to work properly.
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Verify the MAC address and product_uuid are unique for every node {#verify-mac-address}
|
||||
|
|
@ -46,9 +46,9 @@ If you have more than one network adapter, and your Kubernetes components are no
|
|||
route, we recommend you add IP route(s) so Kubernetes cluster addresses go via the appropriate adapter.
|
||||
|
||||
## Check required ports
|
||||
These
|
||||
[required ports](/docs/reference/ports-and-protocols/)
|
||||
need to be open in order for Kubernetes components to communicate with each other. You can use tools like netcat to check if a port is open. For example:
|
||||
These [required ports](/docs/reference/networking/ports-and-protocols/)
|
||||
need to be open in order for Kubernetes components to communicate with each other.
|
||||
You can use tools like netcat to check if a port is open. For example:
|
||||
|
||||
```shell
|
||||
nc 127.0.0.1 6443
|
||||
|
|
|
|||
|
|
@ -9,10 +9,7 @@ weight: 40
|
|||
|
||||
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
|
||||
|
||||
This page explains how to upgrade a Windows node [created with kubeadm](/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes).
|
||||
|
||||
|
||||
|
||||
This page explains how to upgrade a Windows node created with kubeadm.
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
|
@ -21,9 +18,6 @@ This page explains how to upgrade a Windows node [created with kubeadm](/docs/ta
|
|||
cluster](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade). You will want to
|
||||
upgrade the control plane nodes before upgrading your Windows nodes.
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Upgrading worker nodes
|
||||
|
|
@ -81,7 +75,8 @@ upgrade the control plane nodes before upgrading your Windows nodes.
|
|||
```
|
||||
|
||||
{{< note >}}
|
||||
If you are running kube-proxy in a HostProcess container within a Pod, and not as a Windows Service, you can upgrade kube-proxy by applying a newer version of your kube-proxy manifests.
|
||||
If you are running kube-proxy in a HostProcess container within a Pod, and not as a Windows Service,
|
||||
you can upgrade kube-proxy by applying a newer version of your kube-proxy manifests.
|
||||
{{< /note >}}
|
||||
|
||||
### Uncordon the node
|
||||
|
|
@ -94,6 +89,3 @@ bring the node back online by marking it schedulable:
|
|||
kubectl uncordon <node-to-drain>
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -47,11 +47,12 @@ kubectl get pods/<podname> -o yaml
|
|||
```
|
||||
|
||||
In the output, you see a field `spec.serviceAccountName`.
|
||||
Kubernetes [automatically](/docs/user-guide/working-with-resources/#resources-are-automatically-modified)
|
||||
Kubernetes [automatically](/docs/concepts/overview/working-with-objects/object-management/)
|
||||
sets that value if you don't specify it when you create a Pod.
|
||||
|
||||
An application running inside a Pod can access the Kubernetes API using
|
||||
automatically mounted service account credentials. See [accessing the Cluster](/docs/user-guide/accessing-the-cluster/#accessing-the-api-from-a-pod) to learn more.
|
||||
automatically mounted service account credentials.
|
||||
See [accessing the Cluster](/docs/tasks/access-application-cluster/access-cluster/) to learn more.
|
||||
|
||||
When a Pod authenticates as a ServiceAccount, its level of access depends on the
|
||||
[authorization plugin and policy](/docs/reference/access-authn-authz/authorization/#authorization-modules)
|
||||
|
|
@ -62,7 +63,8 @@ in use.
|
|||
If you don't want the {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}
|
||||
to automatically mount a ServiceAccount's API credentials, you can opt out of
|
||||
the default behavior.
|
||||
You can opt out of automounting API credentials on `/var/run/secrets/kubernetes.io/serviceaccount/token` for a service account by setting `automountServiceAccountToken: false` on the ServiceAccount:
|
||||
You can opt out of automounting API credentials on `/var/run/secrets/kubernetes.io/serviceaccount/token`
|
||||
for a service account by setting `automountServiceAccountToken: false` on the ServiceAccount:
|
||||
|
||||
For example:
|
||||
|
||||
|
|
|
|||
|
|
@ -470,8 +470,7 @@ The more files and directories in the volume, the longer that relabelling takes.
|
|||
In Kubernetes 1.25, the kubelet loses track of volume labels after restart. In
|
||||
other words, then kubelet may refuse to start Pods with errors similar to "conflicting
|
||||
SELinux labels of volume", while there are no conflicting labels in Pods. Make sure
|
||||
nodes are
|
||||
[fully drained](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/)
|
||||
nodes are [fully drained](/docs/tasks/administer-cluster/safely-drain-node/)
|
||||
before restarting kubelet.
|
||||
{{< /note >}}
|
||||
|
||||
|
|
@ -519,4 +518,5 @@ kubectl delete pod security-context-demo-4
|
|||
* [AllowPrivilegeEscalation design
|
||||
document](https://git.k8s.io/design-proposals-archive/auth/no-new-privs.md)
|
||||
* For more information about security mechanisms in Linux, see
|
||||
[Overview of Linux Kernel Security Features](https://www.linux.com/learn/overview-linux-kernel-security-features) (Note: Some information is out of date)
|
||||
[Overview of Linux Kernel Security Features](https://www.linux.com/learn/overview-linux-kernel-security-features)
|
||||
(Note: Some information is out of date)
|
||||
|
|
|
|||
Loading…
Reference in New Issue