Merge remote-tracking branch 'upstream/master' into dev-1.20
This commit is contained in:
reylejano-rxm
@@ -124,6 +124,10 @@ With the help of the Big Cloud Fabric's virtual pod multi-tenant architecture, c
|
||||
|
||||
BCF was recognized by Gartner as a visionary in the latest [Magic Quadrant](https://go.bigswitch.com/17GatedDocuments-MagicQuadrantforDataCenterNetworking_Reg.html). One of the BCF Kubernetes on-premises deployments (which includes Kubernetes, DC/OS & VMware running on multiple DCs across different geographic regions) is also referenced [here](https://portworx.com/architects-corner-kubernetes-satya-komala-nio/).
|
||||
|
||||
### Calico
|
||||
|
||||
[Calico](https://docs.projectcalico.org/) is an open source networking and network security solution for containers, virtual machines, and native host-based workloads. Calico supports multiple data planes including: a pure Linux eBPF dataplane, a standard Linux networking dataplane, and a Windows HNS dataplane. Calico provides a full networking stack but can also be used in conjunction with [cloud provider CNIs](https://docs.projectcalico.org/networking/determine-best-networking#calico-compatible-cni-plugins-and-cloud-provider-integrations) to provide network policy enforcement.
|
||||
|
||||
### Cilium
|
||||
|
||||
[Cilium](https://github.com/cilium/cilium) is open source software for
|
||||
@@ -291,14 +295,6 @@ stateful ACLs, load-balancers etc to build different virtual networking
|
||||
topologies. The project has a specific Kubernetes plugin and documentation
|
||||
at [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes).
|
||||
|
||||
### Project Calico
|
||||
|
||||
[Project Calico](https://docs.projectcalico.org/) is an open source container networking provider and network policy engine.
|
||||
|
||||
Calico provides a highly scalable networking and network policy solution for connecting Kubernetes pods based on the same IP networking principles as the internet, for both Linux (open source) and Windows (proprietary - available from [Tigera](https://www.tigera.io/essentials/)). Calico can be deployed without encapsulation or overlays to provide high-performance, high-scale data center networking. Calico also provides fine-grained, intent based network security policy for Kubernetes pods via its distributed firewall.
|
||||
|
||||
Calico can also be run in policy enforcement mode in conjunction with other networking solutions such as Flannel, aka [canal](https://github.com/tigera/canal), or native GCE, AWS or Azure networking.
|
||||
|
||||
### Romana
|
||||
|
||||
[Romana](https://romana.io) is an open source network and security automation solution that lets you deploy Kubernetes without an overlay network. Romana supports Kubernetes [Network Policy](/docs/concepts/services-networking/network-policies/) to provide isolation across network namespaces.
|
||||
|
||||
@@ -271,7 +271,7 @@ preempted. Here's an example:
|
||||
* Pod P is being considered for Node N.
|
||||
* Pod Q is running on another Node in the same Zone as Node N.
|
||||
* Pod P has Zone-wide anti-affinity with Pod Q (`topologyKey:
|
||||
failure-domain.beta.kubernetes.io/zone`).
|
||||
topology.kubernetes.io/zone`).
|
||||
* There are no other cases of anti-affinity between Pod P and other Pods in
|
||||
the Zone.
|
||||
* In order to schedule Pod P on Node N, Pod Q can be preempted, but scheduler
|
||||
|
||||
@@ -15,50 +15,379 @@ weight: 30
|
||||
Kubernetes Secrets let you store and manage sensitive information, such
|
||||
as passwords, OAuth tokens, and ssh keys. Storing confidential information in a Secret
|
||||
is safer and more flexible than putting it verbatim in a
|
||||
{{< glossary_tooltip term_id="pod" >}} definition or in a {{< glossary_tooltip text="container image" term_id="image" >}}. See [Secrets design document](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md) for more information.
|
||||
|
||||
{{< glossary_tooltip term_id="pod" >}} definition or in a
|
||||
{{< glossary_tooltip text="container image" term_id="image" >}}.
|
||||
See [Secrets design document](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md) for more information.
|
||||
|
||||
A Secret is an object that contains a small amount of sensitive data such as
|
||||
a password, a token, or a key. Such information might otherwise be put in a
|
||||
Pod specification or in an image. Users can create Secrets and the system
|
||||
also creates some Secrets.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Overview of Secrets
|
||||
|
||||
A Secret is an object that contains a small amount of sensitive data such as
|
||||
a password, a token, or a key. Such information might otherwise be put in a
|
||||
Pod specification or in an image. Users can create secrets and the system
|
||||
also creates some secrets.
|
||||
|
||||
To use a secret, a Pod needs to reference the secret.
|
||||
A secret can be used with a Pod in three ways:
|
||||
To use a Secret, a Pod needs to reference the Secret.
|
||||
A Secret can be used with a Pod in three ways:
|
||||
|
||||
- As [files](#using-secrets-as-files-from-a-pod) in a
|
||||
{{< glossary_tooltip text="volume" term_id="volume" >}} mounted on one or more of
|
||||
its containers.
|
||||
{{< glossary_tooltip text="volume" term_id="volume" >}} mounted on one or more of
|
||||
its containers.
|
||||
- As [container environment variable](#using-secrets-as-environment-variables).
|
||||
- By the [kubelet when pulling images](#using-imagepullsecrets) for the Pod.
|
||||
|
||||
The name of a Secret object must be a valid
|
||||
[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
|
||||
You can specify the `data` and/or the `stringData` field when creating a
|
||||
configuration file for a Secret. The `data` and the `stringData` fields are optional.
|
||||
The values for all keys in the `data` field have to be base64-encoded strings.
|
||||
If the conversion to base64 string is not desirable, you can choose to specify
|
||||
the `stringData` field instead, which accepts arbitrary strings as values.
|
||||
|
||||
The keys of `data` and `stringData` must consist of alphanumeric characters,
|
||||
`-`, `_` or `.`.
|
||||
`-`, `_` or `.`. All key-value pairs in the `stringData` field are internally
|
||||
merged into the `data` field. If a key appears in both the `data` and the
|
||||
`stringData` field, the value specified in the `stringData` field takes
|
||||
precedence.
|
||||
|
||||
### Built-in Secrets
|
||||
## Types of Secret {#secret-types}
|
||||
|
||||
#### Service accounts automatically create and attach Secrets with API credentials
|
||||
When creating a Secret, you can specify its type using the `type` field of
|
||||
the [`Secret`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)
|
||||
resource, or certain equivalent `kubectl` command line flags (if available).
|
||||
The Secret type is used to facilitate programmatic handling of the Secret data.
|
||||
|
||||
Kubernetes automatically creates secrets which contain credentials for
|
||||
accessing the API and automatically modifies your Pods to use this type of
|
||||
secret.
|
||||
Kubernetes provides several builtin types for some common usage scenarios.
|
||||
These types vary in terms of the validations performed and the constraints
|
||||
Kubernetes imposes on them.
|
||||
|
||||
The automatic creation and use of API credentials can be disabled or overridden
|
||||
if desired. However, if all you need to do is securely access the API server,
|
||||
this is the recommended workflow.
|
||||
| Builtin Type | Usage |
|
||||
|--------------|-------|
|
||||
| `Opaque` | arbitrary user-defined data |
|
||||
| `kubernetes.io/service-account-token` | service account token |
|
||||
| `kubernetes.io/dockercfg` | serialized `~/.dockercfg` file |
|
||||
| `kubernetes.io/dockerconfigjson` | serialized `~/.docker/config.json` file |
|
||||
| `kubernetes.io/basic-auth` | credentials for basic authentication |
|
||||
| `kubernetes.io/ssh-auth` | credentials for SSH authentication |
|
||||
| `kubernetes.io/tls` | data for a TLS client or server |
|
||||
| `bootstrap.kubernetes.io/token` | bootstrap token data |
|
||||
|
||||
You can define and use your own Secret type by assigning a non-empty string as the
|
||||
`type` value for a Secret object. An empty string is treated as an `Opaque` type.
|
||||
Kubernetes doesn't impose any constraints on the type name. However, if you
|
||||
are using one of the builtin types, you must meet all the requirements defined
|
||||
for that type.
|
||||
|
||||
### Opaque secrets
|
||||
|
||||
`Opaque` is the default Secret type if omitted from a Secret configuration file.
|
||||
When you create a Secret using `kubectl`, you will use the `generic`
|
||||
subcommand to indicate an `Opaque` Secret type. For example, the following
|
||||
command creates an empty Secret of type `Opaque`.
|
||||
|
||||
```shell
|
||||
kubectl create secret generic empty-secret
|
||||
kubectl get secret empty-secret
|
||||
```
|
||||
|
||||
The output looks like:
|
||||
|
||||
```
|
||||
NAME TYPE DATA AGE
|
||||
empty-secret Opaque 0 2m6s
|
||||
```
|
||||
|
||||
The `DATA` column shows the number of data items stored in the Secret.
|
||||
In this case, `0` means we have just created an empty Secret.
|
||||
|
||||
### Service account token Secrets
|
||||
|
||||
A `kubernetes.io/service-account-token` type of Secret is used to store a
|
||||
token that identifies a service account. When using this Secret type, you need
|
||||
to ensure that the `kubernetes.io/service-account.name` annotation is set to an
|
||||
existing service account name. An Kubernetes controller fills in some other
|
||||
fields such as the `kubernetes.io/service-account.uid` annotation and the
|
||||
`token` key in the `data` field set to actual token content.
|
||||
|
||||
The following example configuration declares a service account token Secret:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: secret-sa-sample
|
||||
annotations:
|
||||
kubernetes.io/service-account.name: "sa-name"
|
||||
type: kubernetes.io/service-account-token
|
||||
data:
|
||||
# You can include additional key value pairs as you do with Opaque Secrets
|
||||
extra: YmFyCg==
|
||||
```
|
||||
|
||||
When creating a `Pod`, Kubernetes automatically creates a service account Secret
|
||||
and automatically modifies your Pod to use this Secret. The service account token
|
||||
Secret contains credentials for accessing the API.
|
||||
|
||||
The automatic creation and use of API credentials can be disabled or
|
||||
overridden if desired. However, if all you need to do is securely access the
|
||||
API server, this is the recommended workflow.
|
||||
|
||||
See the [ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/)
|
||||
documentation for more information on how service accounts work.
|
||||
You can also check the `automountServiceAccountToken` field and the
|
||||
`serviceAccountName` field of the
|
||||
[`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)
|
||||
for information on referencing service account from Pods.
|
||||
|
||||
### Creating a Secret
|
||||
### Docker config Secrets
|
||||
|
||||
You can use one of the following `type` values to create a Secret to
|
||||
store the credentials for accessing a Docker registry for images.
|
||||
|
||||
- `kubernetes.io/dockercfg`
|
||||
- `kubernetes.io/dockerconfigjson`
|
||||
|
||||
The `kubernetes.io/dockercfg` type is reserved to store a serialized
|
||||
`~/.dockercfg` which is the legacy format for configuring Docker command line.
|
||||
When using this Secret type, you have to ensure the Secret `data` field
|
||||
contains a `.dockercfg` key whose value is content of a `~/.dockercfg` file
|
||||
encoded in the base64 format.
|
||||
|
||||
The `kubernetes/dockerconfigjson` type is designed for storing a serialized
|
||||
JSON that follows the same format rules as the `~/.docker/config.json` file
|
||||
which is a new format for `~/.dockercfg`.
|
||||
When using this Secret type, the `data` field of the Secret object must
|
||||
contain a `.dockerconfigjson` key, in which the content for the
|
||||
`~/.docker/config.json` file is provided as a base64 encoded string.
|
||||
|
||||
Below is an example for a `kubernetes.io/dockercfg` type of Secret:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: secret-dockercfg
|
||||
type: kubernetes.io/dockercfg
|
||||
data:
|
||||
.dockercfg: |
|
||||
"<base64 encoded ~/.dockercfg file>"
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
If you do not want to perform the base64 encoding, you can choose to use the
|
||||
`stringData` field instead.
|
||||
{{< /note >}}
|
||||
|
||||
When you create these types of Secrets using a manifest, the API
|
||||
server checks whether the expected key does exists in the `data` field, and
|
||||
it verifies if the value provided can be parsed as a valid JSON. The API
|
||||
server doesn't validate if the JSON actually is a Docker config file.
|
||||
|
||||
When you do not have a Docker config file, or you want to use `kubectl`
|
||||
to create a Docker registry Secret, you can do:
|
||||
|
||||
```shell
|
||||
kubectl create secret docker-registry secret-tiger-docker \
|
||||
--docker-username=tiger \
|
||||
--docker-password=pass113 \
|
||||
--docker-email=tiger@acme.com
|
||||
```
|
||||
|
||||
This command creates a Secret of type `kubernetes.io/dockerconfigjson`.
|
||||
If you dump the `.dockerconfigjson` content from the `data` field, you will
|
||||
get the following JSON content which is a valid Docker configuration created
|
||||
on the fly:
|
||||
|
||||
```json
|
||||
{
|
||||
"auths": {
|
||||
"https://index.docker.io/v1/": {
|
||||
"username": "tiger",
|
||||
"password": "pass113",
|
||||
"email": "tiger@acme.com",
|
||||
"auth": "dGlnZXI6cGFzczExMw=="
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Basic authentication Secret
|
||||
|
||||
The `kubernetes.io/basic-auth` type is provided for storing credentials needed
|
||||
for basic authentication. When using this Secret type, the `data` field of the
|
||||
Secret must contain the following two keys:
|
||||
|
||||
- `username`: the user name for authentication;
|
||||
- `password`: the password or token for authentication.
|
||||
|
||||
Both values for the above two keys are base64 encoded strings. You can, of
|
||||
course, provide the clear text content using the `stringData` for Secret
|
||||
creation.
|
||||
|
||||
The following YAML is an example config for a basic authentication Secret:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: secret-basic-auth
|
||||
type: kubernetes.io/basic-auth
|
||||
stringData:
|
||||
username: admin
|
||||
password: t0p-Secret
|
||||
```
|
||||
|
||||
The basic authentication Secret type is provided only for user's convenience.
|
||||
You can create an `Opaque` for credentials used for basic authentication.
|
||||
However, using the builtin Secret type helps unify the formats of your credentials
|
||||
and the API server does verify if the required keys are provided in a Secret
|
||||
configuration.
|
||||
|
||||
### SSH authentication secrets
|
||||
|
||||
The builtin type `kubernetes.io/ssh-auth` is provided for storing data used in
|
||||
SSH authentication. When using this Secret type, you will have to specify a
|
||||
`ssh-privatekey` key-value pair in the `data` (or `stringData`) field.
|
||||
as the SSH credential to use.
|
||||
|
||||
The following YAML is an example config for a SSH authentication Secret:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: secret-ssh-auth
|
||||
type: kubernetes.io/ssh-auth
|
||||
data:
|
||||
# the data is abbreviated in this example
|
||||
ssh-privatekey: |
|
||||
MIIEpQIBAAKCAQEAulqb/Y ...
|
||||
```
|
||||
|
||||
The SSH authentication Secret type is provided only for user's convenience.
|
||||
You can create an `Opaque` for credentials used for SSH authentication.
|
||||
However, using the builtin Secret type helps unify the formats of your credentials
|
||||
and the API server does verify if the required keys are provided in a Secret
|
||||
configuration.
|
||||
|
||||
### TLS secrets
|
||||
|
||||
Kubernetes provides a builtin Secret type `kubernetes.io/tls` for to storing
|
||||
a certificate and its associated key that are typically used for TLS . This
|
||||
data is primarily used with TLS termination of the Ingress resource, but may
|
||||
be used with other resources or directly by a workload.
|
||||
When using this type of Secret, the `tls.key` and the `tls.crt` key must be provided
|
||||
in the `data` (or `stringData`) field of the Secret configuration, although the API
|
||||
server doesn't actually validate the values for each key.
|
||||
|
||||
The following YAML contains an example config for a TLS Secret:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: secret-tls
|
||||
type: kubernetes.io/tls
|
||||
data:
|
||||
# the data is abbreviated in this example
|
||||
tls.crt: |
|
||||
MIIC2DCCAcCgAwIBAgIBATANBgkqh ...
|
||||
tls.key: |
|
||||
MIIEpgIBAAKCAQEA7yn3bRHQ5FHMQ ...
|
||||
```
|
||||
|
||||
The TLS Secret type is provided for user's convenience. You can create an `Opaque`
|
||||
for credentials used for TLS server and/or client. However, using the builtin Secret
|
||||
type helps ensure the consistency of Secret format in your project; the API server
|
||||
does verify if the required keys are provided in a Secret configuration.
|
||||
|
||||
When creating a TLS Secret using `kubectl`, you can use the `tls` subcommand
|
||||
as shown in the following example:
|
||||
|
||||
```shell
|
||||
kubectl create secret tls my-tls-secret \
|
||||
--cert=path/to/cert/file \
|
||||
--key=path/to/key/file
|
||||
```
|
||||
|
||||
The public/private key pair must exist before hand. The public key certificate
|
||||
for `--cert` must be .PEM encoded (Base64-encoded DER format), and match the
|
||||
given private key for `--key`.
|
||||
The private key must be in what is commonly called PEM private key format,
|
||||
unencrypted. In both cases, the initial and the last lines from PEM (for
|
||||
example, `--------BEGIN CERTIFICATE-----` and `-------END CERTIFICATE----` for
|
||||
a cetificate) are *not* included.
|
||||
|
||||
### Bootstrap token Secrets
|
||||
|
||||
A bootstrap token Secret can be created by explicitly specifying the Secret
|
||||
`type` to `bootstrap.kubernetes.io/token`. This type of Secret is designed for
|
||||
tokens used during the node bootstrap process. It stores tokens used to sign
|
||||
well known ConfigMaps.
|
||||
|
||||
A bootstrap token Secret is usually created in the `kube-system` namespace and
|
||||
named in the form `bootstrap-token-<token-id>` where `<token-id>` is a 6 character
|
||||
string of the token ID.
|
||||
|
||||
As a Kubernetes manifest, a bootstrap token Secret might look like the
|
||||
following:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: bootstrap-token-5emitj
|
||||
namespace: kube-system
|
||||
type: bootstrap.kubernetes.io/token
|
||||
data:
|
||||
auth-extra-groups: c3lzdGVtOmJvb3RzdHJhcHBlcnM6a3ViZWFkbTpkZWZhdWx0LW5vZGUtdG9rZW4=
|
||||
expiration: MjAyMC0wOS0xM1QwNDozOToxMFo=
|
||||
token-id: NWVtaXRq
|
||||
token-secret: a3E0Z2lodnN6emduMXAwcg==
|
||||
usage-bootstrap-authentication: dHJ1ZQ==
|
||||
usage-bootstrap-signing: dHJ1ZQ==
|
||||
```
|
||||
|
||||
A bootstrap type has the following keys specified under `data`:
|
||||
|
||||
- `token_id`: A random 6 character string as the token identifier. Required.
|
||||
- `token-secret`: A random 16 character string as the actual token secret. Required.
|
||||
- `description1`: A human-readable string that describes what the token is
|
||||
used for. Optional.
|
||||
- `expiration`: An absolute UTC time using RFC3339 specifying when the token
|
||||
should be expired. Optional.
|
||||
- `usage-bootstrap-<usage>`: A boolean flag indicating additional usage for
|
||||
the bootstrap token.
|
||||
- `auth-extra-groups`: A comma-separated list of group names that will be
|
||||
authenticated as in addition to system:bootstrappers group.
|
||||
|
||||
The above YAML may look confusing because the values are all in base64 encoded
|
||||
strings. In fact, you can create an identical Secret using the following YAML
|
||||
which results in an identical Secret object:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
# Note how the Secret is named
|
||||
name: bootstrap-token-5emitj
|
||||
# A bootstrap token Secret usually resides in the kube-system namespace
|
||||
namespace: kube-system
|
||||
type: bootstrap.kubernetes.io/token
|
||||
stringData:
|
||||
auth-extra-groups: "system:bootstrappers:kubeadm:default-node-token"
|
||||
expiration: "2020-09-13T04:39:10Z"
|
||||
# This token ID is used in the name
|
||||
token-id: "5emitj"
|
||||
token-secret: "kq4gihvszzgn1p0r"
|
||||
# This token can be used for authentication
|
||||
usage-bootstrap-authentication: "true"
|
||||
# and it can be used for signing
|
||||
usage-bootstrap-signing: "true"
|
||||
```
|
||||
|
||||
## Creating a Secret
|
||||
|
||||
There are several options to create a Secret:
|
||||
|
||||
@@ -66,7 +395,7 @@ There are several options to create a Secret:
|
||||
- [create Secret from config file](/docs/tasks/configmap-secret/managing-secret-using-config-file/)
|
||||
- [create Secret using kustomize](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
|
||||
|
||||
### Editing a Secret
|
||||
## Editing a Secret
|
||||
|
||||
An existing Secret may be edited with the following command:
|
||||
|
||||
|
||||
@@ -47,7 +47,7 @@ to roll back to a working version.
|
||||
Instead, specify a meaningful tag such as `v1.42.0`.
|
||||
{{< /caution >}}
|
||||
|
||||
## Updating Images
|
||||
## Updating images
|
||||
|
||||
The default pull policy is `IfNotPresent` which causes the
|
||||
{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} to skip
|
||||
@@ -61,13 +61,13 @@ you can do one of the following:
|
||||
|
||||
When `imagePullPolicy` is defined without a specific value, it is also set to `Always`.
|
||||
|
||||
## Multi-architecture Images with Manifests
|
||||
## Multi-architecture images with image indexes
|
||||
|
||||
As well as providing binary images, a container registry can also serve a [container image manifest](https://github.com/opencontainers/image-spec/blob/master/manifest.md). A manifest can reference image manifests for architecture-specific versions of a container. The idea is that you can have a name for an image (for example: `pause`, `example/mycontainer`, `kube-apiserver`) and allow different systems to fetch the right binary image for the machine architecture they are using.
|
||||
As well as providing binary images, a container registry can also serve a [container image index](https://github.com/opencontainers/image-spec/blob/master/image-index.md). An image index can point to multiple [image manifests](https://github.com/opencontainers/image-spec/blob/master/manifest.md) for architecture-specific versions of a container. The idea is that you can have a name for an image (for example: `pause`, `example/mycontainer`, `kube-apiserver`) and allow different systems to fetch the right binary image for the machine architecture they are using.
|
||||
|
||||
Kubernetes itself typically names container images with a suffix `-$(ARCH)`. For backward compatibility, please generate the older images with suffixes. The idea is to generate say `pause` image which has the manifest for all the arch(es) and say `pause-amd64` which is backwards compatible for older configurations or YAML files which may have hard coded the images with suffixes.
|
||||
|
||||
## Using a Private Registry
|
||||
## Using a private registry
|
||||
|
||||
Private registries may require keys to read images from them.
|
||||
Credentials can be provided in several ways:
|
||||
@@ -86,7 +86,7 @@ Credentials can be provided in several ways:
|
||||
|
||||
These options are explaind in more detail below.
|
||||
|
||||
### Configuring Nodes to authenticate to a Private Registry
|
||||
### Configuring nodes to authenticate to a private registry
|
||||
|
||||
If you run Docker on your nodes, you can configure the Docker container
|
||||
runtime to authenticate to a private container registry.
|
||||
@@ -178,7 +178,7 @@ template needs to include the `.docker/config.json` or mount a drive that contai
|
||||
All pods will have read access to images in any private registry once private
|
||||
registry keys are added to the `.docker/config.json`.
|
||||
|
||||
### Pre-pulled Images
|
||||
### Pre-pulled images
|
||||
|
||||
{{< note >}}
|
||||
This approach is suitable if you can control node configuration. It
|
||||
@@ -197,7 +197,7 @@ This can be used to preload certain images for speed or as an alternative to aut
|
||||
|
||||
All pods will have read access to any pre-pulled images.
|
||||
|
||||
### Specifying ImagePullSecrets on a Pod
|
||||
### Specifying imagePullSecrets on a Pod
|
||||
|
||||
{{< note >}}
|
||||
This is the recommended approach to run containers based on images
|
||||
@@ -206,7 +206,7 @@ in private registries.
|
||||
|
||||
Kubernetes supports specifying container image registry keys on a Pod.
|
||||
|
||||
#### Creating a Secret with a Docker Config
|
||||
#### Creating a Secret with a Docker config
|
||||
|
||||
Run the following command, substituting the appropriate uppercase values:
|
||||
|
||||
@@ -266,7 +266,7 @@ Check [Add ImagePullSecrets to a Service Account](/docs/tasks/configure-pod-cont
|
||||
You can use this in conjunction with a per-node `.docker/config.json`. The credentials
|
||||
will be merged.
|
||||
|
||||
## Use Cases
|
||||
## Use cases
|
||||
|
||||
There are a number of solutions for configuring private registries. Here are some
|
||||
common use cases and suggested solutions.
|
||||
|
||||
@@ -200,8 +200,8 @@ The affinity on this pod defines one pod affinity rule and one pod anti-affinity
|
||||
while the `podAntiAffinity` is `preferredDuringSchedulingIgnoredDuringExecution`. The
|
||||
pod affinity rule says that the pod can be scheduled onto a node only if that node is in the same zone
|
||||
as at least one already-running pod that has a label with key "security" and value "S1". (More precisely, the pod is eligible to run
|
||||
on node N if node N has a label with key `failure-domain.beta.kubernetes.io/zone` and some value V
|
||||
such that there is at least one node in the cluster with key `failure-domain.beta.kubernetes.io/zone` and
|
||||
on node N if node N has a label with key `topology.kubernetes.io/zone` and some value V
|
||||
such that there is at least one node in the cluster with key `topology.kubernetes.io/zone` and
|
||||
value V that is running a pod that has a label with key "security" and value "S1".) The pod anti-affinity
|
||||
rule says that the pod cannot be scheduled onto a node if that node is in the same zone as a pod with
|
||||
label having key "security" and value "S2". See the
|
||||
|
||||
@@ -215,7 +215,7 @@ As of Kubernetes 1.20, the following functionality does not exist in the Network
|
||||
- Forcing internal cluster traffic to go through a common gateway (this might be best served with a service mesh or other proxy).
|
||||
- Anything TLS related (use a service mesh or ingress controller for this).
|
||||
- Node specific policies (you can use CIDR notation for these, but you cannot target nodes by their Kubernetes identities specifically).
|
||||
- Targeting of namespaces or services by name (you can, however, target pods or namespaces by their{{< glossary_tooltip text="labels" term_id="label" >}}, which is often a viable workaround).
|
||||
- Targeting of namespaces or services by name (you can, however, target pods or namespaces by their {{< glossary_tooltip text="labels" term_id="label" >}}, which is often a viable workaround).
|
||||
- Creation or management of "Policy requests" that are fulfilled by a third party.
|
||||
- Default policies which are applied to all namespaces or pods (there are some third party Kubernetes distributions and projects which can do this).
|
||||
- Advanced policy querying and reachability tooling.
|
||||
|
||||
@@ -209,7 +209,7 @@ parameters:
|
||||
volumeBindingMode: WaitForFirstConsumer
|
||||
allowedTopologies:
|
||||
- matchLabelExpressions:
|
||||
- key: failure-domain.beta.kubernetes.io/zone
|
||||
- key: topology.kubernetes.io/zone
|
||||
values:
|
||||
- us-central1-a
|
||||
- us-central1-b
|
||||
|
||||
@@ -449,7 +449,7 @@ spec:
|
||||
required:
|
||||
nodeSelectorTerms:
|
||||
- matchExpressions:
|
||||
- key: failure-domain.beta.kubernetes.io/zone
|
||||
- key: topology.kubernetes.io/zone
|
||||
operator: In
|
||||
values:
|
||||
- us-central1-a
|
||||
@@ -1367,7 +1367,7 @@ For more information on how to develop a CSI driver, refer to the
|
||||
|
||||
#### Migrating to CSI drivers from in-tree plugins
|
||||
|
||||
{{< feature-state for_k8s_version="v1.17" state="alpha" >}}
|
||||
{{< feature-state for_k8s_version="v1.17" state="beta" >}}
|
||||
|
||||
The `CSIMigration` feature, when enabled, directs operations against existing in-tree
|
||||
plugins to corresponding CSI plugins (which are expected to be installed and configured).
|
||||
|
||||
@@ -534,8 +534,8 @@ and kubelets will not be allowed to modify labels with that prefix.
|
||||
* `kubernetes.io/os`
|
||||
* `beta.kubernetes.io/instance-type`
|
||||
* `node.kubernetes.io/instance-type`
|
||||
* `failure-domain.beta.kubernetes.io/region`
|
||||
* `failure-domain.beta.kubernetes.io/zone`
|
||||
* `failure-domain.beta.kubernetes.io/region` (deprecated)
|
||||
* `failure-domain.beta.kubernetes.io/zone` (deprecated)
|
||||
* `topology.kubernetes.io/region`
|
||||
* `topology.kubernetes.io/zone`
|
||||
* `kubelet.kubernetes.io/`-prefixed labels
|
||||
|
||||
@@ -243,7 +243,7 @@ for example:
|
||||
The validity duration of signed certificates can be configured with flag:
|
||||
|
||||
```
|
||||
--experimental-cluster-signing-duration
|
||||
--cluster-signing-duration
|
||||
```
|
||||
|
||||
### Approval
|
||||
|
||||
@@ -966,7 +966,7 @@ WindowsEndpointSliceProxying=true|false (ALPHA - default=false)<br/>
|
||||
<td colspan="2">--node-labels mapStringString</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;"><Warning: Alpha feature> Labels to add when registering the node in the cluster. Labels must be `key=value` pairs separated by `,`. Labels in the `kubernetes.io` namespace must begin with an allowed prefix (`kubelet.kubernetes.io`, `node.kubernetes.io`) or be in the specifically allowed set (`beta.kubernetes.io/arch`, `beta.kubernetes.io/instance-type`, `beta.kubernetes.io/os`, `failure-domain.beta.kubernetes.io/region`, `failure-domain.beta.kubernetes.io/zone`, `failure-domain.kubernetes.io/region`, `failure-domain.kubernetes.io/zone`, `kubernetes.io/arch`, `kubernetes.io/hostname`, `kubernetes.io/instance-type`, `kubernetes.io/os`)</td>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;"><Warning: Alpha feature>Labels to add when registering the node in the cluster. Labels must be `key=value pairs` separated by `,`. Labels in the `kubernetes.io` namespace must begin with an allowed prefix (`kubelet.kubernetes.io`, `node.kubernetes.io`) or be in the specifically allowed set (`beta.kubernetes.io/arch`, `beta.kubernetes.io/instance-type`, `beta.kubernetes.io/os`, `failure-domain.beta.kubernetes.io/region`, `failure-domain.beta.kubernetes.io/zone`, `kubernetes.io/arch`, `kubernetes.io/hostname`, `kubernetes.io/os`, `node.kubernetes.io/instance-type`, `topology.kubernetes.io/region`, `topology.kubernetes.io/zone`)</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
|
||||
Executable
+19
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: Object
|
||||
id: object
|
||||
date: 2020-10-12
|
||||
full_link: https://kubernetes.io/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects
|
||||
short_description: >
|
||||
A entity in the Kubernetes system, representing part of the state of your cluster.
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
---
|
||||
An entity in the Kubernetes system. The Kubernetes API uses these entities to represent the state
|
||||
of your cluster.
|
||||
<!--more-->
|
||||
A Kubernetes object is typically a “record of intent”—once you create the object, the Kubernetes
|
||||
{{< glossary_tooltip text="control plane" term_id="control-plane" >}} works constantly to ensure
|
||||
that the item it represents actually exists.
|
||||
By creating an object, you're effectively telling the Kubernetes system what you want that part of
|
||||
your cluster's workload to look like; this is your cluster's desired state.
|
||||
@@ -38,7 +38,7 @@ This label has been deprecated. Please use `kubernetes.io/arch` instead.
|
||||
|
||||
This label has been deprecated. Please use `kubernetes.io/os` instead.
|
||||
|
||||
## kubernetes.io/hostname
|
||||
## kubernetes.io/hostname {#kubernetesiohostname}
|
||||
|
||||
Example: `kubernetes.io/hostname=ip-172-20-114-199.ec2.internal`
|
||||
|
||||
@@ -46,6 +46,8 @@ Used on: Node
|
||||
|
||||
The Kubelet populates this label with the hostname. Note that the hostname can be changed from the "actual" hostname by passing the `--hostname-override` flag to the `kubelet`.
|
||||
|
||||
This label is also used as part of the topology hierarchy. See [topology.kubernetes.io/zone](#topologykubernetesiozone) for more information.
|
||||
|
||||
## beta.kubernetes.io/instance-type (deprecated)
|
||||
|
||||
{{< note >}} Starting in v1.17, this label is deprecated in favor of [node.kubernetes.io/instance-type](#nodekubernetesioinstance-type). {{< /note >}}
|
||||
@@ -63,71 +65,52 @@ to rely on the Kubernetes scheduler to perform resource-based scheduling. You sh
|
||||
|
||||
## failure-domain.beta.kubernetes.io/region (deprecated) {#failure-domainbetakubernetesioregion}
|
||||
|
||||
See [failure-domain.beta.kubernetes.io/zone](#failure-domainbetakubernetesiozone).
|
||||
See [topology.kubernetes.io/region](#topologykubernetesioregion).
|
||||
|
||||
{{< note >}} Starting in v1.17, this label is deprecated in favor of [topology.kubernetes.io/region](#topologykubernetesioregion). {{< /note >}}
|
||||
|
||||
## failure-domain.beta.kubernetes.io/zone (deprecated) {#failure-domainbetakubernetesiozone}
|
||||
|
||||
Example:
|
||||
|
||||
`failure-domain.beta.kubernetes.io/region=us-east-1`
|
||||
|
||||
`failure-domain.beta.kubernetes.io/zone=us-east-1c`
|
||||
|
||||
Used on: Node, PersistentVolume
|
||||
|
||||
On the Node: The `kubelet` populates this with the zone information as defined by the `cloudprovider`.
|
||||
This will be set only if you are using a `cloudprovider`. However, you should consider setting this
|
||||
on the nodes if it makes sense in your topology.
|
||||
|
||||
On the PersistentVolume: The `PersistentVolumeLabel` admission controller will automatically add zone labels to PersistentVolumes, on GCE and AWS.
|
||||
|
||||
Kubernetes will automatically spread the Pods in a replication controller or service across nodes in a single-zone cluster (to reduce the impact of failures). With multiple-zone clusters, this spreading behaviour is extended across zones (to reduce the impact of zone failures). This is achieved via _SelectorSpreadPriority_.
|
||||
|
||||
_SelectorSpreadPriority_ is a best effort placement. If the zones in your cluster are heterogeneous (for example: different numbers of nodes, different types of nodes, or different pod resource requirements), this placement might prevent equal spreading of your Pods across zones. If desired, you can use homogenous zones (same number and types of nodes) to reduce the probability of unequal spreading.
|
||||
|
||||
The scheduler (through the _VolumeZonePredicate_ predicate) also will ensure that Pods, that claim a given volume, are only placed into the same zone as that volume. Volumes cannot be attached across zones.
|
||||
|
||||
The actual values of zone and region don't matter. Nor is the node hierarchy rigidly defined.
|
||||
The expectation is that failures of nodes in different zones should be uncorrelated unless the entire region has failed. For example, zones should typically avoid sharing a single network switch. The exact mapping depends on your particular infrastructure - a three rack installation will choose a very different setup to a multi-datacenter configuration.
|
||||
|
||||
If `PersistentVolumeLabel` does not support automatic labeling of your PersistentVolumes, you should consider
|
||||
adding the labels manually (or adding support for `PersistentVolumeLabel`). With `PersistentVolumeLabel`, the scheduler prevents Pods from mounting volumes in a different zone. If your infrastructure doesn't have this constraint, you don't need to add the zone labels to the volumes at all.
|
||||
See [topology.kubernetes.io/zone](#topologykubernetesiozone).
|
||||
|
||||
{{< note >}} Starting in v1.17, this label is deprecated in favor of [topology.kubernetes.io/zone](#topologykubernetesiozone). {{< /note >}}
|
||||
|
||||
## topology.kubernetes.io/region {#topologykubernetesioregion}
|
||||
|
||||
Example:
|
||||
|
||||
`topology.kubernetes.io/region=us-east-1`
|
||||
|
||||
See [topology.kubernetes.io/zone](#topologykubernetesiozone).
|
||||
|
||||
## topology.kubernetes.io/zone {#topologykubernetesiozone}
|
||||
|
||||
Example:
|
||||
|
||||
`topology.kubernetes.io/region=us-east-1`
|
||||
|
||||
`topology.kubernetes.io/zone=us-east-1c`
|
||||
|
||||
Used on: Node, PersistentVolume
|
||||
|
||||
On the Node: The `kubelet` populates this with the zone information as defined by the `cloudprovider`.
|
||||
This will be set only if you are using a `cloudprovider`. However, you should consider setting this
|
||||
on the nodes if it makes sense in your topology.
|
||||
On Node: The `kubelet` or the external `cloud-controller-manager` populates this with the information as provided by the `cloudprovider`. This will be set only if you are using a `cloudprovider`. However, you should consider setting this on nodes if it makes sense in your topology.
|
||||
|
||||
On the PersistentVolume: The `PersistentVolumeLabel` admission controller will automatically add zone labels to PersistentVolumes, on GCE and AWS.
|
||||
On PersistentVolume: topology-aware volume provisioners will automatically set node affinity constraints on `PersistentVolumes`.
|
||||
|
||||
Kubernetes will automatically spread the Pods in a replication controller or service across nodes in a single-zone cluster (to reduce the impact of failures). With multiple-zone clusters, this spreading behaviour is extended across zones (to reduce the impact of zone failures). This is achieved via _SelectorSpreadPriority_.
|
||||
A zone represents a logical failure domain. It is common for Kubernetes clusters to span multiple zones for increased availability. While the exact definition of a zone is left to infrastructure implementations, common properties of a zone include very low network latency within a zone, no-cost network traffic within a zone, and failure independence from other zones. For example, nodes within a zone might share a network switch, but nodes in different zones should not.
|
||||
|
||||
A region represents a larger domain, made up of one or more zones. It is uncommon for Kubernetes clusters to span multiple regions, While the exact definition of a zone or region is left to infrastructure implementations, common properties of a region include higher network latency between them than within them, non-zero cost for network traffic between them, and failure independence from other zones or regions. For example, nodes within a region might share power infrastructure (e.g. a UPS or generator), but nodes in different regions typically would not.
|
||||
|
||||
Kubernetes makes a few assumptions about the structure of zones and regions:
|
||||
1) regions and zones are hierarchical: zones are strict subsets of regions and no zone can be in 2 regions
|
||||
2) zone names are unique across regions; for example region "africa-east-1" might be comprised of zones "africa-east-1a" and "africa-east-1b"
|
||||
|
||||
It should be safe to assume that topology labels do not change. Even though labels are strictly mutable, consumers of them can assume that a given node is not going to be moved between zones without being destroyed and recreated.
|
||||
|
||||
Kubernetes can use this information in various ways. For example, the scheduler automatically tries to spread the Pods in a ReplicaSet across nodes in a single-zone cluster (to reduce the impact of node failures, see [kubernetes.io/hostname](#kubernetesiohostname)). With multiple-zone clusters, this spreading behavior also applies to zones (to reduce the impact of zone failures). This is achieved via _SelectorSpreadPriority_.
|
||||
|
||||
_SelectorSpreadPriority_ is a best effort placement. If the zones in your cluster are heterogeneous (for example: different numbers of nodes, different types of nodes, or different pod resource requirements), this placement might prevent equal spreading of your Pods across zones. If desired, you can use homogenous zones (same number and types of nodes) to reduce the probability of unequal spreading.
|
||||
|
||||
The scheduler (through the _VolumeZonePredicate_ predicate) also will ensure that Pods, that claim a given volume, are only placed into the same zone as that volume. Volumes cannot be attached across zones.
|
||||
|
||||
The actual values of zone and region don't matter. Nor is the node hierarchy rigidly defined.
|
||||
The expectation is that failures of nodes in different zones should be uncorrelated unless the entire region has failed. For example, zones should typically avoid sharing a single network switch. The exact mapping depends on your particular infrastructure - a three rack installation will choose a very different setup to a multi-datacenter configuration.
|
||||
|
||||
If `PersistentVolumeLabel` does not support automatic labeling of your PersistentVolumes, you should consider
|
||||
adding the labels manually (or adding support for `PersistentVolumeLabel`). With `PersistentVolumeLabel`, the scheduler prevents Pods from mounting volumes in a different zone. If your infrastructure doesn't have this constraint, you don't need to add the zone labels to the volumes at all.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -31,13 +31,6 @@ For general background information, read
|
||||
describes how clients can authenticate to the Kubernetes API server, and how their
|
||||
requests are authorized.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
The REST API is the fundamental fabric of Kubernetes. All operations and
|
||||
communications between components, and external user commands are REST API
|
||||
calls that the API Server handles. Consequently, everything in the Kubernetes
|
||||
platform is treated as an API object and has a corresponding entry in the
|
||||
API.
|
||||
|
||||
## API versioning
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ reviewers:
|
||||
- bart0sh
|
||||
title: Container runtimes
|
||||
content_type: concept
|
||||
weight: 10
|
||||
weight: 20
|
||||
---
|
||||
<!-- overview -->
|
||||
|
||||
@@ -85,6 +85,7 @@ net.ipv4.ip_forward = 1
|
||||
net.bridge.bridge-nf-call-ip6tables = 1
|
||||
EOF
|
||||
|
||||
# Apply sysctl params without reboot
|
||||
sudo sysctl --system
|
||||
```
|
||||
|
||||
@@ -102,7 +103,7 @@ sudo apt-get update && sudo apt-get install -y apt-transport-https ca-certificat
|
||||
|
||||
```shell
|
||||
## Add Docker's official GPG key
|
||||
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add --keyring /etc/apt/trusted.gpg.d/docker.gpg -
|
||||
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key --keyring /etc/apt/trusted.gpg.d/docker.gpg add -
|
||||
```
|
||||
|
||||
```shell
|
||||
@@ -257,8 +258,8 @@ cat <<EOF | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cr
|
||||
deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /
|
||||
EOF
|
||||
|
||||
curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | sudo apt-key add --keyring /etc/apt/trusted.gpg.d/libcontainers.gpg -
|
||||
curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | sudo apt-key add --keyring /etc/apt/trusted.gpg.d/libcontainers.gpg -
|
||||
curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | sudo apt-key --keyring /etc/apt/trusted.gpg.d/libcontainers.gpg add -
|
||||
curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | sudo apt-key --keyring /etc/apt/trusted.gpg.d/libcontainers.gpg add -
|
||||
|
||||
sudo apt-get update
|
||||
sudo apt-get install cri-o cri-o-runc
|
||||
@@ -293,8 +294,8 @@ cat <<EOF | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cr
|
||||
deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /
|
||||
EOF
|
||||
|
||||
curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | sudo apt-key add --keyring /etc/apt/trusted.gpg.d/libcontainers.gpg
|
||||
curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | sudo apt-key add --keyring /etc/apt/trusted.gpg.d/libcontainers-cri-o.gpg -
|
||||
curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | sudo apt-key --keyring /etc/apt/trusted.gpg.d/libcontainers.gpg add -
|
||||
curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | sudo apt-key --keyring /etc/apt/trusted.gpg.d/libcontainers-cri-o.gpg add -
|
||||
|
||||
sudo apt-get update
|
||||
sudo apt-get install cri-o cri-o-runc
|
||||
@@ -387,7 +388,7 @@ sudo apt-get update && sudo apt-get install -y \
|
||||
|
||||
```shell
|
||||
# Add Docker's official GPG key:
|
||||
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add --keyring /etc/apt/trusted.gpg.d/docker.gpg -
|
||||
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key --keyring /etc/apt/trusted.gpg.d/docker.gpg add -
|
||||
```
|
||||
|
||||
```shell
|
||||
@@ -421,6 +422,7 @@ EOF
|
||||
```
|
||||
|
||||
```shell
|
||||
# Create /etc/systemd/system/docker.service.d
|
||||
sudo mkdir -p /etc/systemd/system/docker.service.d
|
||||
```
|
||||
|
||||
@@ -476,6 +478,7 @@ EOF
|
||||
```
|
||||
|
||||
```shell
|
||||
# Create /etc/systemd/system/docker.service.d
|
||||
sudo mkdir -p /etc/systemd/system/docker.service.d
|
||||
```
|
||||
|
||||
|
||||
@@ -0,0 +1,14 @@
|
||||
---
|
||||
title: Turnkey Cloud Solutions
|
||||
content_type: concept
|
||||
weight: 30
|
||||
---
|
||||
<!-- overview -->
|
||||
|
||||
This page provides a list of Kubernetes certified solution providers. From each
|
||||
provider page, you can learn how to install and setup production
|
||||
ready clusters.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
{{< cncf-landscape helpers=true category="certified-kubernetes-hosted" >}}
|
||||
@@ -1,4 +0,0 @@
|
||||
---
|
||||
title: Turnkey Cloud Solutions
|
||||
weight: 30
|
||||
---
|
||||
@@ -1,20 +0,0 @@
|
||||
---
|
||||
reviewers:
|
||||
- colemickens
|
||||
- brendandburns
|
||||
title: Running Kubernetes on Alibaba Cloud
|
||||
---
|
||||
|
||||
## Alibaba Cloud Container Service
|
||||
|
||||
The [Alibaba Cloud Container Service](https://www.alibabacloud.com/product/container-service) lets you run and manage Docker applications on a cluster of either Alibaba Cloud ECS instances or in a Serverless fashion. It supports the popular open source container orchestrators: Docker Swarm and Kubernetes.
|
||||
|
||||
To simplify cluster deployment and management, use [Kubernetes Support for Alibaba Cloud Container Service](https://www.alibabacloud.com/product/kubernetes). You can get started quickly by following the [Kubernetes walk-through](https://www.alibabacloud.com/help/doc-detail/86737.htm), and there are some [tutorials for Kubernetes Support on Alibaba Cloud](https://yq.aliyun.com/teams/11/type_blog-cid_200-page_1) in Chinese.
|
||||
|
||||
To use custom binaries or open source Kubernetes, follow the instructions below.
|
||||
|
||||
## Custom Deployments
|
||||
|
||||
The source code for [Kubernetes with Alibaba Cloud provider implementation](https://github.com/AliyunContainerService/kubernetes) is open source and available on GitHub.
|
||||
|
||||
For more information, see "[Quick deployment of Kubernetes - VPC environment on Alibaba Cloud](https://www.alibabacloud.com/forum/read-830)" in English.
|
||||
@@ -1,88 +0,0 @@
|
||||
---
|
||||
reviewers:
|
||||
- justinsb
|
||||
- clove
|
||||
title: Running Kubernetes on AWS EC2
|
||||
content_type: task
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
This page describes how to install a Kubernetes cluster on AWS.
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
To create a Kubernetes cluster on AWS, you will need an Access Key ID and a Secret Access Key from AWS.
|
||||
|
||||
### Supported Production Grade Tools
|
||||
|
||||
* [conjure-up](https://docs.conjure-up.io/stable/en/cni/k8s-and-aws) is an open-source installer for Kubernetes that creates Kubernetes clusters with native AWS integrations on Ubuntu.
|
||||
|
||||
* [Kubernetes Operations](https://github.com/kubernetes/kops) - Production Grade K8s Installation, Upgrades, and Management. Supports running Debian, Ubuntu, CentOS, and RHEL in AWS.
|
||||
|
||||
* [kube-aws](https://github.com/kubernetes-retired/kube-aws), creates and manages Kubernetes clusters with [Flatcar Linux](https://www.flatcar-linux.org/) nodes, using AWS tools: EC2, CloudFormation and Autoscaling.
|
||||
|
||||
* [KubeOne](https://github.com/kubermatic/kubeone) is an open source cluster lifecycle management tool that creates, upgrades and manages Kubernetes Highly-Available clusters.
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Getting started with your cluster
|
||||
|
||||
### Command line administration tool: kubectl
|
||||
|
||||
The cluster startup script will leave you with a `kubernetes` directory on your workstation.
|
||||
Alternately, you can download the latest Kubernetes release from [this page](https://github.com/kubernetes/kubernetes/releases).
|
||||
|
||||
Next, add the appropriate binary folder to your `PATH` to access kubectl:
|
||||
|
||||
```shell
|
||||
# macOS
|
||||
export PATH=<path/to/kubernetes-directory>/platforms/darwin/amd64:$PATH
|
||||
|
||||
# Linux
|
||||
export PATH=<path/to/kubernetes-directory>/platforms/linux/amd64:$PATH
|
||||
```
|
||||
|
||||
An up-to-date documentation page for this tool is available here: [kubectl manual](/docs/reference/kubectl/kubectl/)
|
||||
|
||||
By default, `kubectl` will use the `kubeconfig` file generated during the cluster startup for authenticating against the API.
|
||||
For more information, please read [kubeconfig files](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
|
||||
|
||||
### Examples
|
||||
|
||||
See [a simple nginx example](/docs/tasks/run-application/run-stateless-application-deployment/) to try out your new cluster.
|
||||
|
||||
The "Guestbook" application is another popular example to get started with Kubernetes: [guestbook example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/)
|
||||
|
||||
For more complete applications, please look in the [examples directory](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/)
|
||||
|
||||
## Scaling the cluster
|
||||
|
||||
Adding and removing nodes through `kubectl` is not supported. You can still scale the amount of nodes manually through adjustments of the 'Desired' and 'Max' properties within the
|
||||
[Auto Scaling Group](https://docs.aws.amazon.com/autoscaling/latest/userguide/as-manual-scaling.html), which was created during the installation.
|
||||
|
||||
## Tearing down the cluster
|
||||
|
||||
Make sure the environment variables you used to provision your cluster are still exported, then call the following script inside the
|
||||
`kubernetes` directory:
|
||||
|
||||
```shell
|
||||
cluster/kube-down.sh
|
||||
```
|
||||
|
||||
## Support Level
|
||||
|
||||
|
||||
IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level
|
||||
-------------------- | ------------ | ------------- | ---------- | --------------------------------------------- | ---------| ----------------------------
|
||||
AWS | kops | Debian | k8s (VPC) | [docs](https://github.com/kubernetes/kops) | | Community ([@justinsb](https://github.com/justinsb))
|
||||
AWS | CoreOS | CoreOS | flannel | - | | Community
|
||||
AWS | Juju | Ubuntu | flannel, calico, canal | - | 100% | Commercial, Community
|
||||
AWS | KubeOne | Ubuntu, CoreOS, CentOS | canal, weavenet | [docs](https://github.com/kubermatic/kubeone) | 100% | Commercial, Community
|
||||
|
||||
|
||||
@@ -1,36 +0,0 @@
|
||||
---
|
||||
reviewers:
|
||||
- colemickens
|
||||
- brendandburns
|
||||
title: Running Kubernetes on Azure
|
||||
---
|
||||
|
||||
## Azure Kubernetes Service (AKS)
|
||||
|
||||
The [Azure Kubernetes Service](https://azure.microsoft.com/en-us/services/kubernetes-service/) offers simple
|
||||
deployments for Kubernetes clusters.
|
||||
|
||||
For an example of deploying a Kubernetes cluster onto Azure via the Azure Kubernetes Service:
|
||||
|
||||
**[Microsoft Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/intro-kubernetes)**
|
||||
|
||||
## Custom Deployments: AKS-Engine
|
||||
|
||||
The core of the Azure Kubernetes Service is **open source** and available on GitHub for the community
|
||||
to use and contribute to: **[AKS-Engine](https://github.com/Azure/aks-engine)**. The legacy [ACS-Engine](https://github.com/Azure/acs-engine) codebase has been deprecated in favor of AKS-engine.
|
||||
|
||||
AKS-Engine is a good choice if you need to make customizations to the deployment beyond what the Azure Kubernetes
|
||||
Service officially supports. These customizations include deploying into existing virtual networks, utilizing multiple
|
||||
agent pools, and more. Some community contributions to AKS-Engine may even become features of the Azure Kubernetes Service.
|
||||
|
||||
The input to AKS-Engine is an apimodel JSON file describing the Kubernetes cluster. It is similar to the Azure Resource Manager (ARM) template syntax used to deploy a cluster directly with the Azure Kubernetes Service. The resulting output is an ARM template that can be checked into source control and used to deploy Kubernetes clusters to Azure.
|
||||
|
||||
You can get started by following the **[AKS-Engine Kubernetes Tutorial](https://github.com/Azure/aks-engine/blob/master/docs/tutorials/README.md)**.
|
||||
|
||||
## CoreOS Tectonic for Azure
|
||||
|
||||
The CoreOS Tectonic Installer for Azure is **open source** and available on GitHub for the community to use and contribute to: **[Tectonic Installer](https://github.com/coreos/tectonic-installer)**.
|
||||
|
||||
Tectonic Installer is a good choice when you need to make cluster customizations as it is built on [Hashicorp's Terraform](https://www.terraform.io/docs/providers/azurerm/) Azure Resource Manager (ARM) provider. This enables users to customize or integrate using familiar Terraform tooling.
|
||||
|
||||
You can get started using the [Tectonic Installer for Azure Guide](https://coreos.com/tectonic/docs/latest/install/azure/azure-terraform.html).
|
||||
@@ -1,223 +0,0 @@
|
||||
---
|
||||
reviewers:
|
||||
- brendandburns
|
||||
- jbeda
|
||||
- mikedanese
|
||||
- thockin
|
||||
title: Running Kubernetes on Google Compute Engine
|
||||
content_type: task
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
The example below creates a Kubernetes cluster with 3 worker node Virtual Machines and a master Virtual Machine (i.e. 4 VMs in your cluster). This cluster is set up and controlled from your workstation (or wherever you find convenient).
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
If you want a simplified getting started experience and GUI for managing clusters, please consider trying [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) for hosted cluster installation and management.
|
||||
|
||||
For an easy way to experiment with the Kubernetes development environment, click the button below
|
||||
to open a Google Cloud Shell with an auto-cloned copy of the Kubernetes source repo.
|
||||
|
||||
[](https://console.cloud.google.com/cloudshell/open?git_repo=https://github.com/kubernetes/kubernetes&page=editor&open_in_editor=README.md)
|
||||
|
||||
If you want to use custom binaries or pure open source Kubernetes, please continue with the instructions below.
|
||||
|
||||
### Prerequisites
|
||||
|
||||
1. You need a Google Cloud Platform account with billing enabled. Visit the [Google Developers Console](https://console.cloud.google.com) for more details.
|
||||
1. Install `gcloud` as necessary. `gcloud` can be installed as a part of the [Google Cloud SDK](https://cloud.google.com/sdk/).
|
||||
1. Enable the [Compute Engine Instance Group Manager API](https://console.developers.google.com/apis/api/replicapool.googleapis.com/overview) in the [Google Cloud developers console](https://console.developers.google.com/apis/library).
|
||||
1. Make sure that gcloud is set to use the Google Cloud Platform project you want. You can check the current project using `gcloud config list project` and change it via `gcloud config set project <project-id>`.
|
||||
1. Make sure you have credentials for GCloud by running `gcloud auth login`.
|
||||
1. (Optional) In order to make API calls against GCE, you must also run `gcloud auth application-default login`.
|
||||
1. Make sure you can start up a GCE VM from the command line. At least make sure you can do the [Create an instance](https://cloud.google.com/compute/docs/instances/#startinstancegcloud) part of the GCE Quickstart.
|
||||
1. Make sure you can SSH into the VM without interactive prompts. See the [Log in to the instance](https://cloud.google.com/compute/docs/instances/#sshing) part of the GCE Quickstart.
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Starting a cluster
|
||||
|
||||
You can install a client and start a cluster with either one of these commands (we list both in case only one is installed on your machine):
|
||||
|
||||
|
||||
```shell
|
||||
curl -sS https://get.k8s.io | bash
|
||||
```
|
||||
|
||||
or
|
||||
|
||||
```shell
|
||||
wget -q -O - https://get.k8s.io | bash
|
||||
```
|
||||
|
||||
Once this command completes, you will have a master VM and four worker VMs, running as a Kubernetes cluster.
|
||||
|
||||
By default, some containers will already be running on your cluster. Containers like `fluentd` provide [logging](/docs/concepts/cluster-administration/logging/), while `heapster` provides [monitoring](https://releases.k8s.io/master/cluster/addons/cluster-monitoring/README.md) services.
|
||||
|
||||
The script run by the commands above creates a cluster with the name/prefix "kubernetes". It defines one specific cluster config, so you can't run it more than once.
|
||||
|
||||
Alternately, you can download and install the latest Kubernetes release from [this page](https://github.com/kubernetes/kubernetes/releases), then run the `<kubernetes>/cluster/kube-up.sh` script to start the cluster:
|
||||
|
||||
```shell
|
||||
cd kubernetes
|
||||
cluster/kube-up.sh
|
||||
```
|
||||
|
||||
If you want more than one cluster running in your project, want to use a different name, or want a different number of worker nodes, see the `<kubernetes>/cluster/gce/config-default.sh` file for more fine-grained configuration before you start up your cluster.
|
||||
|
||||
If you run into trouble, please see the section on [troubleshooting](/docs/setup/production-environment/turnkey/gce/#troubleshooting), post to the
|
||||
[Kubernetes Forum](https://discuss.kubernetes.io), or come ask questions on `#gke` Slack channel.
|
||||
|
||||
The next few steps will show you:
|
||||
|
||||
1. How to set up the command line client on your workstation to manage the cluster
|
||||
1. Examples of how to use the cluster
|
||||
1. How to delete the cluster
|
||||
1. How to start clusters with non-default options (like larger clusters)
|
||||
|
||||
## Installing the Kubernetes command line tools on your workstation
|
||||
|
||||
The cluster startup script will leave you with a running cluster and a `kubernetes` directory on your workstation.
|
||||
|
||||
The [kubectl](/docs/reference/kubectl/kubectl/) tool controls the Kubernetes cluster
|
||||
manager. It lets you inspect your cluster resources, create, delete, and update
|
||||
components, and much more. You will use it to look at your new cluster and bring
|
||||
up example apps.
|
||||
|
||||
You can use `gcloud` to install the `kubectl` command-line tool on your workstation:
|
||||
|
||||
```shell
|
||||
gcloud components install kubectl
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
The kubectl version bundled with `gcloud` may be older than the one
|
||||
downloaded by the get.k8s.io install script. See [Installing kubectl](/docs/tasks/tools/install-kubectl/)
|
||||
document to see how you can set up the latest `kubectl` on your workstation.
|
||||
{{< /note >}}
|
||||
|
||||
## Getting started with your cluster
|
||||
|
||||
### Inspect your cluster
|
||||
|
||||
Once `kubectl` is in your path, you can use it to look at your cluster. E.g., running:
|
||||
|
||||
```shell
|
||||
kubectl get --all-namespaces services
|
||||
```
|
||||
|
||||
should show a set of [services](/docs/concepts/services-networking/service/) that look something like this:
|
||||
|
||||
```shell
|
||||
NAMESPACE NAME TYPE CLUSTER_IP EXTERNAL_IP PORT(S) AGE
|
||||
default kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 1d
|
||||
kube-system kube-dns ClusterIP 10.0.0.2 <none> 53/TCP,53/UDP 1d
|
||||
kube-system kube-ui ClusterIP 10.0.0.3 <none> 80/TCP 1d
|
||||
...
|
||||
```
|
||||
|
||||
Similarly, you can take a look at the set of [pods](/docs/concepts/workloads/pods/) that were created during cluster startup.
|
||||
You can do this via the
|
||||
|
||||
```shell
|
||||
kubectl get --all-namespaces pods
|
||||
```
|
||||
|
||||
command.
|
||||
|
||||
You'll see a list of pods that looks something like this (the name specifics will be different):
|
||||
|
||||
```shell
|
||||
NAMESPACE NAME READY STATUS RESTARTS AGE
|
||||
kube-system coredns-5f4fbb68df-mc8z8 1/1 Running 0 15m
|
||||
kube-system fluentd-cloud-logging-kubernetes-minion-63uo 1/1 Running 0 14m
|
||||
kube-system fluentd-cloud-logging-kubernetes-minion-c1n9 1/1 Running 0 14m
|
||||
kube-system fluentd-cloud-logging-kubernetes-minion-c4og 1/1 Running 0 14m
|
||||
kube-system fluentd-cloud-logging-kubernetes-minion-ngua 1/1 Running 0 14m
|
||||
kube-system kube-ui-v1-curt1 1/1 Running 0 15m
|
||||
kube-system monitoring-heapster-v5-ex4u3 1/1 Running 1 15m
|
||||
kube-system monitoring-influx-grafana-v1-piled 2/2 Running 0 15m
|
||||
```
|
||||
|
||||
Some of the pods may take a few seconds to start up (during this time they'll show `Pending`), but check that they all show as `Running` after a short period.
|
||||
|
||||
### Run some examples
|
||||
|
||||
Then, see [a simple nginx example](/docs/tasks/run-application/run-stateless-application-deployment/) to try out your new cluster.
|
||||
|
||||
For more complete applications, please look in the [examples directory](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/). The [guestbook example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) is a good "getting started" walkthrough.
|
||||
|
||||
## Tearing down the cluster
|
||||
|
||||
To remove/delete/teardown the cluster, use the `kube-down.sh` script.
|
||||
|
||||
```shell
|
||||
cd kubernetes
|
||||
cluster/kube-down.sh
|
||||
```
|
||||
|
||||
Likewise, the `kube-up.sh` in the same directory will bring it back up. You do not need to rerun the `curl` or `wget` command: everything needed to setup the Kubernetes cluster is now on your workstation.
|
||||
|
||||
## Customizing
|
||||
|
||||
The script above relies on Google Storage to stage the Kubernetes release. It
|
||||
then will start (by default) a single master VM along with 3 worker VMs. You
|
||||
can tweak some of these parameters by editing `kubernetes/cluster/gce/config-default.sh`
|
||||
You can view a transcript of a successful cluster creation
|
||||
[here](https://gist.github.com/satnam6502/fc689d1b46db9772adea).
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Project settings
|
||||
|
||||
You need to have the Google Cloud Storage API, and the Google Cloud Storage
|
||||
JSON API enabled. It is activated by default for new projects. Otherwise, it
|
||||
can be done in the Google Cloud Console. See the [Google Cloud Storage JSON
|
||||
API Overview](https://cloud.google.com/storage/docs/json_api/) for more
|
||||
details.
|
||||
|
||||
Also ensure that-- as listed in the [Prerequisites section](#prerequisites)-- you've enabled the `Compute Engine Instance Group Manager API`, and can start up a GCE VM from the command line as in the [GCE Quickstart](https://cloud.google.com/compute/docs/quickstart) instructions.
|
||||
|
||||
### Cluster initialization hang
|
||||
|
||||
If the Kubernetes startup script hangs waiting for the API to be reachable, you can troubleshoot by SSHing into the master and node VMs and looking at logs such as `/var/log/startupscript.log`.
|
||||
|
||||
**Once you fix the issue, you should run `kube-down.sh` to cleanup** after the partial cluster creation, before running `kube-up.sh` to try again.
|
||||
|
||||
### SSH
|
||||
|
||||
If you're having trouble SSHing into your instances, ensure the GCE firewall
|
||||
isn't blocking port 22 to your VMs. By default, this should work but if you
|
||||
have edited firewall rules or created a new non-default network, you'll need to
|
||||
expose it: `gcloud compute firewall-rules create default-ssh --network=<network-name>
|
||||
--description "SSH allowed from anywhere" --allow tcp:22`
|
||||
|
||||
Additionally, your GCE SSH key must either have no passcode or you need to be
|
||||
using `ssh-agent`.
|
||||
|
||||
### Networking
|
||||
|
||||
The instances must be able to connect to each other using their private IP. The
|
||||
script uses the "default" network which should have a firewall rule called
|
||||
"default-allow-internal" which allows traffic on any port on the private IPs.
|
||||
If this rule is missing from the default network or if you change the network
|
||||
being used in `cluster/config-default.sh` create a new rule with the following
|
||||
field values:
|
||||
|
||||
* Source Ranges: `10.0.0.0/8`
|
||||
* Allowed Protocols and Port: `tcp:1-65535;udp:1-65535;icmp`
|
||||
|
||||
## Support Level
|
||||
|
||||
|
||||
IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level
|
||||
-------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ----------------------------
|
||||
GCE | Saltstack | Debian | GCE | [docs](/docs/setup/production-environment/turnkey/gce/) | | Project
|
||||
|
||||
|
||||
@@ -1,65 +0,0 @@
|
||||
---
|
||||
reviewers:
|
||||
- bradtopol
|
||||
title: Running Kubernetes on Multiple Clouds with IBM Cloud Private
|
||||
---
|
||||
|
||||
IBM® Cloud Private is a turnkey cloud solution and an on-premises turnkey cloud solution. IBM Cloud Private delivers pure upstream Kubernetes with the typical management components that are required to run real enterprise workloads. These workloads include health management, log management, audit trails, and metering for tracking usage of workloads on the platform.
|
||||
|
||||
IBM Cloud Private is available in a community edition and a fully supported enterprise edition. The community edition is available at no charge from [Docker Hub](https://hub.docker.com/r/ibmcom/icp-inception/). The enterprise edition supports high availability topologies and includes commercial support from IBM for Kubernetes and the IBM Cloud Private management platform. If you want to try IBM Cloud Private, you can use either the hosted trial, the tutorial, or the self-guided demo. You can also try the free community edition. For details, see [Get started with IBM Cloud Private](https://www.ibm.com/cloud/private/get-started).
|
||||
|
||||
For more information, explore the following resources:
|
||||
|
||||
* [IBM Cloud Private](https://www.ibm.com/cloud/private)
|
||||
* [Reference architecture for IBM Cloud Private](https://github.com/ibm-cloud-architecture/refarch-privatecloud)
|
||||
* [IBM Cloud Private documentation](https://www.ibm.com/support/knowledgecenter/SSBS6K/product_welcome_cloud_private.html)
|
||||
|
||||
## IBM Cloud Private and Terraform
|
||||
|
||||
The following modules are available where you can deploy IBM Cloud Private by using Terraform:
|
||||
|
||||
* AWS: [Deploy IBM Cloud Private to AWS](https://github.com/ibm-cloud-architecture/terraform-icp-aws)
|
||||
* Azure: [Deploy IBM Cloud Private to Azure](https://github.com/ibm-cloud-architecture/terraform-icp-azure)
|
||||
* IBM Cloud: [Deploy IBM Cloud Private cluster to IBM Cloud](https://github.com/ibm-cloud-architecture/terraform-icp-ibmcloud)
|
||||
* OpenStack: [Deploy IBM Cloud Private to OpenStack](https://github.com/ibm-cloud-architecture/terraform-icp-openstack)
|
||||
* Terraform module: [Deploy IBM Cloud Private on any supported infrastructure vendor](https://github.com/ibm-cloud-architecture/terraform-module-icp-deploy)
|
||||
* VMware: [Deploy IBM Cloud Private to VMware](https://github.com/ibm-cloud-architecture/terraform-icp-vmware)
|
||||
|
||||
## IBM Cloud Private on AWS
|
||||
|
||||
You can deploy an IBM Cloud Private cluster on Amazon Web Services (AWS) using Terraform.
|
||||
|
||||
IBM Cloud Private can also run on the AWS cloud platform by using Terraform. To deploy IBM Cloud Private in an AWS EC2 environment, see [Installing IBM Cloud Private on AWS](https://github.com/ibm-cloud-architecture/terraform-icp-aws).
|
||||
|
||||
## IBM Cloud Private on Azure
|
||||
|
||||
You can enable Microsoft Azure as a cloud provider for IBM Cloud Private deployment and take advantage of all the IBM Cloud Private features on the Azure public cloud. For more information, see [IBM Cloud Private on Azure](https://www.ibm.com/support/knowledgecenter/SSBS6K_3.2.0/supported_environments/azure_overview.html).
|
||||
|
||||
## IBM Cloud Private with Red Hat OpenShift
|
||||
|
||||
You can deploy IBM certified software containers that are running on IBM Cloud Private onto Red Hat OpenShift.
|
||||
|
||||
Integration capabilities:
|
||||
|
||||
* Supports Linux® 64-bit platform in offline-only installation mode
|
||||
* Single-master configuration
|
||||
* Integrated IBM Cloud Private cluster management console and catalog
|
||||
* Integrated core platform services, such as monitoring, metering, and logging
|
||||
* IBM Cloud Private uses the OpenShift image registry
|
||||
|
||||
For more information see, [IBM Cloud Private on OpenShift](https://www.ibm.com/support/knowledgecenter/SSBS6K_3.2.0/supported_environments/openshift/overview.html).
|
||||
|
||||
## IBM Cloud Private on VirtualBox
|
||||
|
||||
To install IBM Cloud Private to a VirtualBox environment, see [Installing IBM Cloud Private on VirtualBox](https://github.com/ibm-cloud-architecture/refarch-privatecloud-virtualbox).
|
||||
|
||||
## IBM Cloud Private on VMware
|
||||
|
||||
You can install IBM Cloud Private on VMware with either Ubuntu or RHEL images. For details, see the following projects:
|
||||
|
||||
* [Installing IBM Cloud Private with Ubuntu](https://github.com/ibm-cloud-architecture/refarch-privatecloud/blob/master/Installing_ICp_on_prem_ubuntu.md)
|
||||
* [Installing IBM Cloud Private with Red Hat Enterprise](https://github.com/ibm-cloud-architecture/refarch-privatecloud/tree/master/icp-on-rhel)
|
||||
|
||||
The IBM Cloud Private Hosted service automatically deploys IBM Cloud Private Hosted on your VMware vCenter Server instances. This service brings the power of microservices and containers to your VMware environment on IBM Cloud. With this service, you can extend the same familiar VMware and IBM Cloud Private operational model and tools from on-premises into the IBM Cloud.
|
||||
|
||||
For more information, see [IBM Cloud Private Hosted service](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-icp_overview).
|
||||
@@ -1,19 +0,0 @@
|
||||
---
|
||||
title: Running Kubernetes on Tencent Kubernetes Engine
|
||||
---
|
||||
|
||||
## Tencent Kubernetes Engine
|
||||
|
||||
[Tencent Cloud Tencent Kubernetes Engine (TKE)](https://intl.cloud.tencent.com/product/tke) provides native Kubernetes container management services. You can deploy and manage a Kubernetes cluster with TKE in just a few steps. For detailed directions, see [Deploy Tencent Kubernetes Engine](https://intl.cloud.tencent.com/document/product/457/11741).
|
||||
|
||||
TKE is a [Certified Kubernetes product](https://www.cncf.io/certification/software-conformance/).It is fully compatible with the native Kubernetes API.
|
||||
|
||||
## Custom Deployment
|
||||
|
||||
The core of Tencent Kubernetes Engine is open source and available [on GitHub](https://github.com/TencentCloud/tencentcloud-cloud-controller-manager/).
|
||||
|
||||
When using TKE to create a Kubernetes cluster, you can choose managed mode or independent deployment mode. In addition, you can customize the deployment as needed; for example, you can choose an existing Cloud Virtual Machine instance for cluster creation or enable Kube-proxy in IPVS mode.
|
||||
|
||||
## What's Next
|
||||
|
||||
To learn more, see the [TKE documentation](https://intl.cloud.tencent.com/document/product/457).
|
||||
+11
-13
@@ -518,27 +518,25 @@ apiVersion: "stable.example.com/v1"
|
||||
kind: CronTab
|
||||
metadata:
|
||||
finalizers:
|
||||
- finalizer.stable.example.com
|
||||
- stable.example.com/finalizer
|
||||
```
|
||||
|
||||
Finalizers are arbitrary string values, that when present ensure that a hard delete
|
||||
of a resource is not possible while they exist.
|
||||
Identifiers of custom finalizers consist of a domain name, a forward slash and the name of
|
||||
the finalizer. Any controller can add a finalizer to any object's list of finalizers.
|
||||
|
||||
The first delete request on an object with finalizers sets a value for the
|
||||
`metadata.deletionTimestamp` field but does not delete it. Once this value is set,
|
||||
entries in the `finalizers` list can only be removed.
|
||||
entries in the `finalizers` list can only be removed. While any finalizers remain it is also
|
||||
impossible to force the deletion of an object.
|
||||
|
||||
When the `metadata.deletionTimestamp` field is set, controllers watching the object
|
||||
execute any finalizers they handle, by polling update requests for that
|
||||
object. When all finalizers have been executed, the resource is deleted.
|
||||
When the `metadata.deletionTimestamp` field is set, controllers watching the object execute any
|
||||
finalizers they handle and remove the finalizer from the list after they are done. It is the
|
||||
responsibility of each controller to remove its finalizer from the list.
|
||||
|
||||
The value of `metadata.deletionGracePeriodSeconds` controls the interval between
|
||||
polling updates.
|
||||
The value of `metadata.deletionGracePeriodSeconds` controls the interval between polling updates.
|
||||
|
||||
It is the responsibility of each controller to remove its finalizer from the list.
|
||||
|
||||
Kubernetes only finally deletes the object if the list of finalizers is empty,
|
||||
meaning all finalizers have been executed.
|
||||
Once the list of finalizers is empty, meaning all finalizers have been executed, the resource is
|
||||
deleted by Kubernetes.
|
||||
|
||||
### Validation
|
||||
|
||||
|
||||
@@ -16,34 +16,32 @@ in a replication controller, deployment, replica set or stateful set based on ob
|
||||
(or, with beta support, on some other, application-provided metrics).
|
||||
|
||||
This document walks you through an example of enabling Horizontal Pod Autoscaler for the php-apache server.
|
||||
For more information on how Horizontal Pod Autoscaler behaves, see the
|
||||
For more information on how Horizontal Pod Autoscaler behaves, see the
|
||||
[Horizontal Pod Autoscaler user guide](/docs/tasks/run-application/horizontal-pod-autoscale/).
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
This example requires a running Kubernetes cluster and kubectl, version 1.2 or later.
|
||||
[metrics-server](https://github.com/kubernetes-sigs/metrics-server) monitoring needs to be deployed in the cluster
|
||||
to provide metrics via the resource metrics API, as Horizontal Pod Autoscaler uses this API to collect metrics. The instructions for deploying this are on the GitHub repository of [metrics-server](https://github.com/kubernetes-sigs/metrics-server), if you followed [getting started on GCE guide](/docs/setup/production-environment/turnkey/gce/),
|
||||
metrics-server monitoring will be turned-on by default.
|
||||
[Metrics server](https://github.com/kubernetes-sigs/metrics-server) monitoring needs to be deployed
|
||||
in the cluster to provide metrics through the [Metrics API](https://github.com/kubernetes/metrics).
|
||||
Horizontal Pod Autoscaler uses this API to collect metrics. To learn how to deploy the metrics-server,
|
||||
see the [metrics-server documentation](https://github.com/kubernetes-sigs/metrics-server#deployment).
|
||||
|
||||
To specify multiple resource metrics for a Horizontal Pod Autoscaler, you must have a Kubernetes cluster
|
||||
and kubectl at version 1.6 or later. Furthermore, in order to make use of custom metrics, your cluster
|
||||
must be able to communicate with the API server providing the custom metrics API. Finally, to use metrics
|
||||
not related to any Kubernetes object you must have a Kubernetes cluster at version 1.10 or later, and
|
||||
you must be able to communicate with the API server that provides the external metrics API.
|
||||
To specify multiple resource metrics for a Horizontal Pod Autoscaler, you must have a
|
||||
Kubernetes cluster and kubectl at version 1.6 or later. To make use of custom metrics, your cluster
|
||||
must be able to communicate with the API server providing the custom Metrics API.
|
||||
Finally, to use metrics not related to any Kubernetes object you must have a
|
||||
Kubernetes cluster at version 1.10 or later, and you must be able to communicate
|
||||
with the API server that provides the external Metrics API.
|
||||
See the [Horizontal Pod Autoscaler user guide](/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) for more details.
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Run & expose php-apache server
|
||||
## Run and expose php-apache server
|
||||
|
||||
To demonstrate Horizontal Pod Autoscaler we will use a custom docker image based on the php-apache image.
|
||||
The Dockerfile has the following content:
|
||||
To demonstrate Horizontal Pod Autoscaler we will use a custom docker image based on the php-apache image. The Dockerfile has the following content:
|
||||
|
||||
```
|
||||
```dockerfile
|
||||
FROM php:5-apache
|
||||
COPY index.php /var/www/html/index.php
|
||||
RUN chmod a+rx index.php
|
||||
@@ -51,7 +49,7 @@ RUN chmod a+rx index.php
|
||||
|
||||
It defines an index.php page which performs some CPU intensive computations:
|
||||
|
||||
```
|
||||
```php
|
||||
<?php
|
||||
$x = 0.0001;
|
||||
for ($i = 0; $i <= 1000000; $i++) {
|
||||
@@ -66,11 +64,12 @@ using the following configuration:
|
||||
|
||||
{{< codenew file="application/php-apache.yaml" >}}
|
||||
|
||||
|
||||
Run the following command:
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/php-apache.yaml
|
||||
```
|
||||
|
||||
```
|
||||
deployment.apps/php-apache created
|
||||
service/php-apache created
|
||||
@@ -90,6 +89,7 @@ See [here](/docs/tasks/run-application/horizontal-pod-autoscale/#algorithm-detai
|
||||
```shell
|
||||
kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10
|
||||
```
|
||||
|
||||
```
|
||||
horizontalpodautoscaler.autoscaling/php-apache autoscaled
|
||||
```
|
||||
@@ -99,10 +99,10 @@ We may check the current status of autoscaler by running:
|
||||
```shell
|
||||
kubectl get hpa
|
||||
```
|
||||
|
||||
```
|
||||
NAME REFERENCE TARGET MINPODS MAXPODS REPLICAS AGE
|
||||
php-apache Deployment/php-apache/scale 0% / 50% 1 10 1 18s
|
||||
|
||||
```
|
||||
|
||||
Please note that the current CPU consumption is 0% as we are not sending any requests to the server
|
||||
@@ -122,10 +122,10 @@ Within a minute or so, we should see the higher CPU load by executing:
|
||||
```shell
|
||||
kubectl get hpa
|
||||
```
|
||||
|
||||
```
|
||||
NAME REFERENCE TARGET MINPODS MAXPODS REPLICAS AGE
|
||||
php-apache Deployment/php-apache/scale 305% / 50% 1 10 1 3m
|
||||
|
||||
```
|
||||
|
||||
Here, CPU consumption has increased to 305% of the request.
|
||||
@@ -134,6 +134,7 @@ As a result, the deployment was resized to 7 replicas:
|
||||
```shell
|
||||
kubectl get deployment php-apache
|
||||
```
|
||||
|
||||
```
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
php-apache 7/7 7 7 19m
|
||||
@@ -157,6 +158,7 @@ Then we will verify the result state (after a minute or so):
|
||||
```shell
|
||||
kubectl get hpa
|
||||
```
|
||||
|
||||
```
|
||||
NAME REFERENCE TARGET MINPODS MAXPODS REPLICAS AGE
|
||||
php-apache Deployment/php-apache/scale 0% / 50% 1 10 1 11m
|
||||
@@ -165,6 +167,7 @@ php-apache Deployment/php-apache/scale 0% / 50% 1 10 1
|
||||
```shell
|
||||
kubectl get deployment php-apache
|
||||
```
|
||||
|
||||
```
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
php-apache 1/1 1 1 27m
|
||||
@@ -176,8 +179,6 @@ Here CPU utilization dropped to 0, and so HPA autoscaled the number of replicas
|
||||
Autoscaling the replicas may take a few minutes.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
|
||||
<!-- discussion -->
|
||||
|
||||
## Autoscaling on multiple metrics and custom metrics
|
||||
@@ -419,7 +420,8 @@ we can use `kubectl describe hpa`:
|
||||
```shell
|
||||
kubectl describe hpa cm-test
|
||||
```
|
||||
```shell
|
||||
|
||||
```
|
||||
Name: cm-test
|
||||
Namespace: prom
|
||||
Labels: <none>
|
||||
@@ -474,8 +476,7 @@ We will create the autoscaler by executing the following command:
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/examples/application/hpa/php-apache.yaml
|
||||
```
|
||||
|
||||
```
|
||||
horizontalpodautoscaler.autoscaling/php-apache created
|
||||
```
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user