Git-Mirrors/constellation
1
0
Fork 0
mirror of https://github.com/edgelesssys/constellation.git synced 2024-10-01 01:36:09 -04:00
Code Issues Packages Projects Releases Wiki Activity

docs: refer to apply command instead of init or upgrade apply (#2487)

Browse Source 
Signed-off-by: Daniel Weiße <dw@edgeless.systems>
This commit is contained in:
Daniel Weiße 2023-10-27 08:30:59 +02:00 committed by GitHub
parent fff35bdb2a
commit f4bfbe3564
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
18 changed files with 49 additions and 40 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
debugd/README.md
View File

@ -5,7 +5,7 @@ The debugd gets embedded into OS images at the place where the bootstrapper norm
Therefore, when a debug image is started, the debugd starts executing instead of the bootstrapper.
The debugd will then wait for a request from the `cdbg` tool to upload a bootstrapper binary.
Once the upload is finished debugd will start the bootstrapper.
Subsequently you can initialize your cluster with `constellation init` as usual.
Subsequently you can initialize your cluster with `constellation apply` as usual.
## Build cdbg
@ -45,7 +45,7 @@ With `cdbg` and `yq` installed in your path:
By default, `cdbg` searches for the bootstrapper in the current path (`./bootstrapper`). You can define a custom path by appending the argument `--bootstrapper <path to bootstrapper>` to `cdbg deploy`.
6. Run `constellation init […]` as usual
6. Run `constellation apply […]` as usual
### Logcollection to Opensearch

2
dev-docs/workflows/debug-cluster.md
View File

@ -45,7 +45,7 @@ Create the cluster and deploy the debug images:
Finally run:
```sh
./constellation init
./constellation apply
```
## Access bootstrapper logs

2
dev-docs/workflows/release.md
View File

@ -62,7 +62,7 @@ Releases should be performed using [the automated release pipeline](https://gith
./constellation upgrade check --update-config
yq eval -i '.image="vX.YY.Z"' constellation-conf.yaml
./constellation config fetch-measurements
./constellation upgrade apply --yes --debug
./constellation apply --yes --debug
```
Then wait until the node / Kubernetes upgrades are finished by periodically checking:

8
dev-docs/workflows/versions-support.md
View File

@ -4,20 +4,20 @@ This explains the support and compatibility of the different versions that are p
## Microservice version
(the version that is referenced in the config during constellation init or referenced as target version during upgrade apply) must match the CLI version exactly (down to the version suffix). When planning an upgrade, the source version (current version before the upgrade is applied) may be up to one minor version older (allow upgrades from v2.8.x to v2.9.x).
(the version that is referenced in the config during `constellation apply`) must match the CLI version exactly (down to the version suffix). When planning an upgrade, the source version (current version before the upgrade is applied) may be up to one minor version older (allow upgrades from v2.8.x to v2.9.x).
The reason is this: The CLI embeds exactly one version of the helm charts (the version of the CLI). So whenever we deploy the helm charts, we can only use the embedded chart version.
The source version can only be older by one minor version to ensure we can perform safe upgrades where we can reasonably test what microservice versions will interact with other versions of CLI, OS images, other microservices.
## Kubernetes version
(the version that is referenced in the config during constellation init or referenced as target version during upgrade apply) must match one of the embedded k8s versions. We have a hardcoded list that is embedded in the CLI.
(the version that is referenced in the config during `constellation apply`) must match one of the embedded k8s versions. We have a hardcoded list that is embedded in the CLI.
When planning an upgrade, the source k8s version may be up to one minor version older (allow upgrades from k8s 1.25.x to 1.26.x).
The reason is this: The CLI embeds components for kubernetes version for the hardcoded list of supported k8s versions. So whenever we deploy a k8s version (during constellation init or constellation upgrade apply), the k8s components for the target version need to be available.
The reason is this: The CLI embeds components for kubernetes version for the hardcoded list of supported k8s versions. So whenever we deploy a k8s version (during `constellation apply`), the k8s components for the target version need to be available.
The source version drift is a general k8s recommendation: k8s was designed to withstand a version drift of one minor version in each component during a rolling upgrade.
## Image version
(the version that is referenced in the config during constellation init or referenced as target version during upgrade apply) must have the same major and minor version (but can have a different patch or suffix) when upgrading compared to the cli. Examples: CLI v2.8.2 could correctly upgrade to OS image v2.8.1 or v2.8.2-nightly-foo-bar.
(the version that is referenced in the config during `constellation apply`) must have the same major and minor version (but can have a different patch or suffix) when upgrading compared to the cli. Examples: CLI v2.8.2 could correctly upgrade to OS image v2.8.1 or v2.8.2-nightly-foo-bar.
When planning an upgrade, the source image version may be up to one minor version older (allow upgrades from v2.8.x to 2.9.x).
The reason is this: The CLI uses an API endpoint to query configuration and measurements for a configured target image. This generally allows for arbitrary image versions to be referenced/deployed by the CLI. However, to ensure safe upgrades, we always upgrade by at most one minor version and ensure that the CLI is at the same minor version that we target.
This allows us to test upgrades with only a reasonable amount of moving parts.

2
docs/docs/architecture/attestation.md
View File

@ -90,7 +90,7 @@ Any changes to the image will inevitably also change the measured boot's PCR val
To create a node attestation statement, the Constellation image obtains a CVM attestation statement from the hardware.
This includes the runtime measurements and thereby binds the measured boot results to the CVM hardware measurement.
In addition to the image measurements, Constellation extends a PCR during the [initialization phase](../workflows/create.md#the-init-step) that irrevocably marks the node as initialized.
In addition to the image measurements, Constellation extends a PCR during the [initialization phase](../workflows/create.md#the-apply-step) that irrevocably marks the node as initialized.
The measurement is created using the [*clusterID*](../architecture/keys.md#cluster-identity), tying all future attestation statements to this ID.
Thereby, an attestation statement is unique for every cluster and a node can be identified unambiguously as being initialized.

2
docs/docs/architecture/orchestration.md
View File

@ -36,7 +36,7 @@ In addition, the cluster's [identifier](orchestration.md#post-installation-confi
2. Each CVM boots the Constellation node image and measures every component in the boot chain
3. The first microservice launched in each node is the [*Bootstrapper*](microservices.md#bootstrapper)
4. The *Bootstrapper* waits until it either receives an initialization request or discovers an initialized cluster
5. The CLI `init` command connects to the *Bootstrapper* of a selected node, sends the configuration, and initiates the initialization of the cluster
5. The CLI `apply` command connects to the *Bootstrapper* of a selected node, sends the configuration, and initiates the initialization of the cluster
6. The *Bootstrapper* of **that** node [initializes the Kubernetes cluster](microservices.md#bootstrapper) and deploys the other Constellation [microservices](microservices.md) including the [*JoinService*](microservices.md#joinservice)
7. Subsequently, the *Bootstrappers* of the other nodes discover the initialized cluster and send join requests to the *JoinService*
8. As part of the join request each node includes an attestation statement of its boot measurements as authentication

11
docs/docs/getting-started/first-steps-local.md
View File

@ -116,16 +116,17 @@ attaching persistent storage, or autoscaling aren't available.
3. Initialize the cluster
```bash
constellation init
constellation apply
```
This should give the following output:
```shell-session
$ constellation init
$ constellation apply
Your Constellation master secret was successfully written to ./constellation-mastersecret.json
Note: If you just created the cluster, it can take a few minutes to connect.
Initializing cluster ...
Connecting
Initializing cluster
Installing Kubernetes components
Your Constellation cluster was successfully initialized.
Constellation cluster identifier g6iMP5wRU1b7mpOz2WEISlIYSfdAhB0oNaOg6XEwKFY=
@ -141,7 +142,7 @@ attaching persistent storage, or autoscaling aren't available.
:::info
Depending on your setup, `constellation init` may take 10+ minutes to complete.
Depending on your setup, `constellation apply` may take 10+ minutes to complete.
:::

11
docs/docs/getting-started/first-steps.md
View File

@ -141,16 +141,17 @@ If you encounter any problem with the following steps, make sure to use the [lat
4. Initialize the cluster.
```bash
constellation init
constellation apply
```
This should give the following output:
```shell-session
$ constellation init
$ constellation apply
Your Constellation master secret was successfully written to ./constellation-mastersecret.json
Note: If you just created the cluster, it can take a few minutes to connect.
Initializing cluster ...
Connecting
Initializing cluster
Installing Kubernetes components
Your Constellation cluster was successfully initialized.
Constellation cluster identifier g6iMP5wRU1b7mpOz2WEISlIYSfdAhB0oNaOg6XEwKFY=
@ -166,7 +167,7 @@ If you encounter any problem with the following steps, make sure to use the [lat
:::info
Depending on your CSP and region, `constellation init` may take 10+ minutes to complete.
Depending on your CSP and region, `constellation apply` may take 10+ minutes to complete.
:::

10
docs/docs/workflows/create.md
View File

@ -171,7 +171,7 @@ terraform init
terraform apply
```
The Constellation [init step](#the-init-step) requires the already created `constellation-config.yaml` and the `constellation-state.yaml`.
The Constellation [apply step](#the-apply-step) requires the already created `constellation-config.yaml` and the `constellation-state.yaml`.
Create the `constellation-state.yaml` using the output from the Terraform state and the `constellation-conf.yaml`:
```bash
@ -199,12 +199,12 @@ Continue with [initializing your cluster](#the-init-step).
</tabItem>
</tabs>
## The *init* step
## The *apply* step
The following command initializes and bootstraps your cluster:
```bash
constellation init
constellation apply
```
Next, configure `kubectl` for your cluster:
@ -215,6 +215,6 @@ export KUBECONFIG="$PWD/constellation-admin.conf"
🏁 That's it. You've successfully created a Constellation cluster.
### Troubleshooting
In case `init` fails, the CLI collects logs from the bootstrapping instance and stores them inside `constellation-cluster.log`.
In case `apply` fails, the CLI collects logs from the bootstrapping instance and stores them inside `constellation-cluster.log`.

2
docs/docs/workflows/terminate.md
View File

@ -31,7 +31,7 @@ constellation terminate --yes
```
This deletes all resources created by Constellation in your cloud environment.
All local files created by the `create` and `init` commands are deleted as well, except for `constellation-mastersecret.json` and the configuration file.
All local files created by the `create` and `apply` commands are deleted as well, except for `constellation-mastersecret.json` and the configuration file.
:::caution

6
docs/docs/workflows/troubleshooting.md
View File

@ -65,12 +65,12 @@ kubectl patch configmaps -n kube-system join-config -p "{\"data\":{\"attestation
:::
You can use the `upgrade apply` command to change measurements of a running cluster:
You can use the `apply` command to change measurements of a running cluster:
1. Modify the `measurements` key in your local `constellation-conf.yaml` to the expected values.
2. Run `constellation upgrade apply`.
2. Run `constellation apply`.
Keep in mind that running `upgrade apply` also applies any version changes from your config to the cluster.
Keep in mind that running `apply` also applies any version changes from your config to the cluster.
You can run these commands to learn about the versions currently configured in the cluster:

6
docs/docs/workflows/upgrade.md
View File

@ -2,7 +2,7 @@
Constellation provides an easy way to upgrade all components of your cluster, without disrupting it's availability.
Specifically, you can upgrade the Kubernetes version, the nodes' image, and the Constellation microservices.
You configure the desired versions in your local Constellation configuration and trigger upgrades with the `upgrade apply` command.
You configure the desired versions in your local Constellation configuration and trigger upgrades with the `apply` command.
To learn about available versions you use the `upgrade check` command.
Which versions are available depends on the CLI version you are using.
@ -48,7 +48,7 @@ When using this flag, the `kubernetesVersion`, `image`, `microserviceVersion`, a
Once you updated your config with the desired versions, you can trigger the upgrade with this command:
```bash
constellation upgrade apply
constellation apply
```
Microservice upgrades will be finished within a few minutes, depending on the cluster size.
@ -73,7 +73,7 @@ The phases are `infrastracture` for the cloud resource management through Terraf
## Check the status
Upgrades are asynchronous operations.
After you run `upgrade apply`, it will take a while until the upgrade has completed.
After you run `apply`, it will take a while until the upgrade has completed.
To understand if an upgrade is finished, you can run:
```bash

2
docs/docs/workflows/verify-cluster.md
View File

@ -65,7 +65,7 @@ If attestation fails for a new node, it isn't permitted to join the cluster.
## The *verify* command
:::note
The steps below are purely optional. They're automatically executed by `constellation init` when you initialize your cluster. The `constellation verify` command mostly has an illustrative purpose.
The steps below are purely optional. They're automatically executed by `constellation apply` when you initialize your cluster. The `constellation verify` command mostly has an illustrative purpose.
:::
The `verify` command obtains and verifies an attestation statement from a running Constellation cluster.

2
docs/screencasts/docker/create-cluster.expect
View File

@ -33,7 +33,7 @@ expect_prompt
run_command "# Step 2: Initialize Constellation"
expect_prompt
run_command "constellation init"
run_command "constellation apply"
expect_prompt
run_command "# Wait for cluster to finish bootstrapping..."

2
docs/screencasts/docker/github-readme.expect
View File

@ -29,7 +29,7 @@ send "y"
send "\r"
expect_prompt
run_command "constellation init"
run_command "constellation apply"
expect_prompt
run_command "export KUBECONFIG=/constellation/constellation-admin.conf"

2
e2e/internal/upgrade/upgrade.go
View File

@ -4,7 +4,7 @@ Copyright (c) Edgeless Systems GmbH
SPDX-License-Identifier: AGPL-3.0-only
*/
// Package upgrade tests that the CLI's upgrade apply command works as expected and
// Package upgrade tests that the CLI's apply command works as expected and
// the operators eventually upgrade all nodes inside the cluster.
// The test is written as a go test because:
// 1. the helm cli does not directly provide the chart version of a release

2
internal/kms/README.md
View File

@ -12,7 +12,7 @@ We differentiate between two cases:
* cluster KMS (cKMS):
The Constellation cluster itself holds the master secret (KEK) and manages key derivation.
The KEK is generated by an admin on `constellation init`.
The KEK is generated by an admin on `constellation apply`.
Once send to the cluster, the KEK never leaves the confidential computing context.
As keys are only derived on demand, no DEK is ever persisted to memory by the cKMS.

13
operators/constellation-node-operator/README.md
View File

@ -5,7 +5,7 @@ In particular, it is responsible for updating the OS images of nodes by replacin
## High level goals
- Admin or `constellation init` can create custom resources for node related components
- Admin or `constellation apply` can create custom resources for node related components
- The operator will manage nodes in the cluster by trying to ensure every node has the specified image
- If a node uses an outdated image, it will be replaced by a new node
- Admin can update the specified image at any point in time which will trigger a rolling upgrade through the cluster
@ -20,6 +20,7 @@ The operator has multiple controllers with corresponding custom resource definit
`NodeVersion` is the only user controlled CRD. The spec allows an administrator to update the desired image and trigger a rolling update.
Example for GCP:
```yaml
apiVersion: update.edgeless.systems/v1alpha1
kind: NodeVersion
@ -30,6 +31,7 @@ spec:
```
Example for Azure:
```yaml
apiVersion: update.edgeless.systems/v1alpha1
kind: NodeVersion
@ -39,7 +41,6 @@ spec:
image: "/subscriptions/<subscription-id>/resourceGroups/CONSTELLATION-IMAGES/providers/Microsoft.Compute/galleries/Constellation/images/<image-definition-name>/versions/<image-version>"
```
### AutoscalingStrategy
`AutoscalingStrategy` is used and modified by the `NodeVersion` controller to pause the `cluster-autoscaler` while an image update is in progress.
@ -124,12 +125,13 @@ spec:
deadline: "2022-07-04T08:33:18+00:00"
```
## Getting Started
You’ll need a Kubernetes cluster to run against. You can use [KIND](https://sigs.k8s.io/kind) to get a local cluster for testing, or run against a remote cluster.
**Note:** Your controller will automatically use the current context in your kubeconfig file (i.e. whatever cluster `kubectl cluster-info` shows).
### Running on the cluster
1. Install Instances of Custom Resources:
```sh
@ -149,6 +151,7 @@ make deploy IMG=<some-registry>/constellation/node-operator:tag
```
### Uninstall CRDs
To delete the CRDs from the cluster:
```sh
@ -156,6 +159,7 @@ make uninstall
```
### Undeploy controller
UnDeploy the controller to the cluster:
```sh
@ -163,12 +167,14 @@ make undeploy
```
### How it works
This project aims to follow the Kubernetes [Operator pattern](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/)
It uses [Controllers](https://kubernetes.io/docs/concepts/architecture/controller/)
which provides a reconcile function responsible for synchronizing resources until the desired state is reached on the cluster
### Test It Out
1. Install the CRDs into the cluster:
```sh
@ -184,6 +190,7 @@ make run
**NOTE:** You can also run this in one step by running: `make install run`
### Modifying the API definitions
If you are editing the API definitions, generate the manifests such as CRs or CRDs using:
```sh