whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge branch 'main' into ingressControllerNamespace

Browse Source
This commit is contained in:
Kartik Sharma
2021-09-09 08:40:39 +05:30
committed by GitHub
parent b16ccb3d1d 8155f1d16d
commit bd8f97816a
1319 changed files with 184082 additions and 13285 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/tasks/access-application-cluster/_index.md
Executable → Regular
View File
content/en/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
+26 -20
View File
@@ -7,7 +7,6 @@ card:
weight: 40
---
<!-- overview -->
This page shows how to configure access to multiple clusters by using
@@ -22,19 +21,21 @@ It does not mean that there is a file named `kubeconfig`.
{{< /note >}}
{{< warning >}}
Only use kubeconfig files from trusted sources. Using a specially-crafted kubeconfig file could result in malicious code execution or file exposure.
If you must use an untrusted kubeconfig file, inspect it carefully first, much as you would a shell script.
{{< /warning>}}
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}}
To check that {{< glossary_tooltip text="kubectl" term_id="kubectl" >}} is installed,
run `kubectl version --client`. The kubectl version should be
[within one minor version](/docs/setup/release/version-skew-policy/#kubectl) of your
[within one minor version](/releases/version-skew-policy/#kubectl) of your
cluster's API server.
<!-- steps -->
## Define clusters, users, and contexts
@@ -186,7 +187,7 @@ kubectl config --kubeconfig=config-demo view --minify
The output shows configuration information associated with the `dev-frontend` context:
```shell
```yaml
apiVersion: v1
clusters:
- cluster:
@@ -238,7 +239,6 @@ kubectl config --kubeconfig=config-demo use-context dev-storage
View configuration associated with the new current context, `dev-storage`.
```shell
kubectl config --kubeconfig=config-demo view --minify
```
@@ -247,7 +247,7 @@ kubectl config --kubeconfig=config-demo view --minify
In your `config-exercise` directory, create a file named `config-demo-2` with this content:
```shell
```yaml
apiVersion: v1
kind: Config
preferences: {}
@@ -269,13 +269,17 @@ current value of your `KUBECONFIG` environment variable, so you can restore it l
For example:
### Linux
```shell
export KUBECONFIG_SAVED=$KUBECONFIG
```
### Windows PowerShell
```shell
```powershell
$Env:KUBECONFIG_SAVED=$ENV:KUBECONFIG
```
The `KUBECONFIG` environment variable is a list of paths to configuration files. The list is
colon-delimited for Linux and Mac, and semicolon-delimited for Windows. If you have
a `KUBECONFIG` environment variable, familiarize yourself with the configuration files
@@ -284,11 +288,14 @@ in the list.
Temporarily append two paths to your `KUBECONFIG` environment variable. For example:
### Linux
```shell
export KUBECONFIG=$KUBECONFIG:config-demo:config-demo-2
```
### Windows PowerShell
```shell
```powershell
$Env:KUBECONFIG=("config-demo;config-demo-2")
```
@@ -303,7 +310,7 @@ environment variable. In particular, notice that the merged information has the
`dev-ramp-up` context from the `config-demo-2` file and the three contexts from
the `config-demo` file:
```shell
```yaml
contexts:
- context:
cluster: development
@@ -347,11 +354,14 @@ If you have a `$HOME/.kube/config` file, and it's not already listed in your
For example:
### Linux
```shell
export KUBECONFIG=$KUBECONFIG:$HOME/.kube/config
```
### Windows Powershell
```shell
```powershell
$Env:KUBECONFIG="$Env:KUBECONFIG;$HOME\.kube\config"
```
@@ -367,23 +377,19 @@ kubectl config view
Return your `KUBECONFIG` environment variable to its original value. For example:<br>
### Linux
```shell
export KUBECONFIG=$KUBECONFIG_SAVED
```
### Windows PowerShell
```shell
```powershell
$Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED
```
## {{% heading "whatsnext" %}}
* [Organizing Cluster Access Using kubeconfig Files](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
* [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config)
content/en/docs/tasks/access-application-cluster/create-external-load-balancer.md
+85 -85
View File
@@ -4,47 +4,44 @@ content_type: task
weight: 80
---
<!-- overview -->
This page shows how to create an External Load Balancer.
This page shows how to create an external load balancer.
{{< note >}}
This feature is only available for cloud providers or environments which support external load balancers.
{{< /note >}}
When creating a service, you have the option of automatically creating a
cloud network load balancer. This provides an externally-accessible IP address
that sends traffic to the correct port on your cluster nodes
When creating a {{< glossary_tooltip text="Service" term_id="service" >}}, you have
the option of automatically creating a cloud load balancer. This provides an
externally-accessible IP address that sends traffic to the correct port on your cluster
nodes,
_provided your cluster runs in a supported environment and is configured with
the correct cloud load balancer provider package_.
For information on provisioning and using an Ingress resource that can give
services externally-reachable URLs, load balance the traffic, terminate SSL etc.,
please check the [Ingress](/docs/concepts/services-networking/ingress/)
You can also use an {{< glossary_tooltip term_id="ingress" >}} in place of Service.
For more information, check the [Ingress](/docs/concepts/services-networking/ingress/)
documentation.
## {{% heading "prerequisites" %}}
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{< include "task-tutorial-prereqs.md" >}}
Your cluster must be running in a cloud or other environment that already has support
for configuring external load balancers.
<!-- steps -->
## Configuration file
## Create a Service
### Create a Service from a manifest
To create an external load balancer, add the following line to your
[service configuration file](/docs/concepts/services-networking/service/#loadbalancer):
Service manifest:
```yaml
type: LoadBalancer
```
Your configuration file might look like:
Your manifest might then look like:
```yaml
apiVersion: v1
@@ -60,19 +57,19 @@ spec:
type: LoadBalancer
```
## Using kubectl
### Create a Service using kubectl
You can alternatively create the service with the `kubectl expose` command and
its `--type=LoadBalancer` flag:
```bash
kubectl expose rc example --port=8765 --target-port=9376 \
kubectl expose deployment example --port=8765 --target-port=9376 \
--name=example-service --type=LoadBalancer
```
This command creates a new service using the same selectors as the referenced
resource (in the case of the example above, a replication controller named
`example`).
This command creates a new Service using the same selectors as the referenced
resource (in the case of the example above, a
{{< glossary_tooltip text="Deployment" term_id="deployment" >}} named `example`).
For more information, including optional flags, refer to the
[`kubectl expose` reference](/docs/reference/generated/kubectl/kubectl-commands/#expose).
@@ -86,59 +83,63 @@ information through `kubectl`:
kubectl describe services example-service
```
which should produce output like this:
which should produce output similar to:
```bash
Name: example-service
Namespace: default
Labels: <none>
Annotations: <none>
Selector: app=example
Type: LoadBalancer
IP: 10.67.252.103
LoadBalancer Ingress: 192.0.2.89
Port: <unnamed> 80/TCP
NodePort: <unnamed> 32445/TCP
Endpoints: 10.64.0.4:80,10.64.1.5:80,10.64.2.4:80
Session Affinity: None
Events: <none>
```
Name: example-service
Namespace: default
Labels: app=example
Annotations: <none>
Selector: app=example
Type: LoadBalancer
IP Families: <none>
IP: 10.3.22.96
IPs: 10.3.22.96
LoadBalancer Ingress: 192.0.2.89
Port: <unset> 8765/TCP
TargetPort: 9376/TCP
NodePort: <unset> 30593/TCP
Endpoints: 172.17.0.3:9376
Session Affinity: None
External Traffic Policy: Cluster
Events: <none>
```
The IP address is listed next to `LoadBalancer Ingress`.
The load balancer's IP address is listed next to `LoadBalancer Ingress`.
{{< note >}}
If you are running your service on Minikube, you can find the assigned IP address and port with:
{{< /note >}}
```bash
minikube service example-service --url
```
{{< /note >}}
## Preserving the client source IP
Due to the implementation of this feature, the source IP seen in the target
container is *not the original source IP* of the client. To enable
preservation of the client IP, the following fields can be configured in the
service spec (supported in GCE/Google Kubernetes Engine environments):
By default, the source IP seen in the target container is *not the original
source IP* of the client. To enable preservation of the client IP, the following
fields can be configured in the `.spec` of the Service:
* `service.spec.externalTrafficPolicy` - denotes if this Service desires to route
external traffic to node-local or cluster-wide endpoints. There are two available
options: Cluster (default) and Local. Cluster obscures the client source
IP and may cause a second hop to another node, but should have good overall
load-spreading. Local preserves the client source IP and avoids a second hop
for LoadBalancer and NodePort type services, but risks potentially imbalanced
traffic spreading.
* `service.spec.healthCheckNodePort` - specifies the health check node port
(numeric port number) for the service. If `healthCheckNodePort` isn't specified,
the service controller allocates a port from your cluster's NodePort range. You
can configure that range by setting an API server command line option,
`--service-node-port-range`. It will use the
user-specified `healthCheckNodePort` value if specified by the client. It only has an
effect when `type` is set to LoadBalancer and `externalTrafficPolicy` is set
to Local.
* `.spec.externalTrafficPolicy` - denotes if this Service desires to route
external traffic to node-local or cluster-wide endpoints. There are two available
options: `Cluster` (default) and `Local`. `Cluster` obscures the client source
IP and may cause a second hop to another node, but should have good overall
load-spreading. `Local` preserves the client source IP and avoids a second hop
for LoadBalancer and NodePort type Services, but risks potentially imbalanced
traffic spreading.
* `.spec.healthCheckNodePort` - specifies the health check node port
(numeric port number) for the service. If you don't specify
`healthCheckNodePort`, the service controller allocates a port from your
cluster's NodePort range.
You can configure that range by setting an API server command line option,
`--service-node-port-range`. The Service will use the user-specified
`healthCheckNodePort` value if you specify it, provided that the
Service `type` is set to LoadBalancer and `externalTrafficPolicy` is set
to `Local`.
Setting `externalTrafficPolicy` to Local in the Service configuration file
activates this feature.
Setting `externalTrafficPolicy` to Local in the Service manifest
activates this feature. For example:
```yaml
apiVersion: v1
@@ -155,7 +156,20 @@ spec:
type: LoadBalancer
```
## Garbage Collecting Load Balancers
### Caveats and limitations when preserving source IPs
Load balancing services from some cloud providers do not let you configure different weights for each target.
With each target weighted equally in terms of sending traffic to Nodes, external
traffic is not equally load balanced across different Pods. The external load balancer
is unaware of the number of Pods on each node that are used as a target.
Where `NumServicePods << _NumNodes` or `NumServicePods >> NumNodes`, a fairly close-to-equal
distribution will be seen, even without weights.
Internal pod to pod traffic should behave similar to ClusterIP services, with equal probability across all pods.
## Garbage collecting load balancers
{{< feature-state for_k8s_version="v1.17" state="stable" >}}
@@ -172,32 +186,18 @@ The finalizer will only be removed after the load balancer resource is cleaned u
This prevents dangling load balancer resources even in corner cases such as the
service controller crashing.
## External Load Balancer Providers
## External load balancer providers
It is important to note that the datapath for this functionality is provided by a load balancer external to the Kubernetes cluster.
When the Service `type` is set to LoadBalancer, Kubernetes provides functionality equivalent to `type` equals ClusterIP to pods
within the cluster and extends it by programming the (external to Kubernetes) load balancer with entries for the Kubernetes
pods. The Kubernetes service controller automates the creation of the external load balancer, health checks (if needed),
firewall rules (if needed) and retrieves the external IP allocated by the cloud provider and populates it in the service
object.
## Caveats and Limitations when preserving source IPs
GCE/AWS load balancers do not provide weights for their target pools. This was not an issue with the old LB
kube-proxy rules which would correctly balance across all endpoints.
With the new functionality, the external traffic is not equally load balanced across pods, but rather
equally balanced at the node level (because GCE/AWS and other external LB implementations do not have the ability
for specifying the weight per node, they balance equally across all target nodes, disregarding the number of
pods on each node).
We can, however, state that for NumServicePods << NumNodes or NumServicePods >> NumNodes, a fairly close-to-equal
distribution will be seen, even without weights.
Once the external load balancers provide weights, this functionality can be added to the LB programming path.
*Future Work: No support for weights is provided for the 1.4 release, but may be added at a future date*
Internal pod to pod traffic should behave similar to ClusterIP services, with equal probability across all pods.
within the cluster and extends it by programming the (external to Kubernetes) load balancer with entries for the nodes
hosting the relevant Kubernetes pods. The Kubernetes control plane automates the creation of the external load balancer,
health checks (if needed), and packet filtering rules (if needed). Once the cloud provider allocates an IP address for the load
balancer, the control plane looks up that external IP address and populates it into the Service object.
## {{% heading "whatsnext" %}}
* Read about [Service](/docs/concepts/services-networking/service/)
* Read about [Ingress](/docs/concepts/services-networking/ingress/)
* Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)
content/en/docs/tasks/access-application-cluster/ingress-minikube.md
+17
View File
@@ -44,6 +44,7 @@ This page shows you how to set up a simple Ingress which routes requests to Serv
1. Verify that the NGINX Ingress controller is running
{{< tabs name="tab_with_md" >}}
{{% tab name="minikube v1.19 or later" %}}
```shell
@@ -83,6 +84,22 @@ storage-provisioner 1/1 Running 0 2m
```shell
kubectl get pods -n ingress-nginx
```
{{< note >}}This can take up to a minute.{{< /note >}}
Output:
```shell
NAME READY STATUS RESTARTS AGE
ingress-nginx-admission-create-2tgrf 0/1 Completed 0 3m28s
ingress-nginx-admission-patch-68b98 0/1 Completed 0 3m28s
ingress-nginx-controller-59b45fb494-lzmw2 1/1 Running 0 3m28s
```
## Deploy a hello, world app
1. Create a Deployment using the following command:
content/en/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md
+2 -2
View File
@@ -31,7 +31,7 @@ for database debugging.
1. Create a Deployment that runs MongoDB:
```shell
kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-deployment.yaml
kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-deployment.yaml
```
The output of a successful command verifies that the deployment was created:
@@ -84,7 +84,7 @@ for database debugging.
2. Create a Service to expose MongoDB on the network:
```shell
kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-service.yaml
kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-service.yaml
```
The output of a successful command verifies that the Service was created:
content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md
+22 -16
View File
@@ -2,8 +2,9 @@
reviewers:
- bryk
- mikedanese
- rf232
title: Web UI (Dashboard)
title: Deploy and Access the Kubernetes Dashboard
description: >-
Deploy the web UI (Kubernetes Dashboard) and access it.
content_type: concept
weight: 10
card:
@@ -34,7 +35,7 @@ Dashboard also provides information on the state of Kubernetes resources in your
The Dashboard UI is not deployed by default. To deploy it, run the following command:
```
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.2.0/aio/deploy/recommended.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.3.1/aio/deploy/recommended.yaml
```
## Accessing the Dashboard UI
@@ -49,7 +50,9 @@ The sample user created in the tutorial will have administrative privileges and
{{< /warning >}}
### Command line proxy
You can access Dashboard using the kubectl command-line tool by running the following command:
You can enable access to the Dashboard using the `kubectl` command-line tool,
by running the following command:
```
kubectl proxy
@@ -60,7 +63,8 @@ Kubectl will make Dashboard available at [http://localhost:8001/api/v1/namespace
The UI can _only_ be accessed from the machine where the command is executed. See `kubectl proxy --help` for more options.
{{< note >}}
Kubeconfig Authentication method does NOT support external identity providers or x509 certificate-based authentication.
The kubeconfig authentication method does **not** support external identity providers
or X.509 certificate-based authentication.
{{< /note >}}
## Welcome view
@@ -75,7 +79,7 @@ In addition, you can view which system applications are running by default in th
## 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.
You can either manually specify application details, or upload a YAML or JSON _manifest_ file containing application configuration.
Click the **CREATE** button in the upper right corner of any page to begin.
@@ -186,13 +190,14 @@ If needed, you can expand the **Advanced options** section where you can specify
### 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.
In this style, all configuration is stored in manifests (YAML or JSON configuration files).
The manifests use 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.
you can define your application in one or more manifests, 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
@@ -203,8 +208,9 @@ 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.
#### Admin overview
For cluster and namespace administrators, Dashboard lists Nodes, Namespaces and PersistentVolumes 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.
@@ -212,14 +218,14 @@ 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.)
The view lists applications by workload kind (for example: Deployments, ReplicaSets, StatefulSets).
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.
such as the number of ready pods for a ReplicaSet 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.
For example, Pods that ReplicaSet is controlling or new ReplicaSets and HorizontalPodAutoscalers for Deployments.
#### Services
@@ -230,9 +236,9 @@ internal endpoints for cluster connections and external endpoints for external u
#### Storage
Storage view shows Persistent Volume Claim resources which are used by applications for storing data.
Storage view shows PersistentVolumeClaim resources which are used by applications for storing data.
#### Config Maps and Secrets
#### ConfigMaps and Secrets {#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.