Merge master into dev-1.22 to keep in sync
This commit is contained in:
Victor Palade
@@ -254,7 +254,8 @@ from failed Jobs is not lost inadvertently.
|
||||
|
||||
## Job termination and cleanup
|
||||
|
||||
When a Job completes, no more Pods are created, but the Pods are not deleted either. Keeping them around
|
||||
When a Job completes, no more Pods are created, but the Pods are [usually](#pod-backoff-failure-policy) not deleted either.
|
||||
Keeping them around
|
||||
allows you to still view the logs of completed pods to check for errors, warnings, or other diagnostic output.
|
||||
The job object also remains after it is completed so that you can view its status. It is up to the user to delete
|
||||
old jobs after noting their status. Delete the job with `kubectl` (e.g. `kubectl delete jobs/pi` or `kubectl delete -f ./job.yaml`). When you delete the job using `kubectl`, all the pods it created are deleted too.
|
||||
|
||||
@@ -167,7 +167,7 @@ If you want to use bootstrap tokens, you must enable it on kube-apiserver with t
|
||||
|
||||
#### Token authentication file
|
||||
|
||||
kube-apiserver has an ability to accept tokens as authentication.
|
||||
kube-apiserver has the ability to accept tokens as authentication.
|
||||
These tokens are arbitrary but should represent at least 128 bits of entropy derived
|
||||
from a secure random number generator (such as `/dev/urandom` on most modern Linux
|
||||
systems). There are multiple ways you can generate a token. For example:
|
||||
|
||||
@@ -89,7 +89,7 @@ Operation | Syntax | Description
|
||||
`cluster-info` | `kubectl cluster-info [flags]` | Display endpoint information about the master and services in the cluster.
|
||||
`completion` | `kubectl completion SHELL [options]` | Output shell completion code for the specified shell (bash or zsh).
|
||||
`config` | `kubectl config SUBCOMMAND [flags]` | Modifies kubeconfig files. See the individual subcommands for details.
|
||||
`convert` | `kubectl convert -f FILENAME [options]` | Convert config files between different API versions. Both YAML and JSON formats are accepted.
|
||||
`convert` | `kubectl convert -f FILENAME [options]` | Convert config files between different API versions. Both YAML and JSON formats are accepted. Note - requires `kubectl-convert` plugin to be installed.
|
||||
`cordon` | `kubectl cordon NODE [options]` | Mark node as unschedulable.
|
||||
`cp` | `kubectl cp <file-spec-src> <file-spec-dest> [options]` | Copy files and directories to and from containers.
|
||||
`create` | `kubectl create -f FILENAME [flags]` | Create one or more resources from a file or stdin.
|
||||
|
||||
@@ -119,16 +119,16 @@ Use the following phase to configure bootstrap tokens.
|
||||
{{< tab name="bootstrap-token" include="generated/kubeadm_init_phase_bootstrap-token.md" />}}
|
||||
{{< /tabs >}}
|
||||
|
||||
## kubeadm init phase kubelet-finialize {#cmd-phase-kubelet-finalize-all}
|
||||
## kubeadm init phase kubelet-finalize {#cmd-phase-kubelet-finalize-all}
|
||||
|
||||
Use the following phase to update settings relevant to the kubelet after TLS
|
||||
bootstrap. You can use the `all` subcommand to run all `kubelet-finalize`
|
||||
phases.
|
||||
|
||||
{{< tabs name="tab-kubelet-finalize" >}}
|
||||
{{< tab name="kublet-finalize" include="generated/kubeadm_init_phase_kubelet-finalize.md" />}}
|
||||
{{< tab name="kublet-finalize-all" include="generated/kubeadm_init_phase_kubelet-finalize_all.md" />}}
|
||||
{{< tab name="kublet-finalize-cert-rotation" include="generated/kubeadm_init_phase_kubelet-finalize_experimental-cert-rotation.md" />}}
|
||||
{{< tab name="kubelet-finalize" include="generated/kubeadm_init_phase_kubelet-finalize.md" />}}
|
||||
{{< tab name="kubelet-finalize-all" include="generated/kubeadm_init_phase_kubelet-finalize_all.md" />}}
|
||||
{{< tab name="kubelet-finalize-cert-rotation" include="generated/kubeadm_init_phase_kubelet-finalize_experimental-cert-rotation.md" />}}
|
||||
{{< /tabs >}}
|
||||
|
||||
## kubeadm init phase addon {#cmd-phase-addon}
|
||||
|
||||
@@ -146,7 +146,7 @@ For information about passing flags to control plane components see:
|
||||
|
||||
By default, kubeadm pulls images from `k8s.gcr.io`. If the
|
||||
requested Kubernetes version is a CI label (such as `ci/latest`)
|
||||
`gcr.io/kubernetes-ci-images` is used.
|
||||
`gcr.io/k8s-staging-ci-images` is used.
|
||||
|
||||
You can override this behavior by using [kubeadm with a configuration file](#config-file).
|
||||
Allowed customization are:
|
||||
|
||||
+6
-6
@@ -26,7 +26,7 @@ This guide walks you through the steps to configure and deploy a Windows contain
|
||||
## Before you begin
|
||||
|
||||
* Create a Kubernetes cluster that includes a
|
||||
[master and a worker node running Windows Server](/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes)
|
||||
control plane and a [worker node running Windows Server](/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/)
|
||||
* It is important to note that creating and deploying services and workloads on Kubernetes
|
||||
behaves in much the same way for Linux and Windows containers.
|
||||
[Kubectl commands](/docs/reference/kubectl/overview/) to interface with the cluster are identical.
|
||||
@@ -105,15 +105,15 @@ the container port 80 is exposed directly to the service.
|
||||
1. Check that the deployment succeeded. To verify:
|
||||
|
||||
* Two containers per pod on the Windows node, use `docker ps`
|
||||
* Two pods listed from the Linux master, use `kubectl get pods`
|
||||
* Node-to-pod communication across the network, `curl` port 80 of your pod IPs from the Linux master
|
||||
* Two pods listed from the Linux control plane node, use `kubectl get pods`
|
||||
* Node-to-pod communication across the network, `curl` port 80 of your pod IPs from the Linux control plane node
|
||||
to check for a web server response
|
||||
* Pod-to-pod communication, ping between pods (and across hosts, if you have more than one Windows node)
|
||||
using docker exec or kubectl exec
|
||||
* Service-to-pod communication, `curl` the virtual service IP (seen under `kubectl get services`)
|
||||
from the Linux master and from individual pods
|
||||
from the Linux control plane node and from individual pods
|
||||
* Service discovery, `curl` the service name with the Kubernetes [default DNS suffix](/docs/concepts/services-networking/dns-pod-service/#services)
|
||||
* Inbound connectivity, `curl` the NodePort from the Linux master or machines outside of the cluster
|
||||
* Inbound connectivity, `curl` the NodePort from the Linux control plane node or machines outside of the cluster
|
||||
* Outbound connectivity, `curl` external IPs from inside the pod using kubectl exec
|
||||
|
||||
{{< note >}}
|
||||
@@ -184,7 +184,7 @@ For example: `--register-with-taints='os=windows:NoSchedule'`
|
||||
|
||||
By adding a taint to all Windows nodes, nothing will be scheduled on them (that includes existing Linux Pods).
|
||||
In order for a Windows Pod to be scheduled on a Windows node,
|
||||
it would need both the nodeSelector to choose Windows, and the appropriate matching toleration.
|
||||
it would need both the nodeSelector and the appropriate matching toleration to choose Windows.
|
||||
|
||||
```yaml
|
||||
nodeSelector:
|
||||
|
||||
@@ -163,7 +163,7 @@ Instructions to do so are available at [Install Docker Engine - Enterprise on Wi
|
||||
#### Install wins, kubelet, and kubeadm
|
||||
|
||||
```PowerShell
|
||||
curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/PrepareNode.ps1
|
||||
curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/kubeadm/scripts/PrepareNode.ps1
|
||||
.\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}}
|
||||
```
|
||||
|
||||
@@ -206,7 +206,7 @@ If you're using a different interface rather than Ethernet (i.e. "Ethernet0 2")
|
||||
#### Install wins, kubelet, and kubeadm
|
||||
|
||||
```PowerShell
|
||||
curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/PrepareNode.ps1
|
||||
curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/kubeadm/scripts/PrepareNode.ps1
|
||||
.\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}} -ContainerRuntime containerD
|
||||
```
|
||||
|
||||
|
||||
@@ -126,7 +126,18 @@ command. In that case, you should explicitly set `--certificate-renewal=true`.
|
||||
|
||||
You can renew your certificates manually at any time with the `kubeadm certs renew` command.
|
||||
|
||||
This command performs the renewal using CA (or front-proxy-CA) certificate and key stored in `/etc/kubernetes/pki`.
|
||||
This command performs the renewal using CA (or front-proxy-CA) certificate and key stored in `/etc/kubernetes/pki`.
|
||||
|
||||
After running the command you should restart the control plane Pods. This is required since
|
||||
dynamic certificate reload is currently not supported for all components and certificates.
|
||||
[Static Pods](/docs/tasks/configure-pod-container/static-pod/) are managed by the local kubelet
|
||||
and not by the API Server, thus kubectl cannot be used to delete and restart them.
|
||||
To restart a static Pod you can temporarily remove its manifest file from `/etc/kubernetes/manifests/`
|
||||
and wait for 20 seconds (see the `fileCheckFrequency` value in [KubeletConfiguration struct](/docs/
|
||||
reference/config-api/kubelet-config.v1beta1/).
|
||||
The kubelet will terminate the Pod if it's no longer in the manifest directory.
|
||||
You can then move the file back and after another `fileCheckFrequency` period, the kubelet will recreate
|
||||
the Pod and the certificate renewal for the component can complete.
|
||||
|
||||
{{< warning >}}
|
||||
If you are running an HA cluster, this command needs to be executed on all the control-plane nodes.
|
||||
|
||||
+39
-25
@@ -24,45 +24,59 @@ For background on Cilium, read the [Introduction to Cilium](https://docs.cilium.
|
||||
## Deploying Cilium on Minikube for Basic Testing
|
||||
|
||||
To get familiar with Cilium easily you can follow the
|
||||
[Cilium Kubernetes Getting Started Guide](https://docs.cilium.io/en/stable/gettingstarted/minikube/)
|
||||
[Cilium Kubernetes Getting Started Guide](https://docs.cilium.io/en/stable/gettingstarted/k8s-install-default/)
|
||||
to perform a basic DaemonSet installation of Cilium in minikube.
|
||||
|
||||
To start minikube, minimal version required is >= v1.3.1, run the with the
|
||||
To start minikube, minimal version required is >= v1.5.2, run the with the
|
||||
following arguments:
|
||||
|
||||
```shell
|
||||
minikube version
|
||||
```
|
||||
```
|
||||
minikube version: v1.3.1
|
||||
minikube version: v1.5.2
|
||||
```
|
||||
|
||||
```shell
|
||||
minikube start --network-plugin=cni --memory=4096
|
||||
minikube start --network-plugin=cni
|
||||
```
|
||||
|
||||
Mount the BPF filesystem:
|
||||
For minikube you can install Cilium using its CLI tool. Cilium will
|
||||
automatically detect the cluster configuration and will install the appropriate
|
||||
components for a successful installation:
|
||||
|
||||
```shell
|
||||
minikube ssh -- sudo mount bpffs -t bpf /sys/fs/bpf
|
||||
```
|
||||
|
||||
For minikube you can deploy this simple ''all-in-one'' YAML file that includes
|
||||
DaemonSet configurations for Cilium as well as appropriate RBAC settings:
|
||||
|
||||
```shell
|
||||
kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.8/install/kubernetes/quick-install.yaml
|
||||
curl -LO https://github.com/cilium/cilium-cli/releases/latest/download/cilium-linux-amd64.tar.gz
|
||||
sudo tar xzvfC cilium-linux-amd64.tar.gz /usr/local/bin
|
||||
rm cilium-linux-amd64.tar.gz
|
||||
cilium install
|
||||
```
|
||||
```
|
||||
configmap/cilium-config created
|
||||
serviceaccount/cilium created
|
||||
serviceaccount/cilium-operator created
|
||||
clusterrole.rbac.authorization.k8s.io/cilium created
|
||||
clusterrole.rbac.authorization.k8s.io/cilium-operator created
|
||||
clusterrolebinding.rbac.authorization.k8s.io/cilium created
|
||||
clusterrolebinding.rbac.authorization.k8s.io/cilium-operator created
|
||||
daemonset.apps/cilium create
|
||||
deployment.apps/cilium-operator created
|
||||
🔮 Auto-detected Kubernetes kind: minikube
|
||||
✨ Running "minikube" validation checks
|
||||
✅ Detected minikube version "1.20.0"
|
||||
ℹ️ Cilium version not set, using default version "v1.10.0"
|
||||
🔮 Auto-detected cluster name: minikube
|
||||
🔮 Auto-detected IPAM mode: cluster-pool
|
||||
🔮 Auto-detected datapath mode: tunnel
|
||||
🔑 Generating CA...
|
||||
2021/05/27 02:54:44 [INFO] generate received request
|
||||
2021/05/27 02:54:44 [INFO] received CSR
|
||||
2021/05/27 02:54:44 [INFO] generating key: ecdsa-256
|
||||
2021/05/27 02:54:44 [INFO] encoded CSR
|
||||
2021/05/27 02:54:44 [INFO] signed certificate with serial number 48713764918856674401136471229482703021230538642
|
||||
🔑 Generating certificates for Hubble...
|
||||
2021/05/27 02:54:44 [INFO] generate received request
|
||||
2021/05/27 02:54:44 [INFO] received CSR
|
||||
2021/05/27 02:54:44 [INFO] generating key: ecdsa-256
|
||||
2021/05/27 02:54:44 [INFO] encoded CSR
|
||||
2021/05/27 02:54:44 [INFO] signed certificate with serial number 3514109734025784310086389188421560613333279574
|
||||
🚀 Creating Service accounts...
|
||||
🚀 Creating Cluster roles...
|
||||
🚀 Creating ConfigMap...
|
||||
🚀 Creating Agent DaemonSet...
|
||||
🚀 Creating Operator Deployment...
|
||||
⌛ Waiting for Cilium to be installed...
|
||||
```
|
||||
|
||||
The remainder of the Getting Started Guide explains how to enforce both L3/L4
|
||||
@@ -85,14 +99,14 @@ Deploying a cluster with Cilium adds Pods to the `kube-system` namespace. To see
|
||||
this list of Pods run:
|
||||
|
||||
```shell
|
||||
kubectl get pods --namespace=kube-system
|
||||
kubectl get pods --namespace=kube-system -l k8s-app=cilium
|
||||
```
|
||||
|
||||
You'll see a list of Pods similar to this:
|
||||
|
||||
```console
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
cilium-6rxbd 1/1 Running 0 1m
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
cilium-kkdhz 1/1 Running 0 3m23s
|
||||
...
|
||||
```
|
||||
|
||||
|
||||
@@ -26,7 +26,7 @@ and provides recommendations on overall security.
|
||||
|
||||
## Controlling access to the Kubernetes API
|
||||
|
||||
As Kubernetes is entirely API driven, controlling and limiting who can access the cluster and what actions
|
||||
As Kubernetes is entirely API-driven, controlling and limiting who can access the cluster and what actions
|
||||
they are allowed to perform is the first line of defense.
|
||||
|
||||
### Use Transport Layer Security (TLS) for all API traffic
|
||||
@@ -40,7 +40,7 @@ potentially unsecured traffic.
|
||||
### API Authentication
|
||||
|
||||
Choose an authentication mechanism for the API servers to use that matches the common access patterns
|
||||
when you install a cluster. For instance, small single user clusters may wish to use a simple certificate
|
||||
when you install a cluster. For instance, small, single-user clusters may wish to use a simple certificate
|
||||
or static Bearer token approach. Larger clusters may wish to integrate an existing OIDC or LDAP server that
|
||||
allow users to be subdivided into groups.
|
||||
|
||||
@@ -54,7 +54,7 @@ Consult the [authentication reference document](/docs/reference/access-authn-aut
|
||||
Once authenticated, every API call is also expected to pass an authorization check. Kubernetes ships
|
||||
an integrated [Role-Based Access Control (RBAC)](/docs/reference/access-authn-authz/rbac/) component that matches an incoming user or group to a
|
||||
set of permissions bundled into roles. These permissions combine verbs (get, create, delete) with
|
||||
resources (pods, services, nodes) and can be namespace or cluster scoped. A set of out of the box
|
||||
resources (pods, services, nodes) and can be namespace-scoped or cluster-scoped. A set of out-of-the-box
|
||||
roles are provided that offer reasonable default separation of responsibility depending on what
|
||||
actions a client might want to perform. It is recommended that you use the
|
||||
[Node](/docs/reference/access-authn-authz/node/) and
|
||||
@@ -69,8 +69,8 @@ With authorization, it is important to understand how updates on one object may
|
||||
other places. For instance, a user may not be able to create pods directly, but allowing them to
|
||||
create a deployment, which creates pods on their behalf, will let them create those pods
|
||||
indirectly. Likewise, deleting a node from the API will result in the pods scheduled to that node
|
||||
being terminated and recreated on other nodes. The out of the box roles represent a balance
|
||||
between flexibility and the common use cases, but more limited roles should be carefully reviewed
|
||||
being terminated and recreated on other nodes. The out-of-the box roles represent a balance
|
||||
between flexibility and common use cases, but more limited roles should be carefully reviewed
|
||||
to prevent accidental escalation. You can make roles specific to your use case if the out-of-box ones don't meet your needs.
|
||||
|
||||
Consult the [authorization reference section](/docs/reference/access-authn-authz/authorization/) for more information.
|
||||
@@ -104,7 +104,7 @@ reserved resources like memory, or to provide default limits when none are speci
|
||||
### Controlling what privileges containers run with
|
||||
|
||||
A pod definition contains a [security context](/docs/tasks/configure-pod-container/security-context/)
|
||||
that allows it to request access to running as a specific Linux user on a node (like root),
|
||||
that allows it to request access to run as a specific Linux user on a node (like root),
|
||||
access to run privileged or access the host network, and other controls that would otherwise
|
||||
allow it to run unfettered on a hosting node. [Pod security policies](/docs/concepts/policy/pod-security-policy/)
|
||||
can limit which users or service accounts can provide dangerous security context settings. For example, pod security policies can limit volume mounts, especially `hostPath`, which are aspects of a pod that should be controlled.
|
||||
@@ -155,10 +155,10 @@ within their namespaces. Many of the supported [Kubernetes networking providers]
|
||||
now respect network policy.
|
||||
|
||||
Quota and limit ranges can also be used to control whether users may request node ports or
|
||||
load balanced services, which on many clusters can control whether those users applications
|
||||
load-balanced services, which on many clusters can control whether those users applications
|
||||
are visible outside of the cluster.
|
||||
|
||||
Additional protections may be available that control network rules on a per plugin or per
|
||||
Additional protections may be available that control network rules on a per-plugin or per-
|
||||
environment basis, such as per-node firewalls, physically separating cluster nodes to
|
||||
prevent cross talk, or advanced networking policy.
|
||||
|
||||
@@ -169,7 +169,7 @@ By default these APIs are accessible by pods running on an instance and can cont
|
||||
credentials for that node, or provisioning data such as kubelet credentials. These credentials
|
||||
can be used to escalate within the cluster or to other cloud services under the same account.
|
||||
|
||||
When running Kubernetes on a cloud platform limit permissions given to instance credentials, use
|
||||
When running Kubernetes on a cloud platform, limit permissions given to instance credentials, use
|
||||
[network policies](/docs/tasks/administer-cluster/declare-network-policy/) to restrict pod access
|
||||
to the metadata API, and avoid using provisioning data to deliver secrets.
|
||||
|
||||
@@ -177,7 +177,7 @@ to the metadata API, and avoid using provisioning data to deliver secrets.
|
||||
|
||||
By default, there are no restrictions on which nodes may run a pod. Kubernetes offers a
|
||||
[rich set of policies for controlling placement of pods onto nodes](/docs/concepts/scheduling-eviction/assign-pod-node/)
|
||||
and the [taint based pod placement and eviction](/docs/concepts/scheduling-eviction/taint-and-toleration/)
|
||||
and the [taint-based pod placement and eviction](/docs/concepts/scheduling-eviction/taint-and-toleration/)
|
||||
that are available to end users. For many clusters use of these policies to separate workloads
|
||||
can be a convention that authors adopt or enforce via tooling.
|
||||
|
||||
@@ -223,8 +223,9 @@ do not use.
|
||||
The shorter the lifetime of a secret or credential the harder it is for an attacker to make
|
||||
use of that credential. Set short lifetimes on certificates and automate their rotation. Use
|
||||
an authentication provider that can control how long issued tokens are available and use short
|
||||
lifetimes where possible. If you use service account tokens in external integrations, plan to
|
||||
rotate those tokens frequently. For example, once the bootstrap phase is complete, a bootstrap token used for setting up nodes should be revoked or its authorization removed.
|
||||
lifetimes where possible. If you use service-account tokens in external integrations, plan to
|
||||
rotate those tokens frequently. For example, once the bootstrap phase is complete, a bootstrap
|
||||
token used for setting up nodes should be revoked or its authorization removed.
|
||||
|
||||
### Review third party integrations before enabling them
|
||||
|
||||
@@ -246,7 +247,8 @@ and may grant an attacker significant visibility into the state of your cluster.
|
||||
your backups using a well reviewed backup and encryption solution, and consider using full disk
|
||||
encryption where possible.
|
||||
|
||||
Kubernetes supports [encryption at rest](/docs/tasks/administer-cluster/encrypt-data/), a feature introduced in 1.7, and beta since 1.13. This will encrypt `Secret` resources in etcd, preventing
|
||||
Kubernetes supports [encryption at rest](/docs/tasks/administer-cluster/encrypt-data/), a feature
|
||||
introduced in 1.7, and beta since 1.13. This will encrypt `Secret` resources in etcd, preventing
|
||||
parties that gain access to your etcd backups from viewing the content of those secrets. While
|
||||
this feature is currently beta, it offers an additional level of defense when backups
|
||||
are not encrypted or an attacker gains read access to etcd.
|
||||
|
||||
@@ -16,7 +16,7 @@ This document shares how to validate IPv4/IPv6 dual-stack enabled Kubernetes clu
|
||||
|
||||
|
||||
* Provider support for dual-stack networking (Cloud provider or otherwise must be able to provide Kubernetes nodes with routable IPv4/IPv6 network interfaces)
|
||||
* A [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) that supports dual-stack (such as Kubenet or Calico)
|
||||
* A [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) that supports dual-stack (such as Calico, Cilium or Kubenet)
|
||||
* [Dual-stack enabled](/docs/concepts/services-networking/dual-stack/) cluster
|
||||
|
||||
{{< version-check >}}
|
||||
|
||||
@@ -189,7 +189,7 @@ by making use of the `autoscaling/v2beta2` API version.
|
||||
First, get the YAML of your HorizontalPodAutoscaler in the `autoscaling/v2beta2` form:
|
||||
|
||||
```shell
|
||||
kubectl get hpa.v2beta2.autoscaling -o yaml > /tmp/hpa-v2.yaml
|
||||
kubectl get hpa php-apache -o yaml > /tmp/hpa-v2.yaml
|
||||
```
|
||||
|
||||
Open the `/tmp/hpa-v2.yaml` file in an editor, and you should see YAML which looks like this:
|
||||
|
||||
@@ -185,7 +185,7 @@ Below are the procedures to set up autocompletion for Bash and Zsh.
|
||||
|
||||
1. Validate the binary (optional)
|
||||
|
||||
Download the kubectl checksum file:
|
||||
Download the kubectl-convert checksum file:
|
||||
|
||||
{{< tabs name="download_convert_checksum_macos" >}}
|
||||
{{< tab name="Intel" codelang="bash" >}}
|
||||
|
||||
@@ -26,7 +26,7 @@ weight: 20
|
||||
<div class="row">
|
||||
<div class="col-md-12">
|
||||
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/" role="button">Home<span class=""></span></a>
|
||||
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/" role="button">Continue to Module 2 ><span class=""></span></a>
|
||||
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/" role="button">Continue to Module 2 ><span class=""></span></a>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
@@ -37,9 +37,9 @@ weight: 20
|
||||
</div>
|
||||
<div class="row">
|
||||
<div class="col-md-12">
|
||||
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro/" role="button"> < Return to Module 1<span class=""></span></a>
|
||||
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro/" role="button"> < Return to Module 1<span class=""></span></a>
|
||||
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/" role="button">Home<span class=""></span></a>
|
||||
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/explore/explore-intro/" role="button">Continue to Module 3 ><span class=""></span></a>
|
||||
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/explore/explore-intro/" role="button">Continue to Module 3 ><span class=""></span></a>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
@@ -29,9 +29,9 @@ weight: 20
|
||||
</div>
|
||||
<div class="row">
|
||||
<div class="col-md-12">
|
||||
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/" role="button">< Return to Module 2<span class="btn"></span></a>
|
||||
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/" role="button">< Return to Module 2<span class="btn"></span></a>
|
||||
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/" role="button">Home<span class=""></span></a>
|
||||
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/expose/expose-intro/" role="button">Continue to Module 4 ><span class="btn"></span></a>
|
||||
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/expose/expose-intro/" role="button">Continue to Module 4 ><span class="btn"></span></a>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
@@ -26,9 +26,9 @@ weight: 20
|
||||
</div>
|
||||
<div class="row">
|
||||
<div class="col-md-12">
|
||||
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/explore/explore-intro/" role="button">< Return to Module 3<span class=""></span></a>
|
||||
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/explore/explore-intro/" role="button">< Return to Module 3<span class=""></span></a>
|
||||
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/" role="button">Home<span class=""></span></a>
|
||||
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/scale/scale-intro/" role="button">Continue to Module 5 ><span class=""></span></a>
|
||||
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/scale/scale-intro/" role="button">Continue to Module 5 ><span class=""></span></a>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
@@ -26,9 +26,9 @@ weight: 20
|
||||
</div>
|
||||
<div class="row">
|
||||
<div class="col-md-12">
|
||||
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/expose/expose-interactive/" role="button">< Return to Module 4<span class=""></span></a>
|
||||
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/expose/expose-interactive/" role="button">< Return to Module 4<span class=""></span></a>
|
||||
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/" role="button">Home<span class=""></span></a>
|
||||
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/update/update-intro/" role="button">Continue to Module 6 ><span class=""></span></a>
|
||||
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/update/update-intro/" role="button">Continue to Module 6 ><span class=""></span></a>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
@@ -26,7 +26,7 @@ weight: 20
|
||||
</div>
|
||||
<div class="row">
|
||||
<div class="col-md-12">
|
||||
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/scale/scale-interactive/" role="button">< Return to Module 5<span class=""></span></a>
|
||||
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/scale/scale-interactive/" role="button">< Return to Module 5<span class=""></span></a>
|
||||
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/" role="button">Return to Kubernetes Basics<span class=""></span></a>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
Reference in New Issue
Block a user