You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: 20250401-kubecon-london/workshop/00-prerequisites/README.md
+13-10Lines changed: 13 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,11 +9,11 @@ In this chapter we'll set up our workshop-dedicated development environment.
9
9
10
10
Start by cloning the git repository we'll refer to throughout the workshop, and will be the place for the binaries, scripts and kubeconfigs we will create as we move forward.
11
11
12
-
Important: We will need 4 terminal windows for long running programs & interactions to the same underlaying machine during this workshop.
12
+
**Important:** We will need 4 terminal windows for long running programs & interactions to the same underlying machine during this workshop.
Notice the exercises in directories `<Sequence number>-<Exercise name>`. These are to be visited in sequence, and to complete one, all previous exercises need to be completed first to bring the system into the desired state. While it's best if you try to follow the tasks by yourself, if you ever get stuck, you can finish an exercise by running the scripts inside the respective exercise directory.
27
+
Notice the exercises in directories `<Sequence number>-<Exercise name>`. These are the rules:
28
28
29
-
Also take a note of the `clean-all.sh` script. If you ever get stuck and want to reset, run it and it will clean up and stop processes and containers used in the exercises.
29
+
1. exercises need to be visited in sequence. To complete one, all previous exercises need to be completed first.
30
+
2. Are you stuck? While it's best if you try to follow the tasks by yourself, if you ever get stuck, you can finish an exercise by running the scripts inside the respective exercise directory.
31
+
3. Something broke? If you ever need to reset, run `clean-all.sh` to clean up.
32
+
4. Finished an exercise? High-five! Each exercise directory has a script `99-highfive.sh`. Run it to check-in your progress!
30
33
31
34
## Get your bins
32
35
33
-
This one is easy. During the workshop we will make use of these programs:
36
+
Ready for a warm-up? In this quick exercise we are going to install programs we'll be using:
You may visit the links, download and extract the respective binaries to a new directory called `bin/` in the workshop's root (e.g., `$WORKSHOP/bin/kubectl`). If you already have some of these installed and available in your `$PATH`, you may skip them--just make sure they are up-to-date.
43
-
44
-
Alternatively, we've prepared a script that does just that:
45
+
Install them all in one go by running the following script:
45
46
46
47
```shell
47
48
00-prerequisites/01-install.sh
48
49
```
49
50
50
-
If you're going the manual way, please make sure the file names are stripped of OS and arch names they may contain (e.g. `mv kubectl-krew-linux_amd64 kubectl-krew`), as we'll refer to them using their system-agnostic names later on.
51
+
Inspect it first, and you'll see that it `curl`s files from the GitHub releases of the respective project repositories, and stores them in `bin/`, inside our current working directory.
52
+
53
+
Alternatively, you may install the binaries manually. If you already have some of them installed and available in your `$PATH`, you may skip them--just make sure they are up-to-date. If you choose to go the manual way, please make sure the file names are stripped of any OS and arch names they may contain (e.g. `mv kubectl-krew-linux_amd64 kubectl-krew`), as we'll refer to them using their system-agnostic names later on.
Copy file name to clipboardExpand all lines: 20250401-kubecon-london/workshop/01-deploy-kcp/README.md
+9-7Lines changed: 9 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -24,8 +24,8 @@ kcp may be deployed via a [Helm chart](https://github.com/kcp-dev/helm-charts),
24
24
=== "Fish"
25
25
26
26
```fish
27
-
set WORKSHOP_ROOT (git rev-parse --show-toplevel)/20250401-kubecon-london/workshop
28
-
set PATH $WORKSHOP_ROOT/bin $PATH
27
+
set -gx WORKSHOP_ROOT (git rev-parse --show-toplevel)/20250401-kubecon-london/workshop
28
+
set -gx PATH $WORKSHOP_ROOT/bin $PATH
29
29
```
30
30
31
31
Starting kcp in standalone mode is as easy as typing `kcp start` and pressing Enter.
@@ -34,27 +34,28 @@ Starting kcp in standalone mode is as easy as typing `kcp start` and pressing En
34
34
cd$WORKSHOP_ROOT&& kcp start
35
35
```
36
36
37
-
38
37
You should see the program running indefinitely, and outputting its logs--starting with some errors that should clean up in a couple of seconds as the different controllers start up. Leave the terminal window open, as we will keep using this kcp instance throughout the duration of the workshop. In this mode, all kcp's state is in-memory only. That means exiting the process (by, for example, pressing _Ctrl+C_ in this terminal), will lose all its etcd contents.
39
38
40
39
Once kcp's output seems stable, we can start making simple kubectl calls against it. `kcp start` creates a hidden directory `.kcp`, where it places its kubeconfig and the certificates.
41
40
42
-
Open a new terminal (termianl 2, same 01-deploy-kcp directory) now.
43
-
44
41
!!! Important
45
42
43
+
Open a **second shell** and `cd` into workshop's directory now.
Copy file name to clipboardExpand all lines: 20250401-kubecon-london/workshop/02-explore-workspaces/README.md
+10-10Lines changed: 10 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -82,9 +82,7 @@ kubectl ws use :
82
82
kubectl get ws
83
83
```
84
84
85
-
These are the workspaces we created, and they represent logical separation of resources in the cluster.
86
-
87
-
We haven't seen `ws use` yet. Using this command, you move into a different workspace in the tree of workspaces, much like `cd` moves you into a different directory described by a path. In case of workspaces, a path too may be relative or absolute, where `:` is the path separator, and `:` alone denotes the root of the tree.
85
+
We haven't seen `ws use` yet. Using this command you move into a different workspace in the tree of workspaces, much like `cd` moves you into a different directory described by a path. In the case of workspaces, a path too may be relative or absolute, where `:` is the path separator, and `:` alone denotes the root of the tree.
88
86
89
87
```shell
90
88
kubectl ws use :
@@ -101,7 +99,7 @@ kubectl create configmap test --from-literal=test=two
101
99
kubectl get configmap test -o json
102
100
```
103
101
104
-
Notice how even though these two ConfigMaps have the same name `test`, and are in the same namespace `default`, they are actually two distinct objects. They live in two different workspaces, and are completely separate.
102
+
Notice how even though these two ConfigMaps have the same name `test`, and are in the same namespace `default`, they are actually two distinct objects. They live in two different workspaces, and are completely separate.**Workspaces represent logical separation of resources in the cluster.**
105
103
106
104
We've created a few workspaces now, and already it's easy to lose sight of what is where. Say hello to `ws tree`:
107
105
@@ -169,16 +167,18 @@ Starting with the first one, `APIResourceSchema`:
169
167
kubectl get apiresourceschema -o json
170
168
```
171
169
172
-
Try to skim through the YAML output and you'll notice that it is almost identical to a definition of a CRD. Unlinke a CRD however, `APIResourceSchema` instance does not have a backing API server, and instead it simply describes an API that we can pass around and refer to. By decoupling the schema definition from serving, API owners can be more explicit about API evolution.
170
+
Try to skim through the YAML output and you'll notice that it is almost identical to a definition of a CRD. Unlike a CRD however, `APIResourceSchema` instance does not have a backing API server, and instead it simply describes an API that we can pass around and refer to. By decoupling the schema definition from serving, API owners can be more explicit about API evolution.
173
171
174
172
```shell
175
173
kubectl get apiexport cowboys -o yaml
176
174
```
177
175
178
176
Take a note of the following properties in the output:
179
-
*`.spec.latestResourceSchemas`: refers to specific versions of `APIResourceSchema` objects,
177
+
178
+
*`.spec.latestResourceSchemas`: lists which APIResourceSchemas we are exporting,
180
179
*`.spec.permissionClaims`: describes resource permissions that our API depends on. These are the permissions that we, the service provider, want the consumer to grant us,
181
-
*`.status.virtualWorkspaces[].url`: the URL where the provider can access the granted resources.
180
+
*`.status.virtualWorkspaces[].url`: a Kubernetes endpoint to access all resources that belong to this export, across all consumers.
181
+
182
182
```yaml
183
183
# Stripped down example output of `kubectl get apiexport` command above.
184
184
spec:
@@ -195,7 +195,7 @@ status:
195
195
196
196
### Service consumer
197
197
198
-
With the provider in place, let's create two consumers in their own workspaces, starting with "wild-west":
198
+
With the provider in place, let's shift into the role of a consumer. Actually, two consumers, in their own workspaces! Let's start with the first one, named "wild-west":
0 commit comments