Merge pull request #1879 from Adaptly/flatcar-0.15.x

[v0.15.0] Switch CoreOS to Flatcar

Author: dominicgunn

builtin/files/cluster.yaml.tmpl

@@ -6,17 +6,15 @@ clusterName: {{.ClusterName}}
 # The URI of the S3 bucket for the cluster
 s3URI: {{.S3URI}}
 
-# CoreOS release channel to use. Currently supported options: alpha, beta, stable
-# See coreos.com/releases for more information
+# Flatcar release channel to use. Currently supported options: alpha, beta, stable
+# See https://www.flatcar-linux.org/releases/ for more information
 #releaseChannel: stable
 
-# The AMI ID of CoreOS.
-#
 # To update this to the latest AMI run the following command with the appropriate region and channel then place the resulting ID here
-#   REGION=eu-west-1 && CHANNEL=stable && curl -s https://coreos.com/dist/aws/aws-$CHANNEL.json | jq -r ".\"$REGION\".hvm"
+#   REGION=eu-west-1 CHANNEL=stable; curl -s https://$CHANNEL.release.flatcar-linux.net/amd64-usr/current/flatcar_production_ami_all.json | jq  -r ".amis[] | select(.name==\"$REGION\") .hvm"
 amiId: "{{.AmiId}}"
 
-# Container Linux has automatic updates https://coreos.com/os/docs/latest/update-strategies.html. This can be a risk in certain situations and this is why is disabled by default and you can enable it by setting this param to false.
+# Flatcar has automatic updates https://docs.flatcar-linux.org/os/update-strategies/#disable-automatic-updates-daemon. This can be a risk in certain situations and this is why is disabled by default and you can enable it by setting this param to false.
 disableContainerLinuxAutomaticUpdates: true
 
 # Customizes how kube-aws deals with CloudFormation

builtin/files/etcdadm/README.md

@@ -33,8 +33,8 @@ save it in S3
 * `etcdadm restore` restores the etcd member running on the same node as etcdadm from a snapshot saved in S3
 * `etcdadm check` runs health checks against all the members in an etcd cluster so that `kubeadm reconfigure` updates the etcd member accordingly to the situation
 * `etcdadm reconfigure` reconfigures the etcd member on the same node as etcdadm so that it survives:
-  * `N/2` or less permanently failed members, by automatically removing a permanently failed member and then re-add it as a brand-new member with empty data according to ["Replace a failed etcd member on CoreOS Container Linux"](https://coreos.com/etcd/docs/latest/etcd-live-cluster-reconfiguration.html#replace-a-failed-etcd-member-on-coreos-container-linux)
-  * `(N/2)+1` or more permanently failed members, by automatically initiating a new cluster, from a snapshot if it exists, according to ["etcd disaster recovery on CoreOS Container Linux"](https://coreos.com/etcd/docs/latest/etcd-live-cluster-reconfiguration.html#etcd-disaster-recovery-on-coreos-container-linux)  
+  * `N/2` or less permanently failed members, by automatically removing a permanently failed member and then re-add it as a brand-new member with empty data according to ["Replace a failed etcd member on Flatcar Container Linux"](https://coreos.com/etcd/docs/latest/etcd-live-cluster-reconfiguration.html#replace-a-failed-etcd-member-on-coreos-container-linux)
+  * `(N/2)+1` or more permanently failed members, by automatically initiating a new cluster, from a snapshot if it exists, according to ["etcd disaster recovery on Flatcar Container Linux"](https://coreos.com/etcd/docs/latest/etcd-live-cluster-reconfiguration.html#etcd-disaster-recovery-on-coreos-container-linux)  
 * `etcdadm replace` is used to manually recover from an etcd member from a permanent failure. It resets the etcd member running on the same node as etcdadm by:
   1. clearing the contents of the etcd data dir
   2. removing and then re-adding the etcd member by running `etcdctl member remove` and then `etcdctl memer add`

builtin/files/userdata/cloud-config-controller

@@ -40,13 +40,10 @@ coreos:
     reboot-strategy: "off"
   units:
 {{if .DisableContainerLinuxAutomaticUpdates}}
-    - name: disable-automatic-update.service
-      command: start
-      content: |
-        [Unit]
-        Description=Disable Container Linux automatic update. Work around to be removed on Ignition migration.
-        [Service]
-        ExecStart=/usr/bin/sh -c 'for u in update-engine locksmithd; do systemctl stop $${u}.service; systemctl mask $${u}.service; systemctl disable $${u}.service; done; systemctl reset-failed'
+    - name: update-engine.service
+      mask: true
+    - name: locksmithd.service
+      mask: true
 {{end}}
 
     - name: handle-disable-request.service

builtin/files/userdata/cloud-config-etcd

@@ -42,13 +42,10 @@ coreos:
     reboot-strategy: "off"
   units:
 {{if .DisableContainerLinuxAutomaticUpdates}}
-    - name: disable-automatic-update.service
-      command: start
-      content: |
-        [Unit]
-        Description=Disable Container Linux automatic update. Work around to be removed on Ignition migration.
-        [Service]
-        ExecStart=/usr/bin/sh -c 'for u in update-engine locksmithd; do systemctl stop $${u}.service; systemctl mask $${u}.service; systemctl disable $${u}.service; done; systemctl reset-failed'
+    - name: update-engine.service
+      mask: true
+    - name: locksmithd.service
+      mask: true
 {{end}}
 {{- range $u := .Etcd.CustomSystemdUnits}}
     - name: {{$u.Name}}

builtin/files/userdata/cloud-config-worker

@@ -42,13 +42,10 @@ coreos:
     reboot-strategy: "off"
   units:
 {{if .DisableContainerLinuxAutomaticUpdates}}
-    - name: disable-automatic-update.service
-      command: start
-      content: |
-        [Unit]
-        Description=Disable Container Linux automatic update. Work around to be removed on Ignition migration.
-        [Service]
-        ExecStart=/usr/bin/sh -c 'for u in update-engine locksmithd; do systemctl stop $${u}.service; systemctl mask $${u}.service; systemctl disable $${u}.service; done; systemctl reset-failed'
+    - name: update-engine.service
+      mask: true
+    - name: locksmithd.service
+      mask: true
 {{end}}
 {{- range $u := .CustomSystemdUnits}}
     - name: {{$u.Name}}

docs/cli-reference/README.md

@@ -8,7 +8,7 @@ Initialize the base configuration for a cluster ready for customization prior to
 
 | Flag | Description | Default |
 | -- | -- | -- |
-| `ami-id` | The AMI ID of CoreOS Container Linux to deploy | The latest AMI for the Container Linux release channel specified in `cluster.yaml` |
+| `ami-id` | The AMI ID of Flatcar Container Linux to deploy | The latest AMI for the Container Linux release channel specified in `cluster.yaml` |
 | `availability-zone` | The AWS availability-zone to deploy to. Note, this can be changed to multi AZ in `cluster.yaml` | none |
 | `cluster-name` | The name of this cluster. This will be the name of the cloudformation stack | none |
 | `external-dns-name` | The hostname that will route to the api server | none |

docs/getting-started/step-2-render.md

@@ -6,7 +6,7 @@ This is the second step of [running Kubernetes on AWS](README.md). Before we lau
 
 ### EC2 key pair
 
-The keypair that will authenticate SSH access to your EC2 instances. The public half of this key pair will be configured on each CoreOS node.
+The keypair that will authenticate SSH access to your EC2 instances. The public half of this key pair will be configured on each Flatcar node.
 
 After creating a key pair, you will use the name you gave the keys to configure the cluster. Key pairs are only available to EC2 instances in the same region. More info in the [EC2 Keypair docs](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html).
 
@@ -207,7 +207,7 @@ Each component certificate is only valid for 90 days, while the CA is valid for
 If deploying a production Kubernetes cluster, consider establishing PKI independently of this tool first. [Read more below.][tls-note]
 
 **Did everything render correctly?**
-If you are familiar with CoreOS and the AWS platform, you may want to include some additional customizations or optional features. Read on below to explore more.
+If you are familiar with Flatcar and the AWS platform, you may want to include some additional customizations or optional features. Read on below to explore more.
 
 [Yes, ready to launch the cluster][getting-started-step-3]
 
@@ -236,15 +236,15 @@ You can now customize your cluster by editing asset files. Any changes to these
   * `cloud-config-worker`
   * `cloud-config-controller`
 
-  This directory contains the [cloud-init](https://github.com/coreos/coreos-cloudinit) cloud-config userdata files. The CoreOS operating system supports automated provisioning via cloud-config files, which describe the various files, scripts and systemd actions necessary to produce a working cluster machine. These files are templated with your cluster configuration parameters and embedded into the CloudFormation stack template.
+  This directory contains the [cloud-init](https://github.com/coreos/coreos-cloudinit) cloud-config userdata files. The Flatcar operating system supports automated provisioning via cloud-config files, which describe the various files, scripts and systemd actions necessary to produce a working cluster machine. These files are templated with your cluster configuration parameters and embedded into the CloudFormation stack template.
 
   Some common customizations are:
 
   - [mounting ephemeral disks][mount-disks]
   - [allow pods to mount RDB][rdb] or [iSCSI volumes][iscsi]
   - [allowing access to insecure container registries][insecure-registry]
   - [use host DNS configuration instead of a public DNS server][host-dns]
-  - [changing your CoreOS auto-update settings][update]
+  - [changing your Flatcar auto-update settings][update]
   <br/><br/>
 
 * **stack-template.json**
@@ -270,7 +270,7 @@ You can now customize your cluster by editing asset files. Any changes to these
 
 ### Kubernetes Container Runtime
 
-The kube-aws tool now optionally supports using rkt as the kubernetes container runtime. To configure rkt as the container runtime you must run with a CoreOS version >= `v1151.0.0` and configure the runtime flag.
+The kube-aws tool now optionally supports using rkt as the kubernetes container runtime. To configure rkt as the container runtime you must run with a Flatcar version >= `v1151.0.0` and configure the runtime flag.
 
 Edit the `cluster.yaml` file:
 

docs/getting-started/step-4-update.md

@@ -44,7 +44,7 @@ some of your system pods will break (especially `kube-dns`). Deleting the said s
 
 There is no solution for hosting an etcd cluster in a way that is easily updateable in this fashion- so updates are automatically masked for the etcd instances. This means that, after the cluster is created, nothing about the etcd ec2 instances is allowed to be updated.
 
-Fortunately, CoreOS update engine will take care of keeping the members of the etcd cluster up-to-date, but you as the operator will not be able to modify them after creation via the update mechanism.
+Fortunately, Flatcar update engine will take care of keeping the members of the etcd cluster up-to-date, but you as the operator will not be able to modify them after creation via the update mechanism.
 
 In the (near) future, etcd will be hosted on Kubernetes and this problem will no longer be relevant. Rather than concocting overly complex band-aid, we've decided to "punt" on this issue of the time being.
 

docs/tutorials/quick-start.md

@@ -1,6 +1,6 @@
 # Quick Start
 
-Get started with kube-aws and deploy a fully-functional Kubernetes cluster running on CoreOS Container Linux using AWS CloudFormation.
+Get started with kube-aws and deploy a fully-functional Kubernetes cluster running on Flatcar Container Linux using AWS CloudFormation.
 
 After completing this guide, you will be able to deploy applications to Kubernetes on AWS and interact with the Kubernetes API using the `kubectl` CLI tool.