Merge pull request #55 from etungsten/res-doc-update

Update docs, update cpu/memory request, limits for update-api agent DaemonSet

README.md

@@ -52,27 +52,31 @@ The agent relies on each node's updater components and schedules its pods based
 The node indicates its updater interface version in a label called `bottlerocket.aws/updater-interface-version`.
 Agent deployments, respective to the interface version, are scheduled using this label and target only a single version in each.
 
-For the `1.0.0` `updater-interface-version`, this label looks like:
+- For Bottlerocket OS versions >= v0.4.1, we recommend using `update-interface-version` 2.0.0 to leverage Bottlerocket's API to dispatch updates.
+- Bottlerocket OS versions < v0.4.1 are only compatible with `update-interface-version` 1.0.0.
+  - With this version, the agent needs to run in a priviledged container with access to the root filesystem.
+
+For the `2.0.0` `updater-interface-version`, this label looks like:
 
 ``` text
-bottlerocket.aws/updater-interface-version=1.0.0
+bottlerocket.aws/updater-interface-version=2.0.0
 ```
 
 `kubectl` can be used to set this label on a node in the cluster:
 
 ``` sh
-kubectl label node $NODE_NAME bottlerocket.aws/updater-interface-version=1.0.0
+kubectl label node $NODE_NAME bottlerocket.aws/updater-interface-version=2.0.0
 ```
 
 If all nodes in the cluster are running Bottlerocket and have the same `updater-interface-version`, all can be labeled at the same time:
 
 ``` sh
-kubectl label node $(kubectl get nodes -o jsonpath='{.items[*].metadata.name}') bottlerocket.aws/updater-interface-version=1.0.0
+kubectl label node $(kubectl get nodes -o jsonpath='{.items[*].metadata.name}') bottlerocket.aws/updater-interface-version=2.0.0
 ```
 
 Each workload resource may have additional constraints or scheduling affinities based on each node's labels in addition to the `bottlerocket.aws/updater-interface-version` label scheduling constraint.
 
-Customized deployments may use the [suggested deployment](./update-operator.yaml) or the [example development deployment](./dev/deployment.yaml) as a starting point, with customized container images specified if needed.
+Customized deployments may use the [suggested deployment](./update-operator.yaml) as a starting point, with customized container images specified if needed.
 
 ## Scheduled Components
 

update-operator.yaml

@@ -131,7 +131,7 @@ spec:
               fieldRef:
                 fieldPath: spec.nodeName
 ---
-# This DaemonSet is for Bottlerocket hosts that support updates through the Bottlerocket API
+# This DaemonSet is for Bottlerocket hosts that support updates through the Bottlerocket API (Bottlerocket OS versions >= v0.4.1)
 apiVersion: apps/v1
 kind: DaemonSet
 metadata:
@@ -184,10 +184,10 @@ spec:
                   fieldPath: spec.nodeName
           resources:
             limits:
-              memory: 600Mi
+              memory: 50Mi
             requests:
-              cpu: 100m
-              memory: 600Mi
+              cpu: 10m
+              memory: 50Mi
           volumeMounts:
             - name: bottlerocket-api-socket
               mountPath: /run/api.sock
@@ -203,7 +203,7 @@ spec:
             path: /run/api.sock
             type: Socket
 ---
-# This DaemonSet is for Bottlerocket hosts that can only support updates through updog
+# This DaemonSet is for Bottlerocket hosts that can only support updates through updog (Bottlerocket OS versions < v0.4.1)
 apiVersion: apps/v1
 kind: DaemonSet
 metadata: