diff --git a/calico/getting-started/kubernetes/quickstart.mdx b/calico/getting-started/kubernetes/quickstart.mdx index ae948b140a..f27cf3cf13 100644 --- a/calico/getting-started/kubernetes/quickstart.mdx +++ b/calico/getting-started/kubernetes/quickstart.mdx @@ -1,170 +1,482 @@ --- -description: Install Calico on a single-host Kubernetes cluster for testing or development in under 15 minutes. -title: "Tutorial: Quickstart on Kubernetes" +description: Quickstart for Calico. --- -# Quickstart for Calico on Kubernetes +import Screenshot from '/src/___new___/components/Screenshot'; +export let figCount = 1; -## Big picture +# Calico quickstart guide -This quickstart gets you a single-host Kubernetes cluster with $[prodname] in approximately 15 minutes. - -## Value - -Use this quickstart to quickly and easily try $[prodname] features. To deploy a cluster suitable for production, refer to [$[prodname] on Kubernetes](../index.mdx). +This quickstart guide shows you how to install Calico, secure a cluster with network policy, and monitor network traffic with Calico Whisker. ## Before you begin -**Required** +You'll need to install a few tools to complete this tutorial: + +* `kind`. + This is what you'll use to create a cluster on your workstation. + For installation instructions, see the [`kind` documentation](https://kind.sigs.k8s.io/docs/user/quick-start/). +* Docker Engine or Docker Desktop. + This is required to run containers for the `kind` utility. + For installation instructions, see the [Docker documentation](https://docs.docker.com/desktop/). +* `kubectl`. + This is the tool you'll use to interact with your cluster. + For installation instructions, see the [Kubernetes documentation](https://kubernetes.io/docs/tasks/tools/#kubectl) -- A Linux host that meets the following requirements: - - x86-64, arm64, ppc64le, or s390x processor - - 2CPU - - 2GB RAM - - 10GB free disk space - - RedHat Enterprise Linux 7.x+, CentOS 7.x+, Ubuntu 18.04+, or Debian 9.x+ +## Step 1: Create a cluster -- $[prodname] can manage `cali` and `tunl` interfaces on the host +In this step, you will: +* **Create a cluster:** Use `kind` to create a Kubernetes cluster. +* **Verify the cluster:** Check that the cluster is running and ready. - If NetworkManager is present on the host, see [Configure NetworkManager](../../operations/troubleshoot/troubleshooting.mdx#configure-networkmanager). +1. Create a file called `config.yaml` and give it the following content: -## Concepts + ```bash + kind: Cluster + apiVersion: kind.x-k8s.io/v1alpha4 + nodes: + - role: control-plane + - role: worker + - role: worker + networking: + disableDefaultCNI: true + podSubnet: 192.168.0.0/16 + ``` -### Operator based installation + This configuration file tells `kind` to create a cluster with one control-plane node and two worker nodes. + It instructs `kind` to create the cluster without a CNI. + The `podSubnet` range defines the IP addresses that Kubernetes will use for pods. -This quickstart guide uses the Tigera operator to install $[prodname]. The operator provides lifecycle management for Calico -exposed via the Kubernetes API defined as a custom resource definition. +2. Start your Kubernetes cluster with the configuration file by running the following command: -:::note + ```bash + kind create cluster --name=calico-cluster --config=config.yaml + ``` -It is also possible to install Calico without an operator using Kubernetes manifests directly. -For platforms and guides that do not use the Tigera operator, you may notice some differences in the steps and Kubernetes -resources compared to those presented in this guide. + `kind` reads your configuration file and creates a cluster in a few minutes. -::: + ```bash title='Expected output' + Creating cluster "calico-cluster" ... + ✓ Ensuring node image (kindest/node:v1.29.2) đŸ–ŧ + ✓ Preparing nodes đŸ“Ļ đŸ“Ļ đŸ“Ļ + ✓ Writing configuration 📜 + ✓ Starting control-plane đŸ•šī¸ + ✓ Installing StorageClass 💾 + ✓ Joining worker nodes 🚜 + Set kubectl context to "kind-calico-cluster" + You can now use your cluster with: -## How to + kubectl cluster-info --context kind-calico-cluster -The geeky details of what you get: + Thanks for using kind! 😊 + ``` - +3. To verify that your cluster is working, run the following command: -### Create a single-host Kubernetes cluster + ```bash + kubectl get nodes + ``` -1. [Follow the Kubernetes instructions to install kubeadm](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/) + You should see three nodes with the name you gave the cluster. - :::note + ```bash title="Expected output" + NAME STATUS ROLES AGE VERSION + calico-cluster-control-plane NotReady control-plane 5m46s v1.29.2 + calico-cluster-worker NotReady 5m23s v1.29.2 + calico-cluster-worker2 NotReady 5m22s v1.29.2 + ``` - After installing kubeadm, do not power down or restart - the host. Instead, continue directly to the next step. + Don't wait for the nodes to get a `Ready` status. + They remain in a `NotReady` status until you configure networking in the next step. - ::: +## Step 2. Install Calico -1. As a regular user with sudo privileges, open a terminal on the host that you installed kubeadm on. +In this step, you will install Calico in your cluster. -1. Initialize the control plane using the following command. +1. Install the Tigera operator and custom resource definitions. + ```bash + kubectl create -f $[manifestsUrl]/manifests/tigera-operator.yaml ``` - sudo kubeadm init --pod-network-cidr=192.168.0.0/16 + + ```bash title="Expected output" + namespace/tigera-operator created + serviceaccount/tigera-operator created + clusterrole.rbac.authorization.k8s.io/tigera-operator-secrets created + clusterrole.rbac.authorization.k8s.io/tigera-operator created + clusterrolebinding.rbac.authorization.k8s.io/tigera-operator created + rolebinding.rbac.authorization.k8s.io/tigera-operator-secrets created + deployment.apps/tigera-operator created ``` - :::note +2. Install $[prodname] by creating the necessary custom resources. - If 192.168.0.0/16 is already in use within your network you must select a different pod network - CIDR, replacing 192.168.0.0/16 in the above command. + ```bash + kubectl create -f $[manifestsUrl]/manifests/custom-resources.yaml + ``` - ::: + ```bash title="Expected output" + installation.operator.tigera.io/default created + apiserver.operator.tigera.io/default created + goldmane.operator.tigera.io/default created + whisker.operator.tigera.io/default created + ``` -1. Execute the following commands to configure kubectl (also returned by `kubeadm init`). +3. Monitor the deployment by running the following command: + ```bash + watch kubectl get tigerastatus ``` - mkdir -p $HOME/.kube - sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config - sudo chown $(id -u):$(id -g) $HOME/.kube/config + + After a few minutes, all the Calico components display `True` in the `AVAILABLE` column. + + ```bash title="Expected output" + NAME AVAILABLE PROGRESSING DEGRADED SINCE + apiserver True False False 4m9s + calico True False False 3m29s + goldmane True False False 3m39s + ippools True False False 6m4s + whisker True False False 3m19s ``` -### Install $[prodname] +## Step 3. Monitor network traffic in Calico Whisker -1. Install the Tigera operator and custom resource definitions. +The Whisker web console deploys automatically, but it is not accessible from outside the cluster by default. +To view the web console, you need to allow access. + +In this step, you will: + +* **Set up port forwarding:** This allows you to access the Whisker web console from your browser. +* **Open the Whisker web console:** View the network traffic logs in real time. +1. From your terminal, run the following command: + + ```bash + kubectl port-forward -n calico-system service/whisker 8081:8081 ``` - kubectl create -f $[manifestsUrl]/manifests/tigera-operator.yaml + + ```bash title="Expected output" + Forwarding from 127.0.0.1:8081 -> 8081 + Forwarding from [::1]:8081 -> 8081 ``` - :::note + Keep this terminal open throughout the rest of this tutorial. + The Whisker web console needs the port forwarding to be active to receive logs. + +2. To open Calico Whisker, open your browser and go to `localhost:8081`. + You won't see any flows at the beginning. + But in a few moments, as the console receives flow logs, you'll begin to see a list of connections. - Due to the large size of the CRD bundle, `kubectl apply` might exceed request limits. Instead, use `kubectl create` or `kubectl replace`. + + *Figure {figCount++}: Whisker web console with allowed flows for core Kubernetes services.* - ::: + The web console accumulates flow logs in real time. + Keep this window open through the rest of the tutorial to see logs of the connections your pods are making. -1. Install $[prodname] by creating the necessary custom resource. For more information on configuration options available in this manifest, see [the installation reference](../../reference/installation/api.mdx). +## Step 4. Deploy NGINX and BusyBox to generate traffic +Now it's time to generate some network traffic. +We'll do this first by deploying an NGINX server and exposing it as a service in the cluster. +Then we'll make HTTP requests from another pod in the cluster to the NGINX server and to an external website. +For this we'll use the BusyBox utility. + +In this step, you will: +* **Create a server:** Deploy an NGINX web server in your Kubernetes cluster. +* **Expose the server:** Make the NGINX server accessible within the cluster. +* **Test connectivity:** Use a BusyBox pod to verify connections to the NGINX server and the public internet. + +1. Create a namespace for your application: + + ```bash + kubectl create namespace quickstart ``` - kubectl create -f $[manifestsUrl]/manifests/custom-resources.yaml + ```bash title="Expected output" + namespace/quickstart created ``` - :::note +1. Deploy an NGINX web server in the `quickstart` namespace: - Before creating this manifest, read its contents and make sure its settings are correct for your environment. For example, - you may need to change the default IP pool CIDR to match your pod network CIDR. - - ::: + ```bash + kubectl create deployment --namespace=quickstart nginx --image=nginx + ``` + ```bash title="Expected output" + deployment.apps/nginx created + ``` -1. Confirm that all of the pods are running with the following command. +1. Expose the NGINX deployment to make it accessible within the cluster: + ```bash + kubectl expose --namespace=quickstart deployment nginx --port=80 ``` - watch kubectl get pods -n calico-system + ```bash title="Expected output" + service/nginx exposed ``` - Wait until each pod has the `STATUS` of `Running`. +1. Start a BusyBox session to test whether you can access the NGINX server. - :::note + ```bash + kubectl run --namespace=quickstart access --rm -ti --image busybox /bin/sh + ``` - The Tigera operator installs resources in the `calico-system` namespace. Other install methods may use - the `kube-system` namespace instead. + This command creates a BusyBox pod inside the `quickstart` namespace and starts a shell session inside the pod. - ::: + ```bash title="Expected output" + If you don't see a command prompt, try pressing enter. + / # + ``` -1. Remove the taints on the control plane so that you can schedule pods on it. +1. In the BusyBox shell, run the following command to test communication with the NGINX server: ```bash - kubectl taint nodes --all node-role.kubernetes.io/control-plane- + wget -qO- http://nginx + ``` + + You should see the HTML content of the NGINX welcome page. + + ```html title="Expected output" + + + + Welcome to nginx! + + + +

Welcome to nginx!

+

If you see this page, the nginx web server is successfully installed and + working. Further configuration is required.

+ +

For online documentation and support please refer to + nginx.org.
+ Commercial support is available at + nginx.com.

+ +

Thank you for using nginx.

+ + ``` + This confirms that the BusyBox pod can access the NGINX server. + +1. In the Busybox shell, run the following command test communication with the public internet: + + ```bash + wget -qO- https://docs.tigera.io/pod-connection-test.txt + ``` + + You should see the content of the file `pod-connectivity-test.txt`. + + ```html title="Expected output" + You successfully connected to https://docs.tigera.io/pod-connection-test.txt. + ``` + + This confirms that the BusyBox pod can access the public internet. + + +1. Return to your browser to see the connection appear in the Whisker web console. + You should see three new connection types: one to `coredns` one to `nginx`, and another to `PUBLIC NETWORK`. - It should return the following. + + *Figure {figCount++}: Whisker web console showing allowed flows to NGINX server and `https://docs.tigera.io`.* + +## Step 5. Restrict all traffic with a default deny policy + +To effectively secure your cluster, it's best to start by denying all traffic, and then gradually allowing only the necessary traffic. +We'll do this by applying a Global Calico Network Policy that denies all ingress and egress traffic by default. + +In this step, you will: +* **Implement a global default deny policy:** Use a Global Calico Network Policy to deny all ingress and egress traffic by default. +* **Verify access is denied:** Use your BusyBox pod to confirm that the policy is working as expected. + +1. Create a Global Calico Network Policy to deny all traffic except for the necessary system namespaces: + + ```bash + kubectl create -f - < untainted + ```bash title="Expected output" + globalnetworkpolicy.projectcalico.org/default-deny created ``` -1. Confirm that you now have a node in your cluster with the following command. +1. Now go back to your BusyBox shell and test access to the NGINX server again: + ```bash + wget -qO- http://nginx ``` - kubectl get nodes -o wide + + You should see the following output, indicating that access is denied: + + ```bash title="Expected output" + wget: bad address 'nginx' ``` - It should return something like the following. +1. Test access to the public internet again: + ```bash + wget -qO- https://docs.tigera.io/pod-connection-test.txt ``` - NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME - Ready master 52m v1.12.2 10.128.0.28 Ubuntu 18.04.1 LTS 4.15.0-1023-gcp docker://18.6.1 + + You should see the following output, indicating that egress traffic is also denied: + + ```bash title="Expected output" + wget: bad address 'docs.tigera.io' ``` -Congratulations! You now have a single-host Kubernetes cluster with $[prodname]. +1. Return to your browser to see the denied flow logs appear in the Whisker web console. + You should see two denied flows to `coredns`. + + + *Figure {figCount++}: Whisker web console showing denied flows to NGINX server and `https://docs.tigera.io`.* + + + By following these steps, you have successfully implemented a global default deny policy and verified that it is working as expected. + +## Step 6. Create targeted network policy for allowed traffic + +Now that you have a default deny policy in place, you need to create specific policies to allow only the necessary traffic for your applications to function. +The `default-deny` policy blocks all ingress and egress traffic for pods not in system namespaces, including our `access` (BusyBox) and `nginx` pods in the `quickstart` namespace. + +In this step, you will: +* **Allow egress traffic from BusyBox** Create a network policy to allow egress traffic from the BusyBox pod to the public internet. +* **Allow ingress traffic to NGINX** Create a network policy to allow ingress traffic to the NGINX server. + +1. Create a Calico network policy in the `quickstart` namespace that selects the `access` pod and allows all egress traffic from it. -## Next steps + ```bash + kubectl create -f - < + + + Welcome to nginx! + + + +

Welcome to nginx!

+

If you see this page, the nginx web server is successfully installed and + working. Further configuration is required.

+ +

For online documentation and support please refer to + nginx.org.
+ Commercial support is available at + nginx.com.

+ +

Thank you for using nginx.

+ + + ``` + +You have now successfully implemented a default deny policy and then created targeted allow policies to restore connectivity only for your applications. + +## Step 7. Clean up + +* To remove the `kind` cluster, run the following command: + + ```bash + kind delete cluster --name calico-cluster + ``` + + ```bash title="Expected output" + Deleting cluster "calico-cluster" ... + Deleted nodes: ["calico-cluster-control-plane" "calico-cluster-worker2" "calico-cluster-worker"] + ``` + +## Additional resources + +* TBD -- [Secure a simple application using the Kubernetes NetworkPolicy API](../../network-policy/get-started/kubernetes-policy/kubernetes-policy-basic.mdx) -- [Control ingress and egress traffic using the Kubernetes NetworkPolicy API](../../network-policy/get-started/kubernetes-policy/kubernetes-policy-advanced.mdx) -- [Run a tutorial that shows blocked and allowed connections in real time](../../network-policy/get-started/kubernetes-policy/kubernetes-demo.mdx) -- [Hands-on workshop: Learn the basics of Calico, and Kubernetes.](https://www.tigera.io/tutorials/?_sf_s=Calico%20Basics) diff --git a/calico/variables.js b/calico/variables.js index 7d86ac6f38..f6216bee5f 100644 --- a/calico/variables.js +++ b/calico/variables.js @@ -17,7 +17,7 @@ const variables = { noderunning: 'calico-node', rootDirWindows: 'C:\\CalicoWindows', ppa_repo_name: 'calico-master', - manifestsUrl: 'https://raw.githubusercontent.com/projectcalico/calico/master', + manifestsUrl: 'https://2025-04-16-v3-30-rehydrate.docs.eng.tigera.net', //Replace with hashrelease releases, registry: '', vppbranch: 'master', diff --git a/static/img/quickstart-whisker1.png b/static/img/quickstart-whisker1.png new file mode 100644 index 0000000000..bcd5016d33 Binary files /dev/null and b/static/img/quickstart-whisker1.png differ diff --git a/static/img/quickstart-whisker2.png b/static/img/quickstart-whisker2.png new file mode 100644 index 0000000000..26397f3b38 Binary files /dev/null and b/static/img/quickstart-whisker2.png differ diff --git a/static/img/quickstart-whisker3.png b/static/img/quickstart-whisker3.png new file mode 100644 index 0000000000..3263384aa4 Binary files /dev/null and b/static/img/quickstart-whisker3.png differ diff --git a/static/img/whisker.jpg b/static/img/whisker.jpg new file mode 100644 index 0000000000..1efc3abf8d Binary files /dev/null and b/static/img/whisker.jpg differ