Merge remote-tracking branch 'upstream/main' into dev-1.23
This commit is contained in:
Jesse Butler
@@ -214,115 +214,7 @@ In each case, the credentials of the pod are used to communicate securely with t
|
||||
|
||||
## Accessing services running on the cluster
|
||||
|
||||
The previous section was about connecting the Kubernetes API server. This section is about
|
||||
connecting to other services running on Kubernetes cluster. In Kubernetes, the
|
||||
[nodes](/docs/concepts/architecture/nodes/),
|
||||
[pods](/docs/concepts/workloads/pods/) and
|
||||
[services](/docs/concepts/services-networking/service/) all have
|
||||
their own IPs. In many cases, the node IPs, pod IPs, and some service IPs on a cluster will not be
|
||||
routable, so they will not be reachable from a machine outside the cluster,
|
||||
such as your desktop machine.
|
||||
|
||||
### Ways to connect
|
||||
|
||||
You have several options for connecting to nodes, pods and services from outside the cluster:
|
||||
|
||||
- Access services through public IPs.
|
||||
- Use a service with type `NodePort` or `LoadBalancer` to make the service reachable outside
|
||||
the cluster. See the [services](/docs/concepts/services-networking/service/) and
|
||||
[kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) documentation.
|
||||
- Depending on your cluster environment, this may only expose the service to your corporate network,
|
||||
or it may expose it to the internet. Think about whether the service being exposed is secure.
|
||||
Does it do its own authentication?
|
||||
- Place pods behind services. To access one specific pod from a set of replicas, such as for debugging,
|
||||
place a unique label on the pod and create a new service which selects this label.
|
||||
- In most cases, it should not be necessary for application developer to directly access
|
||||
nodes via their nodeIPs.
|
||||
- Access services, nodes, or pods using the Proxy Verb.
|
||||
- Does apiserver authentication and authorization prior to accessing the remote service.
|
||||
Use this if the services are not secure enough to expose to the internet, or to gain
|
||||
access to ports on the node IP, or for debugging.
|
||||
- Proxies may cause problems for some web applications.
|
||||
- Only works for HTTP/HTTPS.
|
||||
- Described [here](#manually-constructing-apiserver-proxy-urls).
|
||||
- Access from a node or pod in the cluster.
|
||||
- Run a pod, and then connect to a shell in it using [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec).
|
||||
Connect to other nodes, pods, and services from that shell.
|
||||
- Some clusters may allow you to ssh to a node in the cluster. From there you may be able to
|
||||
access cluster services. This is a non-standard method, and will work on some clusters but
|
||||
not others. Browsers and other tools may or may not be installed. Cluster DNS may not work.
|
||||
|
||||
### Discovering builtin services
|
||||
|
||||
Typically, there are several services which are started on a cluster by kube-system. Get a list of these
|
||||
with the `kubectl cluster-info` command:
|
||||
|
||||
```shell
|
||||
kubectl cluster-info
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```
|
||||
Kubernetes master is running at https://104.197.5.247
|
||||
elasticsearch-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy
|
||||
kibana-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kibana-logging/proxy
|
||||
kube-dns is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kube-dns/proxy
|
||||
grafana is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy
|
||||
heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy
|
||||
```
|
||||
|
||||
This shows the proxy-verb URL for accessing each service.
|
||||
For example, this cluster has cluster-level logging enabled (using Elasticsearch), which can be reached
|
||||
at `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/` if suitable credentials are passed. Logging can also be reached through a kubectl proxy, for example at:
|
||||
`http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`.
|
||||
(See [Access Clusters Using the Kubernetes API](/docs/tasks/administer-cluster/access-cluster-api/) for how to pass credentials or use kubectl proxy.)
|
||||
|
||||
#### Manually constructing apiserver proxy URLs
|
||||
|
||||
As mentioned above, you use the `kubectl cluster-info` command to retrieve the service's proxy URL. To create proxy URLs that include service endpoints, suffixes, and parameters, you append to the service's proxy URL:
|
||||
`http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`service_name[:port_name]`*`/proxy`
|
||||
|
||||
If you haven't specified a name for your port, you don't have to specify *port_name* in the URL. You can also use the port number in place of the *port_name* for both named and unnamed ports.
|
||||
|
||||
By default, the API server proxies to your service using http. To use https, prefix the service name with `https:`:
|
||||
`http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`https:service_name:[port_name]`*`/proxy`
|
||||
|
||||
The supported formats for the name segment of the URL are:
|
||||
|
||||
* `<service_name>` - proxies to the default or unnamed port using http
|
||||
* `<service_name>:<port_name>` - proxies to the specified port name or port number using http
|
||||
* `https:<service_name>:` - proxies to the default or unnamed port using https (note the trailing colon)
|
||||
* `https:<service_name>:<port_name>` - proxies to the specified port name or port number using https
|
||||
|
||||
##### Examples
|
||||
|
||||
* To access the Elasticsearch service endpoint `_search?q=user:kimchy`, you would use: `http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy`
|
||||
* To access the Elasticsearch cluster health information `_cluster/health?pretty=true`, you would use: `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true`
|
||||
|
||||
```json
|
||||
{
|
||||
"cluster_name" : "kubernetes_logging",
|
||||
"status" : "yellow",
|
||||
"timed_out" : false,
|
||||
"number_of_nodes" : 1,
|
||||
"number_of_data_nodes" : 1,
|
||||
"active_primary_shards" : 5,
|
||||
"active_shards" : 5,
|
||||
"relocating_shards" : 0,
|
||||
"initializing_shards" : 0,
|
||||
"unassigned_shards" : 5
|
||||
}
|
||||
```
|
||||
|
||||
### Using web browsers to access services running on the cluster
|
||||
|
||||
You may be able to put an apiserver proxy url into the address bar of a browser. However:
|
||||
|
||||
- Web browsers cannot usually pass tokens, so you may need to use basic (password) auth. Apiserver can be configured to accept basic auth,
|
||||
but your cluster may not be configured to accept basic auth.
|
||||
- Some web apps may not work, particularly those with client side javascript that construct urls in a
|
||||
way that is unaware of the proxy path prefix.
|
||||
The previous section describes how to connect to the Kubernetes API server. For information about connecting to other services running on a Kubernetes cluster, see [Access Cluster Services.](/docs/tasks/access-application-cluster/access-cluster/)
|
||||
|
||||
## Requesting redirects
|
||||
|
||||
|
||||
+2
-2
@@ -70,7 +70,7 @@ The formatting can be controlled further by using the `range` operation to
|
||||
iterate over elements individually.
|
||||
|
||||
```shell
|
||||
kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\
|
||||
kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\
|
||||
sort
|
||||
```
|
||||
|
||||
@@ -80,7 +80,7 @@ To target only Pods matching a specific label, use the -l flag. The
|
||||
following matches only Pods with labels matching `app=nginx`.
|
||||
|
||||
```shell
|
||||
kubectl get pods --all-namespaces -o=jsonpath="{.items[*].spec.containers[*].image}" -l app=nginx
|
||||
kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" -l app=nginx
|
||||
```
|
||||
|
||||
## List Container images filtering by Pod namespace
|
||||
|
||||
@@ -86,7 +86,18 @@ See [Access Clusters Using the Kubernetes API](/docs/tasks/administer-cluster/ac
|
||||
As mentioned above, you use the `kubectl cluster-info` command to retrieve the service's proxy URL. To create proxy URLs that include service endpoints, suffixes, and parameters, you append to the service's proxy URL:
|
||||
`http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`[https:]service_name[:port_name]`*`/proxy`
|
||||
|
||||
If you haven't specified a name for your port, you don't have to specify *port_name* in the URL.
|
||||
If you haven't specified a name for your port, you don't have to specify *port_name* in the URL. You can also use the port number in place of the *port_name* for both named and unnamed ports.
|
||||
|
||||
By default, the API server proxies to your service using HTTP. To use HTTPS, prefix the service name with `https:`:
|
||||
`http://<kubernetes_master_address>/api/v1/namespaces/<namespace_name>/services/<service_name>/proxy`
|
||||
|
||||
The supported formats for the `<service_name>` segment of the URL are:
|
||||
|
||||
* `<service_name>` - proxies to the default or unnamed port using http
|
||||
* `<service_name>:<port_name>` - proxies to the specified port name or port number using http
|
||||
* `https:<service_name>:` - proxies to the default or unnamed port using https (note the trailing colon)
|
||||
* `https:<service_name>:<port_name>` - proxies to the specified port name or port number using https
|
||||
|
||||
|
||||
##### Examples
|
||||
|
||||
|
||||
@@ -78,10 +78,6 @@ Pick a control plane node that you wish to upgrade first. It must have the `/etc
|
||||
apt-mark unhold kubeadm && \
|
||||
apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 && \
|
||||
apt-mark hold kubeadm
|
||||
-
|
||||
# since apt-get version 1.1 you can also use the following method
|
||||
apt-get update && \
|
||||
apt-get install -y --allow-change-held-packages kubeadm={{< skew currentVersion >}}.x-00
|
||||
{{% /tab %}}
|
||||
{{% tab name="CentOS, RHEL or Fedora" %}}
|
||||
# replace x in {{< skew currentVersion >}}.x-0 with the latest patch version
|
||||
@@ -175,10 +171,6 @@ Also calling `kubeadm upgrade plan` and upgrading the CNI provider plugin is no
|
||||
apt-mark unhold kubelet kubectl && \
|
||||
apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \
|
||||
apt-mark hold kubelet kubectl
|
||||
-
|
||||
# since apt-get version 1.1 you can also use the following method
|
||||
apt-get update && \
|
||||
apt-get install -y --allow-change-held-packages kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00
|
||||
{{% /tab %}}
|
||||
{{% tab name="CentOS, RHEL or Fedora" %}}
|
||||
# replace x in {{< skew currentVersion >}}.x-0 with the latest patch version
|
||||
@@ -218,10 +210,6 @@ without compromising the minimum required capacity for running your workloads.
|
||||
apt-mark unhold kubeadm && \
|
||||
apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 && \
|
||||
apt-mark hold kubeadm
|
||||
-
|
||||
# since apt-get version 1.1 you can also use the following method
|
||||
apt-get update && \
|
||||
apt-get install -y --allow-change-held-packages kubeadm={{< skew currentVersion >}}.x-00
|
||||
{{% /tab %}}
|
||||
{{% tab name="CentOS, RHEL or Fedora" %}}
|
||||
# replace x in {{< skew currentVersion >}}.x-0 with the latest patch version
|
||||
@@ -256,10 +244,6 @@ without compromising the minimum required capacity for running your workloads.
|
||||
apt-mark unhold kubelet kubectl && \
|
||||
apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \
|
||||
apt-mark hold kubelet kubectl
|
||||
-
|
||||
# since apt-get version 1.1 you can also use the following method
|
||||
apt-get update && \
|
||||
apt-get install -y --allow-change-held-packages kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00
|
||||
{{% /tab %}}
|
||||
{{% tab name="CentOS, RHEL or Fedora" %}}
|
||||
# replace x in {{< skew currentVersion >}}.x-0 with the latest patch version
|
||||
|
||||
@@ -91,4 +91,13 @@ If you are using the sample manifest from the previous point, this will require
|
||||
Once enabled, node-local-dns Pods will run in the kube-system namespace on each of the cluster nodes. This Pod runs [CoreDNS](https://github.com/coredns/coredns) in cache mode, so all CoreDNS metrics exposed by the different plugins will be available on a per-node basis.
|
||||
|
||||
You can disable this feature by removing the DaemonSet, using `kubectl delete -f <manifest>` . You should also revert any changes you made to the kubelet configuration.
|
||||
|
||||
## StubDomains and Upstream server Configuration
|
||||
|
||||
StubDomains and upstream servers specified in the `kube-dns` ConfigMap in the `kube-system` namespace
|
||||
are automatically picked up by `node-local-dns` pods. The ConfigMap contents need to follow the format
|
||||
shown in [the example](/docs/tasks/administer-cluster/dns-custom-nameservers/#example-1).
|
||||
The `node-local-dns` ConfigMap can also be modified directly with the stubDomain configuration
|
||||
in the Corefile format. Some cloud providers might not allow modifying `node-local-dns` ConfigMap directly.
|
||||
In those cases, the `kube-dns` ConfigMap can be updated.
|
||||
|
||||
|
||||
@@ -11,7 +11,7 @@ min-kubernetes-server-version: v1.11
|
||||
{{< feature-state for_k8s_version="v1.22" state="deprecated" >}}
|
||||
|
||||
{{< caution >}}
|
||||
[Dynamic Kubelet Configuration](https://github.com/kubernetes/enhancements/issues/281)
|
||||
The [Dynamic Kubelet Configuration](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/281-dynamic-kubelet-configuration)
|
||||
feature is deprecated and should not be used.
|
||||
Please switch to alternative means distributing configuration to the Nodes of your cluster.
|
||||
{{< /caution >}}
|
||||
@@ -37,13 +37,10 @@ fields is available in the inline
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
You need to have a Kubernetes cluster.
|
||||
You also need kubectl v1.11 or higher, configured to communicate with your cluster.
|
||||
You also need `kubectl`, [installed](/docs/tasks/tools/#kubectl) and configured to communicate with your cluster.
|
||||
Make sure that you are using a version of `kubectl` that is
|
||||
[compatible](/releases/version-skew-policy/) with your cluster.
|
||||
{{< version-check >}}
|
||||
Your cluster API server version (eg v1.12) must be no more than one minor
|
||||
version away from the version of kubectl that you are using. For example,
|
||||
if your cluster is running v1.16 then you can use kubectl v1.15, v1.16
|
||||
or v1.17; other combinations
|
||||
[aren't supported](/docs/setup/release/version-skew-policy/#kubectl).
|
||||
|
||||
Some of the examples use the command line tool
|
||||
[jq](https://stedolan.github.io/jq/). You do not need `jq` to complete the task,
|
||||
@@ -383,9 +380,10 @@ internal failure, see Kubelet log for details | The kubelet encountered some int
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
- For more information on configuring the kubelet via a configuration file, see
|
||||
[Set kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file).
|
||||
- See the reference documentation for [`NodeConfigSource`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#nodeconfigsource-v1-core)
|
||||
- [Set kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file)
|
||||
explains the supported way to configure a kubelet.
|
||||
- See the reference documentation for Node, including the `configSource` field within
|
||||
the Node's [.spec](/docs/reference/kubernetes-api/cluster-resources/node-v1/#NodeSpec)
|
||||
- Learn more about kubelet configuration by checking the
|
||||
[`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/)
|
||||
reference.
|
||||
|
||||
@@ -71,6 +71,7 @@ The following sysctls are supported in the _safe_ set:
|
||||
- `net.ipv4.ip_local_port_range`,
|
||||
- `net.ipv4.tcp_syncookies`,
|
||||
- `net.ipv4.ping_group_range` (since Kubernetes 1.18).
|
||||
- `net.ipv4.ip_unprivileged_port_start` (since Kubernetes 1.22).
|
||||
|
||||
{{< note >}}
|
||||
The example `net.ipv4.tcp_syncookies` is not namespaced on Linux kernel version 4.4 or lower.
|
||||
|
||||
@@ -236,8 +236,14 @@ sudo rmdir /mnt/data
|
||||
|
||||
You can now close the shell to your Node.
|
||||
|
||||
## Mounting the same persistentVolume in two places
|
||||
|
||||
{{< codenew file="pods/storage/pv-duplicate.yaml" >}}
|
||||
|
||||
You can perform 2 volume mounts on your nginx container:
|
||||
|
||||
`/usr/share/nginx/html` for the static website
|
||||
`/etc/nginx/nginx.conf` for the default config
|
||||
|
||||
<!-- discussion -->
|
||||
|
||||
|
||||
@@ -73,6 +73,7 @@ isolation other than resource constraints imposed on the HostProcess user accoun
|
||||
filesystem or Hyper-V isolation are supported for HostProcess containers.
|
||||
- Volume mounts are supported and are mounted under the container volume. See [Volume Mounts](#volume-mounts)
|
||||
- As of 1.23, a limited set of host user accounts are available for HostProcess containers by default.
|
||||
- A limited set of host user accounts are available for HostProcess containers by default.
|
||||
See [Choosing a User Account](#choosing-a-user-account).
|
||||
- Resource limits (disk, memory, cpu count) are supported in the same fashion as processes
|
||||
on the host.
|
||||
|
||||
@@ -29,13 +29,13 @@ Kompose is released via GitHub on a three-week cycle, you can see all current re
|
||||
|
||||
```sh
|
||||
# Linux
|
||||
curl -L https://github.com/kubernetes/kompose/releases/download/v1.24.0/kompose-linux-amd64 -o kompose
|
||||
curl -L https://github.com/kubernetes/kompose/releases/download/v1.26.0/kompose-linux-amd64 -o kompose
|
||||
|
||||
# macOS
|
||||
curl -L https://github.com/kubernetes/kompose/releases/download/v1.24.0/kompose-darwin-amd64 -o kompose
|
||||
curl -L https://github.com/kubernetes/kompose/releases/download/v1.26.0/kompose-darwin-amd64 -o kompose
|
||||
|
||||
# Windows
|
||||
curl -L https://github.com/kubernetes/kompose/releases/download/v1.24.0/kompose-windows-amd64.exe -o kompose.exe
|
||||
curl -L https://github.com/kubernetes/kompose/releases/download/v1.26.0/kompose-windows-amd64.exe -o kompose.exe
|
||||
|
||||
chmod +x kompose
|
||||
sudo mv ./kompose /usr/local/bin/kompose
|
||||
@@ -207,8 +207,6 @@ you need is an existing `docker-compose.yml` file.
|
||||
|
||||
- CLI
|
||||
- [`kompose convert`](#kompose-convert)
|
||||
- [`kompose up`](#kompose-up)
|
||||
- [`kompose down`](#kompose-down)
|
||||
- Documentation
|
||||
- [Build and Push Docker Images](#build-and-push-docker-images)
|
||||
- [Alternative Conversions](#alternative-conversions)
|
||||
@@ -328,121 +326,7 @@ INFO OpenShift file "foo-buildconfig.yaml" created
|
||||
If you are manually pushing the OpenShift artifacts using ``oc create -f``, you need to ensure that you push the imagestream artifact before the buildconfig artifact, to workaround this OpenShift issue: https://github.com/openshift/origin/issues/4518 .
|
||||
{{< /note >}}
|
||||
|
||||
## `kompose up`
|
||||
|
||||
Kompose supports a straightforward way to deploy your "composed" application to Kubernetes or OpenShift via `kompose up`.
|
||||
|
||||
### Kubernetes `kompose up` example
|
||||
|
||||
```shell
|
||||
kompose --file ./examples/docker-guestbook.yml up
|
||||
```
|
||||
|
||||
```none
|
||||
We are going to create Kubernetes deployments and services for your Dockerized application.
|
||||
If you need different kind of resources, use the 'kompose convert' and 'kubectl apply -f' commands instead.
|
||||
|
||||
INFO Successfully created service: redis-master
|
||||
INFO Successfully created service: redis-slave
|
||||
INFO Successfully created service: frontend
|
||||
INFO Successfully created deployment: redis-master
|
||||
INFO Successfully created deployment: redis-slave
|
||||
INFO Successfully created deployment: frontend
|
||||
|
||||
Your application has been deployed to Kubernetes. You can run 'kubectl get deployment,svc,pods' for details.
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl get deployment,svc,pods
|
||||
```
|
||||
|
||||
```none
|
||||
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
|
||||
deployment.extensions/frontend 1 1 1 1 4m
|
||||
deployment.extensions/redis-master 1 1 1 1 4m
|
||||
deployment.extensions/redis-slave 1 1 1 1 4m
|
||||
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
service/frontend ClusterIP 10.0.174.12 <none> 80/TCP 4m
|
||||
service/kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 13d
|
||||
service/redis-master ClusterIP 10.0.202.43 <none> 6379/TCP 4m
|
||||
service/redis-slave ClusterIP 10.0.1.85 <none> 6379/TCP 4m
|
||||
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
pod/frontend-2768218532-cs5t5 1/1 Running 0 4m
|
||||
pod/redis-master-1432129712-63jn8 1/1 Running 0 4m
|
||||
pod/redis-slave-2504961300-nve7b 1/1 Running 0 4m
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
|
||||
- You must have a running Kubernetes cluster with a pre-configured kubectl context.
|
||||
- Only deployments and services are generated and deployed to Kubernetes. If you need different kind of resources, use the `kompose convert` and `kubectl apply -f` commands instead.
|
||||
{{< /note >}}
|
||||
|
||||
### OpenShift `kompose up` example
|
||||
|
||||
```shell
|
||||
kompose --file ./examples/docker-guestbook.yml --provider openshift up
|
||||
```
|
||||
|
||||
```none
|
||||
We are going to create OpenShift DeploymentConfigs and Services for your Dockerized application.
|
||||
If you need different kind of resources, use the 'kompose convert' and 'oc create -f' commands instead.
|
||||
|
||||
INFO Successfully created service: redis-slave
|
||||
INFO Successfully created service: frontend
|
||||
INFO Successfully created service: redis-master
|
||||
INFO Successfully created deployment: redis-slave
|
||||
INFO Successfully created ImageStream: redis-slave
|
||||
INFO Successfully created deployment: frontend
|
||||
INFO Successfully created ImageStream: frontend
|
||||
INFO Successfully created deployment: redis-master
|
||||
INFO Successfully created ImageStream: redis-master
|
||||
|
||||
Your application has been deployed to OpenShift. You can run 'oc get dc,svc,is' for details.
|
||||
```
|
||||
|
||||
```shell
|
||||
oc get dc,svc,is
|
||||
```
|
||||
|
||||
```none
|
||||
NAME REVISION DESIRED CURRENT TRIGGERED BY
|
||||
dc/frontend 0 1 0 config,image(frontend:v4)
|
||||
dc/redis-master 0 1 0 config,image(redis-master:e2e)
|
||||
dc/redis-slave 0 1 0 config,image(redis-slave:v1)
|
||||
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
svc/frontend 172.30.46.64 <none> 80/TCP 8s
|
||||
svc/redis-master 172.30.144.56 <none> 6379/TCP 8s
|
||||
svc/redis-slave 172.30.75.245 <none> 6379/TCP 8s
|
||||
NAME DOCKER REPO TAGS UPDATED
|
||||
is/frontend 172.30.12.200:5000/fff/frontend
|
||||
is/redis-master 172.30.12.200:5000/fff/redis-master
|
||||
is/redis-slave 172.30.12.200:5000/fff/redis-slave v1
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
You must have a running OpenShift cluster with a pre-configured `oc` context (`oc login`).
|
||||
{{< /note >}}
|
||||
|
||||
## `kompose down`
|
||||
|
||||
Once you have deployed "composed" application to Kubernetes, `kompose down` will help you to take the application out by deleting its deployments and services. If you need to remove other resources, use the 'kubectl' command.
|
||||
|
||||
```shell
|
||||
kompose --file docker-guestbook.yml down
|
||||
INFO Successfully deleted service: redis-master
|
||||
INFO Successfully deleted deployment: redis-master
|
||||
INFO Successfully deleted service: redis-slave
|
||||
INFO Successfully deleted deployment: redis-slave
|
||||
INFO Successfully deleted service: frontend
|
||||
INFO Successfully deleted deployment: frontend
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
You must have a running Kubernetes cluster with a pre-configured `kubectl` context.
|
||||
{{< /note >}}
|
||||
|
||||
## Build and Push Docker Images
|
||||
|
||||
|
||||
+13
-3
@@ -1038,8 +1038,8 @@ procedure.
|
||||
|
||||
*Option 1:* Use the Storage Version Migrator
|
||||
|
||||
1. Run the [storage Version migrator](https://github.com/kubernetes-sigs/kube-storage-version-migrator)
|
||||
2. Remove the old version from the CustomResourceDefinition `status.storedVersions` field.
|
||||
1. Run the [storage Version migrator](https://github.com/kubernetes-sigs/kube-storage-version-migrator)
|
||||
2. Remove the old version from the CustomResourceDefinition `status.storedVersions` field.
|
||||
|
||||
*Option 2:* Manually upgrade the existing objects to a new stored version
|
||||
|
||||
@@ -1050,6 +1050,16 @@ The following is an example procedure to upgrade from `v1beta1` to `v1`.
|
||||
2. Write an upgrade procedure to list all existing objects and write them with
|
||||
the same content. This forces the backend to write objects in the current
|
||||
storage version, which is `v1`.
|
||||
2. Remove `v1beta1` from the CustomResourceDefinition `status.storedVersions` field.
|
||||
3. Remove `v1beta1` from the CustomResourceDefinition `status.storedVersions` field.
|
||||
|
||||
{{< note >}}
|
||||
The `kubectl` tool currently cannot be used to edit or patch the `status` subresource on a CRD: see the [Kubectl Subresource Support KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-cli/2590-kubectl-subresource) for more details.
|
||||
|
||||
The easier way to patch the status subresource from the CLI is directly interacting with the API server using the `curl` tool, in this example:
|
||||
```bash
|
||||
kubectl proxy &
|
||||
curl --header "Content-Type: application/json-patch+json" \
|
||||
--request PATCH http://localhost:8001/apis/apiextensions.k8s.io/v1/customresourcedefinitions/<your CRD name here>/status \
|
||||
--data '[{"op": "replace", "path": "/status/storedVersions", "value":["v1"]}]'
|
||||
```
|
||||
{{< /note >}}
|
||||
|
||||
@@ -178,13 +178,13 @@ First, copy and paste the following template of a Job object, into a file called
|
||||
|
||||
|
||||
```liquid
|
||||
{%- set params = [{ "name": "apple", "url": "http://dbpedia.org/resource/Apple", },
|
||||
{% set params = [{ "name": "apple", "url": "http://dbpedia.org/resource/Apple", },
|
||||
{ "name": "banana", "url": "http://dbpedia.org/resource/Banana", },
|
||||
{ "name": "cherry", "url": "http://dbpedia.org/resource/Cherry" }]
|
||||
%}
|
||||
{%- for p in params %}
|
||||
{%- set name = p["name"] %}
|
||||
{%- set url = p["url"] %}
|
||||
{% for p in params %}
|
||||
{% set name = p["name"] %}
|
||||
{% set url = p["url"] %}
|
||||
---
|
||||
apiVersion: batch/v1
|
||||
kind: Job
|
||||
@@ -204,7 +204,7 @@ spec:
|
||||
image: busybox
|
||||
command: ["sh", "-c", "echo Processing URL {{ url }} && sleep 5"]
|
||||
restartPolicy: Never
|
||||
{%- endfor %}
|
||||
{% endfor %}
|
||||
```
|
||||
|
||||
The above template defines two parameters for each Job object using a list of
|
||||
|
||||
@@ -525,6 +525,45 @@ stops adjusting the target (and sets the `ScalingActive` Condition on itself
|
||||
to `false`) until you reactivate it by manually adjusting the target's desired
|
||||
replica count or HPA's minimum replica count.
|
||||
|
||||
### Migrating Deployments and StatefulSets to horizontal autoscaling
|
||||
|
||||
When an HPA is enabled, it is recommended that the value of `spec.replicas` of
|
||||
the Deployment and / or StatefulSet be removed from their
|
||||
{{< glossary_tooltip text="manifest(s)" term_id="manifest" >}}. If this isn't done, any time
|
||||
a change to that object is applied, for example via `kubectl apply -f
|
||||
deployment.yaml`, this will instruct Kubernetes to scale the current number of Pods
|
||||
to the value of the `spec.replicas` key. This may not be
|
||||
desired and could be troublesome when an HPA is active.
|
||||
|
||||
Keep in mind that the removal of `spec.replicas` may incur a one-time
|
||||
degradation of Pod counts as the default value of this key is 1 (reference
|
||||
[Deployment Replicas](/docs/concepts/workloads/controllers/deployment#replicas).
|
||||
Upon the update, all Pods except 1 will begin their termination procedures. Any
|
||||
deployment application afterwards will behave as normal and respect a rolling
|
||||
update configuration as desired. You can avoid this degradation by choosing one of the following two
|
||||
methods based on how you are modifying your deployments:
|
||||
|
||||
{{< tabs name="fix_replicas_instructions" >}}
|
||||
{{% tab name="Client Side Apply (this is the default)" %}}
|
||||
|
||||
1. `kubectl apply edit-last-applied deployment/<deployment_name>`
|
||||
2. In the editor, remove `spec.replicas`. When you save and exit the editor, `kubectl`
|
||||
applies the update. No changes to Pod counts happen at this step.
|
||||
3. You can now remove `spec.replicas` from the manifest. If you use source code management,
|
||||
also commit your changes or take whatever other steps for revising the source code
|
||||
are appropriate for how you track updates.
|
||||
4. From here on out you can run `kubectl apply -f deployment.yaml`
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="Server Side Apply" %}}
|
||||
|
||||
When using the [Server-Side Apply](/docs/reference/using-api/server-side-apply/)
|
||||
you can follow the [transferring ownership](/docs/reference/using-api/server-side-apply/#transferring-ownership)
|
||||
guidelines, which cover this exact use case.
|
||||
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
If you configure autoscaling in your cluster, you may also want to consider running a
|
||||
|
||||
Reference in New Issue
Block a user