Merge pull request #23017 from tengqm/links-tasks-2
Tune links in tasks section (2/2)
This commit is contained in:
Kubernetes Prow Robot
@@ -8,9 +8,6 @@ content_type: concept
|
||||
|
||||
This topic discusses multiple ways to interact with clusters.
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Accessing for the first time with kubectl
|
||||
@@ -29,8 +26,9 @@ Check the location and credentials that kubectl knows about with this command:
|
||||
kubectl config view
|
||||
```
|
||||
|
||||
Many of the [examples](/docs/user-guide/kubectl-cheatsheet) provide an introduction to using
|
||||
kubectl and complete documentation is found in the [kubectl manual](/docs/user-guide/kubectl-overview).
|
||||
Many of the [examples](/docs/reference/kubectl/cheatsheet/) provide an introduction to using
|
||||
kubectl and complete documentation is found in the
|
||||
[kubectl manual](/docs/reference/kubectl/overview/).
|
||||
|
||||
## Directly accessing the REST API
|
||||
|
||||
@@ -165,7 +163,7 @@ client libraries.
|
||||
* To get the library, run the following command: `go get k8s.io/client-go@kubernetes-<kubernetes-version-number>`, see [INSTALL.md](https://github.com/kubernetes/client-go/blob/master/INSTALL.md#for-the-casual-user) for detailed installation instructions. See [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go#compatibility-matrix) to see which versions are supported.
|
||||
* Write an application atop of the client-go clients. Note that client-go defines its own API objects, so if needed, please import API definitions from client-go rather than from the main repository, e.g., `import "k8s.io/client-go/kubernetes"` is correct.
|
||||
|
||||
The Go client can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)
|
||||
The Go client can use the same [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
|
||||
as the kubectl CLI does to locate and authenticate to the apiserver. See this [example](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go).
|
||||
|
||||
If the application is deployed as a Pod in the cluster, please refer to the [next section](#accessing-the-api-from-a-pod).
|
||||
@@ -174,7 +172,7 @@ If the application is deployed as a Pod in the cluster, please refer to the [nex
|
||||
|
||||
To use [Python client](https://github.com/kubernetes-client/python), run the following command: `pip install kubernetes`. See [Python Client Library page](https://github.com/kubernetes-client/python) for more installation options.
|
||||
|
||||
The Python client can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)
|
||||
The Python client can use the same [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
|
||||
as the kubectl CLI does to locate and authenticate to the apiserver. See this [example](https://github.com/kubernetes-client/python/tree/master/examples).
|
||||
|
||||
### Other languages
|
||||
@@ -219,7 +217,9 @@ In each case, the credentials of the pod are used to communicate securely with t
|
||||
|
||||
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/admin/node), [pods](/docs/user-guide/pods) and [services](/docs/user-guide/services) all have
|
||||
[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.
|
||||
@@ -230,7 +230,7 @@ You have several options for connecting to nodes, pods and services from outside
|
||||
|
||||
- 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/user-guide/services) and
|
||||
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 just expose the service to your corporate network,
|
||||
or it may expose it to the internet. Think about whether the service being exposed is secure.
|
||||
|
||||
+12
-26
@@ -7,19 +7,14 @@ weight: 110
|
||||
<!-- overview -->
|
||||
|
||||
This page shows how to use a Volume to communicate between two Containers running
|
||||
in the same Pod. See also how to allow processes to communicate by [sharing process namespace](/docs/tasks/configure-pod-container/share-process-namespace/) between containers.
|
||||
|
||||
|
||||
|
||||
in the same Pod. See also how to allow processes to communicate by
|
||||
[sharing process namespace](/docs/tasks/configure-pod-container/share-process-namespace/)
|
||||
between containers.
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Creating a Pod that runs two Containers
|
||||
@@ -103,14 +98,15 @@ The output is similar to this:
|
||||
Recall that the debian Container created the `index.html` file in the nginx root
|
||||
directory. Use `curl` to send a GET request to the nginx server:
|
||||
|
||||
root@two-containers:/# curl localhost
|
||||
```
|
||||
root@two-containers:/# curl localhost
|
||||
```
|
||||
|
||||
The output shows that nginx serves a web page written by the debian container:
|
||||
|
||||
Hello from the debian container
|
||||
|
||||
|
||||
|
||||
```
|
||||
Hello from the debian container
|
||||
```
|
||||
|
||||
<!-- discussion -->
|
||||
|
||||
@@ -128,20 +124,14 @@ The Volume in this exercise provides a way for Containers to communicate during
|
||||
the life of the Pod. If the Pod is deleted and recreated, any data stored in
|
||||
the shared Volume is lost.
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* Learn more about
|
||||
[patterns for composite containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns).
|
||||
* Learn more about [patterns for composite containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns).
|
||||
|
||||
* Learn about
|
||||
[composite containers for modular architecture](http://www.slideshare.net/Docker/slideshare-burns).
|
||||
* Learn about [composite containers for modular architecture](https://www.slideshare.net/Docker/slideshare-burns).
|
||||
|
||||
* See
|
||||
[Configuring a Pod to Use a Volume for Storage](/docs/tasks/configure-pod-container/configure-volume-storage/).
|
||||
* See [Configuring a Pod to Use a Volume for Storage](/docs/tasks/configure-pod-container/configure-volume-storage/).
|
||||
|
||||
* See [Configure a Pod to share process namespace between containers in a Pod](/docs/tasks/configure-pod-container/share-process-namespace/)
|
||||
|
||||
@@ -149,7 +139,3 @@ the shared Volume is lost.
|
||||
|
||||
* See [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -11,33 +11,21 @@ microservice. The backend microservice is a hello greeter. The
|
||||
frontend and backend are connected using a Kubernetes
|
||||
{{< glossary_tooltip term_id="service" >}} object.
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "objectives" %}}
|
||||
|
||||
|
||||
* Create and run a microservice using a {{< glossary_tooltip term_id="deployment" >}} object.
|
||||
* Route traffic to the backend using a frontend.
|
||||
* Use a Service object to connect the frontend application to the
|
||||
backend application.
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
* This task uses
|
||||
[Services with external load balancers](/docs/tasks/access-application-cluster/create-external-load-balancer/), which
|
||||
require a supported environment. If your environment does not
|
||||
support this, you can use a Service of type
|
||||
[NodePort](/docs/concepts/services-networking/service/#nodeport) instead.
|
||||
|
||||
|
||||
|
||||
This task uses
|
||||
[Services with external load balancers](/docs/tasks/access-application-cluster/create-external-load-balancer/), which
|
||||
require a supported environment. If your environment does not support this, you can use a Service of type
|
||||
[NodePort](/docs/concepts/services-networking/service/#nodeport) instead.
|
||||
|
||||
<!-- lessoncontent -->
|
||||
|
||||
@@ -153,8 +141,8 @@ service/frontend created
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
The nginx configuration is baked into the [container
|
||||
image](/examples/service/access/Dockerfile). A better way to do this would
|
||||
The nginx configuration is baked into the
|
||||
[container image](/examples/service/access/Dockerfile). A better way to do this would
|
||||
be to use a
|
||||
[ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/),
|
||||
so that you can change the configuration more easily.
|
||||
@@ -203,27 +191,22 @@ The output shows the message generated by the backend:
|
||||
{"message":"Hello"}
|
||||
```
|
||||
|
||||
|
||||
|
||||
## {{% heading "cleanup" %}}
|
||||
|
||||
|
||||
To delete the Services, enter this command:
|
||||
|
||||
kubectl delete services frontend hello
|
||||
```shell
|
||||
kubectl delete services frontend hello
|
||||
```
|
||||
|
||||
To delete the Deployments, the ReplicaSets and the Pods that are running the backend and frontend applications, enter this command:
|
||||
|
||||
kubectl delete deployment frontend hello
|
||||
|
||||
|
||||
```shell
|
||||
kubectl delete deployment frontend hello
|
||||
```
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* Learn more about [Services](/docs/concepts/services-networking/service/)
|
||||
* Learn more about [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
+8
-26
@@ -9,15 +9,10 @@ weight: 100
|
||||
This page shows how to use kubectl to list all of the Container images
|
||||
for Pods running in a cluster.
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
In this exercise you will use kubectl to fetch all of the Pods
|
||||
@@ -30,14 +25,14 @@ of Containers for each.
|
||||
- Format the output to include only the list of Container image names
|
||||
using `-o jsonpath={..image}`. This will recursively parse out the
|
||||
`image` field from the returned json.
|
||||
- See the [jsonpath reference](/docs/user-guide/jsonpath/)
|
||||
- See the [jsonpath reference](/docs/reference/kubectl/jsonpath/)
|
||||
for further information on how to use jsonpath.
|
||||
- Format the output using standard tools: `tr`, `sort`, `uniq`
|
||||
- Use `tr` to replace spaces with newlines
|
||||
- Use `sort` to sort the results
|
||||
- Use `uniq` to aggregate image counts
|
||||
|
||||
```sh
|
||||
```shell
|
||||
kubectl get pods --all-namespaces -o jsonpath="{..image}" |\
|
||||
tr -s '[[:space:]]' '\n' |\
|
||||
sort |\
|
||||
@@ -52,7 +47,7 @@ field within the Pod. This ensures the correct field is retrieved
|
||||
even when the field name is repeated,
|
||||
e.g. many fields are called `name` within a given item:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}"
|
||||
```
|
||||
|
||||
@@ -74,7 +69,7 @@ Pod is returned instead of a list of items.
|
||||
The formatting can be controlled further by using the `range` operation to
|
||||
iterate over elements individually.
|
||||
|
||||
```sh
|
||||
```shell
|
||||
kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\
|
||||
sort
|
||||
```
|
||||
@@ -84,7 +79,7 @@ sort
|
||||
To target only Pods matching a specific label, use the -l flag. The
|
||||
following matches only Pods with labels matching `app=nginx`.
|
||||
|
||||
```sh
|
||||
```shell
|
||||
kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx
|
||||
```
|
||||
|
||||
@@ -93,7 +88,7 @@ kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx
|
||||
To target only pods in a specific namespace, use the namespace flag. The
|
||||
following matches only Pods in the `kube-system` namespace.
|
||||
|
||||
```sh
|
||||
```shell
|
||||
kubectl get pods --namespace kube-system -o jsonpath="{..image}"
|
||||
```
|
||||
|
||||
@@ -102,27 +97,14 @@ kubectl get pods --namespace kube-system -o jsonpath="{..image}"
|
||||
As an alternative to jsonpath, Kubectl supports using [go-templates](https://golang.org/pkg/text/template/)
|
||||
for formatting the output:
|
||||
|
||||
|
||||
```sh
|
||||
```shell
|
||||
kubectl get pods --all-namespaces -o go-template --template="{{range .items}}{{range .spec.containers}}{{.image}} {{end}}{{end}}"
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- discussion -->
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
### Reference
|
||||
|
||||
* [Jsonpath](/docs/user-guide/jsonpath/) reference guide
|
||||
* [Jsonpath](/docs/reference/kubectl/jsonpath/) reference guide
|
||||
* [Go template](https://golang.org/pkg/text/template/) reference guide
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -14,15 +14,19 @@ card:
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
Dashboard is a web-based Kubernetes user interface. You can use Dashboard to deploy containerized applications to a Kubernetes cluster, troubleshoot your containerized application, and manage the cluster resources. You can use Dashboard to get an overview of applications running on your cluster, as well as for creating or modifying individual Kubernetes resources (such as Deployments, Jobs, DaemonSets, etc). For example, you can scale a Deployment, initiate a rolling update, restart a pod or deploy new applications using a deploy wizard.
|
||||
Dashboard is a web-based Kubernetes user interface.
|
||||
You can use Dashboard to deploy containerized applications to a Kubernetes cluster,
|
||||
troubleshoot your containerized application, and manage the cluster resources.
|
||||
You can use Dashboard to get an overview of applications running on your cluster,
|
||||
as well as for creating or modifying individual Kubernetes resources
|
||||
(such as Deployments, Jobs, DaemonSets, etc).
|
||||
For example, you can scale a Deployment, initiate a rolling update, restart a pod
|
||||
or deploy new applications using a deploy wizard.
|
||||
|
||||
Dashboard also provides information on the state of Kubernetes resources in your cluster and on any errors that may have occurred.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Deploying the Dashboard UI
|
||||
@@ -35,8 +39,10 @@ kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0/a
|
||||
|
||||
## Accessing the Dashboard UI
|
||||
|
||||
|
||||
To protect your cluster data, Dashboard deploys with a minimal RBAC configuration by default. Currently, Dashboard only supports logging in with a Bearer Token. To create a token for this demo, you can follow our guide on [creating a sample user](https://github.com/kubernetes/dashboard/blob/master/docs/user/access-control/creating-sample-user.md).
|
||||
To protect your cluster data, Dashboard deploys with a minimal RBAC configuration by default.
|
||||
Currently, Dashboard only supports logging in with a Bearer Token.
|
||||
To create a token for this demo, you can follow our guide on
|
||||
[creating a sample user](https://github.com/kubernetes/dashboard/blob/master/docs/user/access-control/creating-sample-user.md).
|
||||
|
||||
{{< warning >}}
|
||||
The sample user created in the tutorial will have administrative privileges and is for educational purposes only.
|
||||
@@ -59,13 +65,17 @@ Kubeconfig Authentication method does NOT support external identity providers or
|
||||
|
||||
## Welcome view
|
||||
|
||||
When you access Dashboard on an empty cluster, you'll see the welcome page. This page contains a link to this document as well as a button to deploy your first application. In addition, you can view which system applications are running by default in the `kube-system` [namespace](/docs/tasks/administer-cluster/namespaces/) of your cluster, for example the Dashboard itself.
|
||||
When you access Dashboard on an empty cluster, you'll see the welcome page.
|
||||
This page contains a link to this document as well as a button to deploy your first application.
|
||||
In addition, you can view which system applications are running by default in the `kube-system`
|
||||
[namespace](/docs/tasks/administer-cluster/namespaces/) of your cluster, for example the Dashboard itself.
|
||||
|
||||
|
||||
|
||||
## Deploying containerized applications
|
||||
|
||||
Dashboard lets you create and deploy a containerized application as a Deployment and optional Service with a simple wizard. You can either manually specify application details, or upload a YAML or JSON file containing application configuration.
|
||||
Dashboard lets you create and deploy a containerized application as a Deployment and optional Service with a simple wizard.
|
||||
You can either manually specify application details, or upload a YAML or JSON file containing application configuration.
|
||||
|
||||
Click the **CREATE** button in the upper right corner of any page to begin.
|
||||
|
||||
@@ -73,17 +83,29 @@ Click the **CREATE** button in the upper right corner of any page to begin.
|
||||
|
||||
The deploy wizard expects that you provide the following information:
|
||||
|
||||
- **App name** (mandatory): Name for your application. A [label](/docs/concepts/overview/working-with-objects/labels/) with the name will be added to the Deployment and Service, if any, that will be deployed.
|
||||
- **App name** (mandatory): Name for your application.
|
||||
A [label](/docs/concepts/overview/working-with-objects/labels/) with the name will be
|
||||
added to the Deployment and Service, if any, that will be deployed.
|
||||
|
||||
The application name must be unique within the selected Kubernetes [namespace](/docs/tasks/administer-cluster/namespaces/). It must start with a lowercase character, and end with a lowercase character or a number, and contain only lowercase letters, numbers and dashes (-). It is limited to 24 characters. Leading and trailing spaces are ignored.
|
||||
The application name must be unique within the selected Kubernetes [namespace](/docs/tasks/administer-cluster/namespaces/).
|
||||
It must start with a lowercase character, and end with a lowercase character or a number,
|
||||
and contain only lowercase letters, numbers and dashes (-). It is limited to 24 characters.
|
||||
Leading and trailing spaces are ignored.
|
||||
|
||||
- **Container image** (mandatory): The URL of a public Docker [container image](/docs/concepts/containers/images/) on any registry, or a private image (commonly hosted on the Google Container Registry or Docker Hub). The container image specification must end with a colon.
|
||||
- **Container image** (mandatory):
|
||||
The URL of a public Docker [container image](/docs/concepts/containers/images/) on any registry,
|
||||
or a private image (commonly hosted on the Google Container Registry or Docker Hub).
|
||||
The container image specification must end with a colon.
|
||||
|
||||
- **Number of pods** (mandatory): The target number of Pods you want your application to be deployed in. The value must be a positive integer.
|
||||
- **Number of pods** (mandatory): The target number of Pods you want your application to be deployed in.
|
||||
The value must be a positive integer.
|
||||
|
||||
A [Deployment](/docs/concepts/workloads/controllers/deployment/) will be created to maintain the desired number of Pods across your cluster.
|
||||
A [Deployment](/docs/concepts/workloads/controllers/deployment/) will be created to
|
||||
maintain the desired number of Pods across your cluster.
|
||||
|
||||
- **Service** (optional): For some parts of your application (e.g. frontends) you may want to expose a [Service](/docs/concepts/services-networking/service/) onto an external, maybe public IP address outside of your cluster (external Service).
|
||||
- **Service** (optional): For some parts of your application (e.g. frontends) you may want to expose a
|
||||
[Service](/docs/concepts/services-networking/service/) onto an external,
|
||||
maybe public IP address outside of your cluster (external Service).
|
||||
|
||||
{{< note >}}
|
||||
For external Services, you may need to open up one or more ports to do so.
|
||||
@@ -91,13 +113,22 @@ The deploy wizard expects that you provide the following information:
|
||||
|
||||
Other Services that are only visible from inside the cluster are called internal Services.
|
||||
|
||||
Irrespective of the Service type, if you choose to create a Service and your container listens on a port (incoming), you need to specify two ports. The Service will be created mapping the port (incoming) to the target port seen by the container. This Service will route to your deployed Pods. Supported protocols are TCP and UDP. The internal DNS name for this Service will be the value you specified as application name above.
|
||||
Irrespective of the Service type, if you choose to create a Service and your container listens
|
||||
on a port (incoming), you need to specify two ports.
|
||||
The Service will be created mapping the port (incoming) to the target port seen by the container.
|
||||
This Service will route to your deployed Pods. Supported protocols are TCP and UDP.
|
||||
The internal DNS name for this Service will be the value you specified as application name above.
|
||||
|
||||
If needed, you can expand the **Advanced options** section where you can specify more settings:
|
||||
|
||||
- **Description**: The text you enter here will be added as an [annotation](/docs/concepts/overview/working-with-objects/annotations/) to the Deployment and displayed in the application's details.
|
||||
- **Description**: The text you enter here will be added as an
|
||||
[annotation](/docs/concepts/overview/working-with-objects/annotations/)
|
||||
to the Deployment and displayed in the application's details.
|
||||
|
||||
- **Labels**: Default [labels](/docs/concepts/overview/working-with-objects/labels/) to be used for your application are application name and version. You can specify additional labels to be applied to the Deployment, Service (if any), and Pods, such as release, environment, tier, partition, and release track.
|
||||
- **Labels**: Default [labels](/docs/concepts/overview/working-with-objects/labels/) to be used
|
||||
for your application are application name and version.
|
||||
You can specify additional labels to be applied to the Deployment, Service (if any), and Pods,
|
||||
such as release, environment, tier, partition, and release track.
|
||||
|
||||
Example:
|
||||
|
||||
@@ -108,66 +139,111 @@ If needed, you can expand the **Advanced options** section where you can specify
|
||||
track=stable
|
||||
```
|
||||
|
||||
- **Namespace**: Kubernetes supports multiple virtual clusters backed by the same physical cluster. These virtual clusters are called [namespaces](/docs/tasks/administer-cluster/namespaces/). They let you partition resources into logically named groups.
|
||||
- **Namespace**: Kubernetes supports multiple virtual clusters backed by the same physical cluster.
|
||||
These virtual clusters are called [namespaces](/docs/tasks/administer-cluster/namespaces/).
|
||||
They let you partition resources into logically named groups.
|
||||
|
||||
Dashboard offers all available namespaces in a dropdown list, and allows you to create a new namespace. The namespace name may contain a maximum of 63 alphanumeric characters and dashes (-) but can not contain capital letters.
|
||||
Namespace names should not consist of only numbers. If the name is set as a number, such as 10, the pod will be put in the default namespace.
|
||||
Dashboard offers all available namespaces in a dropdown list, and allows you to create a new namespace.
|
||||
The namespace name may contain a maximum of 63 alphanumeric characters and dashes (-) but can not contain capital letters.
|
||||
Namespace names should not consist of only numbers.
|
||||
If the name is set as a number, such as 10, the pod will be put in the default namespace.
|
||||
|
||||
In case the creation of the namespace is successful, it is selected by default. If the creation fails, the first namespace is selected.
|
||||
In case the creation of the namespace is successful, it is selected by default.
|
||||
If the creation fails, the first namespace is selected.
|
||||
|
||||
- **Image Pull Secret**: In case the specified Docker container image is private, it may require [pull secret](/docs/concepts/configuration/secret/) credentials.
|
||||
- **Image Pull Secret**:
|
||||
In case the specified Docker container image is private, it may require
|
||||
[pull secret](/docs/concepts/configuration/secret/) credentials.
|
||||
|
||||
Dashboard offers all available secrets in a dropdown list, and allows you to create a new secret. The secret name must follow the DNS domain name syntax, for example `new.image-pull.secret`. The content of a secret must be base64-encoded and specified in a [`.dockercfg`](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) file. The secret name may consist of a maximum of 253 characters.
|
||||
Dashboard offers all available secrets in a dropdown list, and allows you to create a new secret.
|
||||
The secret name must follow the DNS domain name syntax, for example `new.image-pull.secret`.
|
||||
The content of a secret must be base64-encoded and specified in a
|
||||
[`.dockercfg`](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) file.
|
||||
The secret name may consist of a maximum of 253 characters.
|
||||
|
||||
In case the creation of the image pull secret is successful, it is selected by default. If the creation fails, no secret is applied.
|
||||
|
||||
- **CPU requirement (cores)** and **Memory requirement (MiB)**: You can specify the minimum [resource limits](/docs/tasks/configure-pod-container/limit-range/) for the container. By default, Pods run with unbounded CPU and memory limits.
|
||||
- **CPU requirement (cores)** and **Memory requirement (MiB)**:
|
||||
You can specify the minimum [resource limits](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
|
||||
for the container. By default, Pods run with unbounded CPU and memory limits.
|
||||
|
||||
- **Run command** and **Run command arguments**: By default, your containers run the specified Docker image's default [entrypoint command](/docs/tasks/inject-data-application/define-command-argument-container/). You can use the command options and arguments to override the default.
|
||||
- **Run command** and **Run command arguments**:
|
||||
By default, your containers run the specified Docker image's default
|
||||
[entrypoint command](/docs/tasks/inject-data-application/define-command-argument-container/).
|
||||
You can use the command options and arguments to override the default.
|
||||
|
||||
- **Run as privileged**: This setting determines whether processes in [privileged containers](/docs/user-guide/pods/#privileged-mode-for-pod-containers) are equivalent to processes running as root on the host. Privileged containers can make use of capabilities like manipulating the network stack and accessing devices.
|
||||
- **Run as privileged**: This setting determines whether processes in
|
||||
[privileged containers](/docs/concepts/workloads/pods/#privileged-mode-for-containers)
|
||||
are equivalent to processes running as root on the host.
|
||||
Privileged containers can make use of capabilities like manipulating the network stack and accessing devices.
|
||||
|
||||
- **Environment variables**: Kubernetes exposes Services through [environment variables](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/). You can compose environment variable or pass arguments to your commands using the values of environment variables. They can be used in applications to find a Service. Values can reference other variables using the `$(VAR_NAME)` syntax.
|
||||
- **Environment variables**: Kubernetes exposes Services through
|
||||
[environment variables](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/).
|
||||
You can compose environment variable or pass arguments to your commands using the values of environment variables.
|
||||
They can be used in applications to find a Service.
|
||||
Values can reference other variables using the `$(VAR_NAME)` syntax.
|
||||
|
||||
### Uploading a YAML or JSON file
|
||||
|
||||
Kubernetes supports declarative configuration. In this style, all configuration is stored in YAML or JSON configuration files using the Kubernetes [API](/docs/concepts/overview/kubernetes-api/) resource schemas.
|
||||
Kubernetes supports declarative configuration.
|
||||
In this style, all configuration is stored in YAML or JSON configuration files
|
||||
using the Kubernetes [API](/docs/concepts/overview/kubernetes-api/) resource schemas.
|
||||
|
||||
As an alternative to specifying application details in the deploy wizard, you can define your application in YAML or JSON files, and upload the files using Dashboard.
|
||||
As an alternative to specifying application details in the deploy wizard,
|
||||
you can define your application in YAML or JSON files, and upload the files using Dashboard.
|
||||
|
||||
## Using Dashboard
|
||||
Following sections describe views of the Kubernetes Dashboard UI; what they provide and how can they be used.
|
||||
|
||||
### Navigation
|
||||
|
||||
When there are Kubernetes objects defined in the cluster, Dashboard shows them in the initial view. By default only objects from the _default_ namespace are shown and this can be changed using the namespace selector located in the navigation menu.
|
||||
When there are Kubernetes objects defined in the cluster, Dashboard shows them in the initial view.
|
||||
By default only objects from the _default_ namespace are shown and
|
||||
this can be changed using the namespace selector located in the navigation menu.
|
||||
|
||||
Dashboard shows most Kubernetes object kinds and groups them in a few menu categories.
|
||||
|
||||
#### Admin Overview
|
||||
For cluster and namespace administrators, Dashboard lists Nodes, Namespaces and Persistent Volumes and has detail views for them. Node list view contains CPU and memory usage metrics aggregated across all Nodes. The details view shows the metrics for a Node, its specification, status, allocated resources, events and pods running on the node.
|
||||
For cluster and namespace administrators, Dashboard lists Nodes, Namespaces and Persistent Volumes and has detail views for them.
|
||||
Node list view contains CPU and memory usage metrics aggregated across all Nodes.
|
||||
The details view shows the metrics for a Node, its specification, status,
|
||||
allocated resources, events and pods running on the node.
|
||||
|
||||
#### Workloads
|
||||
Shows all applications running in the selected namespace. The view lists applications by workload kind (e.g., Deployments, Replica Sets, Stateful Sets, etc.) and each workload kind can be viewed separately. The lists summarize actionable information about the workloads, such as the number of ready pods for a Replica Set or current memory usage for a Pod.
|
||||
|
||||
Detail views for workloads show status and specification information and surface relationships between objects. For example, Pods that Replica Set is controlling or New Replica Sets and Horizontal Pod Autoscalers for Deployments.
|
||||
Shows all applications running in the selected namespace.
|
||||
The view lists applications by workload kind (e.g., Deployments, Replica Sets, Stateful Sets, etc.)
|
||||
and each workload kind can be viewed separately.
|
||||
The lists summarize actionable information about the workloads,
|
||||
such as the number of ready pods for a Replica Set or current memory usage for a Pod.
|
||||
|
||||
Detail views for workloads show status and specification information and
|
||||
surface relationships between objects.
|
||||
For example, Pods that Replica Set is controlling or New Replica Sets and Horizontal Pod Autoscalers for Deployments.
|
||||
|
||||
#### Services
|
||||
Shows Kubernetes resources that allow for exposing services to external world and discovering them within a cluster. For that reason, Service and Ingress views show Pods targeted by them, internal endpoints for cluster connections and external endpoints for external users.
|
||||
|
||||
Shows Kubernetes resources that allow for exposing services to external world and
|
||||
discovering them within a cluster.
|
||||
For that reason, Service and Ingress views show Pods targeted by them,
|
||||
internal endpoints for cluster connections and external endpoints for external users.
|
||||
|
||||
#### Storage
|
||||
|
||||
Storage view shows Persistent Volume Claim resources which are used by applications for storing data.
|
||||
|
||||
#### Config Maps and Secrets
|
||||
Shows all Kubernetes resources that are used for live configuration of applications running in clusters. The view allows for editing and managing config objects and displays secrets hidden by default.
|
||||
|
||||
Shows all Kubernetes resources that are used for live configuration of applications running in clusters.
|
||||
The view allows for editing and managing config objects and displays secrets hidden by default.
|
||||
|
||||
#### Logs viewer
|
||||
Pod lists and detail pages link to a logs viewer that is built into Dashboard. The viewer allows for drilling down logs from containers belonging to a single Pod.
|
||||
|
||||
Pod lists and detail pages link to a logs viewer that is built into Dashboard.
|
||||
The viewer allows for drilling down logs from containers belonging to a single Pod.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user