diff --git a/docs/proposals/20190704-AutomatedUpgrades.md b/docs/proposals/20190704-AutomatedUpgrades.md index 6503d52838..6f91271939 100644 --- a/docs/proposals/20190704-AutomatedUpgrades.md +++ b/docs/proposals/20190704-AutomatedUpgrades.md @@ -175,7 +175,7 @@ Once the operator has decided scheduling, it will use the upgrade RPC to perform ## Rationale -One of the goals in Talos is to allow for machines to be thought of as a container in that it is ephemeral, reproducable, and predictable. +One of the goals in Talos is to allow for machines to be thought of as a container in that it is ephemeral, reproducible, and predictable. Since the `kubelet` can reproduce a machine's workload, it is not too crazy to think that we can facilitate upgrades by completely wiping a node, and then performing a fresh install as if the machine is new. ## Compatibility diff --git a/website/content/docs/v0.10/Learn More/architecture.md b/website/content/docs/v0.10/Learn More/architecture.md index c920634f1b..3c8a86a248 100644 --- a/website/content/docs/v0.10/Learn More/architecture.md +++ b/website/content/docs/v0.10/Learn More/architecture.md @@ -23,7 +23,7 @@ This is a key component in reducing coupling and maintaining modularity. One of the more unique design decisions in Talos is the layout of the root file system. There are three "layers" to the Talos root file system. At its' core the rootfs is a read-only squashfs. -The sqaushfs is then mounted as a loop device into memory. +The squashfs is then mounted as a loop device into memory. This provides Talos with an immutable base. The next layer is a set of `tmpfs` file systems for runtime specific needs. @@ -32,7 +32,7 @@ One reason for this is that we need special files such as `/etc/hosts`, and `/et For example, at boot Talos will write `/system/etc/hosts` and the bind mount it over `/etc/hosts`. This means that instead of making all of `/etc` writable, Talos only makes very specific files writable under `/etc`. -All files under `/system` are completely reproducable. +All files under `/system` are completely reproducible. For files and directories that need to persist across boots, Talos creates `overlayfs` file systems. The `/etc/kuberentes` is a good example of this. Directories like this are `overlayfs` backed by an XFS file system mounted at `/var`. diff --git a/website/content/docs/v0.11/Learn More/architecture.md b/website/content/docs/v0.11/Learn More/architecture.md index c920634f1b..3c8a86a248 100644 --- a/website/content/docs/v0.11/Learn More/architecture.md +++ b/website/content/docs/v0.11/Learn More/architecture.md @@ -23,7 +23,7 @@ This is a key component in reducing coupling and maintaining modularity. One of the more unique design decisions in Talos is the layout of the root file system. There are three "layers" to the Talos root file system. At its' core the rootfs is a read-only squashfs. -The sqaushfs is then mounted as a loop device into memory. +The squashfs is then mounted as a loop device into memory. This provides Talos with an immutable base. The next layer is a set of `tmpfs` file systems for runtime specific needs. @@ -32,7 +32,7 @@ One reason for this is that we need special files such as `/etc/hosts`, and `/et For example, at boot Talos will write `/system/etc/hosts` and the bind mount it over `/etc/hosts`. This means that instead of making all of `/etc` writable, Talos only makes very specific files writable under `/etc`. -All files under `/system` are completely reproducable. +All files under `/system` are completely reproducible. For files and directories that need to persist across boots, Talos creates `overlayfs` file systems. The `/etc/kuberentes` is a good example of this. Directories like this are `overlayfs` backed by an XFS file system mounted at `/var`. diff --git a/website/content/docs/v0.8/Learn More/architecture.md b/website/content/docs/v0.8/Learn More/architecture.md index c920634f1b..3c8a86a248 100644 --- a/website/content/docs/v0.8/Learn More/architecture.md +++ b/website/content/docs/v0.8/Learn More/architecture.md @@ -23,7 +23,7 @@ This is a key component in reducing coupling and maintaining modularity. One of the more unique design decisions in Talos is the layout of the root file system. There are three "layers" to the Talos root file system. At its' core the rootfs is a read-only squashfs. -The sqaushfs is then mounted as a loop device into memory. +The squashfs is then mounted as a loop device into memory. This provides Talos with an immutable base. The next layer is a set of `tmpfs` file systems for runtime specific needs. @@ -32,7 +32,7 @@ One reason for this is that we need special files such as `/etc/hosts`, and `/et For example, at boot Talos will write `/system/etc/hosts` and the bind mount it over `/etc/hosts`. This means that instead of making all of `/etc` writable, Talos only makes very specific files writable under `/etc`. -All files under `/system` are completely reproducable. +All files under `/system` are completely reproducible. For files and directories that need to persist across boots, Talos creates `overlayfs` file systems. The `/etc/kuberentes` is a good example of this. Directories like this are `overlayfs` backed by an XFS file system mounted at `/var`. diff --git a/website/content/docs/v0.9/Learn More/architecture.md b/website/content/docs/v0.9/Learn More/architecture.md index c920634f1b..3c8a86a248 100644 --- a/website/content/docs/v0.9/Learn More/architecture.md +++ b/website/content/docs/v0.9/Learn More/architecture.md @@ -23,7 +23,7 @@ This is a key component in reducing coupling and maintaining modularity. One of the more unique design decisions in Talos is the layout of the root file system. There are three "layers" to the Talos root file system. At its' core the rootfs is a read-only squashfs. -The sqaushfs is then mounted as a loop device into memory. +The squashfs is then mounted as a loop device into memory. This provides Talos with an immutable base. The next layer is a set of `tmpfs` file systems for runtime specific needs. @@ -32,7 +32,7 @@ One reason for this is that we need special files such as `/etc/hosts`, and `/et For example, at boot Talos will write `/system/etc/hosts` and the bind mount it over `/etc/hosts`. This means that instead of making all of `/etc` writable, Talos only makes very specific files writable under `/etc`. -All files under `/system` are completely reproducable. +All files under `/system` are completely reproducible. For files and directories that need to persist across boots, Talos creates `overlayfs` file systems. The `/etc/kuberentes` is a good example of this. Directories like this are `overlayfs` backed by an XFS file system mounted at `/var`.