This is a tutorial that uses a toy infrastructure project to highlight some of CUE's features and show how it can be used to simplify and manage infrastructure. Go to Tutorial if you want to skip the introductory stuff.
From cuelang.org:
This is a tutorial that uses a toy infrastructure project to highlight some of CUE's features and show how it can be used to simplify and manage infrastructure. Go to Tutorial if you want to skip the introductory stuff.
From cuelang.org:
# The script returns a kubeconfig for the service account given | |
# you need to have kubectl on PATH with the context set to the cluster you want to create the config for | |
# Cosmetics for the created config | |
clusterName=.... | |
# your server address goes here get it via `kubectl cluster-info` | |
server=https://.... | |
# the Namespace and ServiceAccount name that is used for the config | |
namespace=mynamespace | |
serviceAccount=mynamespace-user |
#!/usr/bin/env bash | |
set -o errexit | |
set -o nounset | |
set -o pipefail | |
LAST_SYNC_COMMIT=$(git log -n1 --grep '^\[upstream-sync\]' --pretty='format:%h' helm/) | |
TMPDIR=$(mktemp -d) | |
UPSTREAM_ZIP_URL=${UPSTREAM_ZIP_URL:-"https://github.com/Kong/charts/archive/master.zip"} |
Helm 3 is storing description of it's releases in secrets. You can simply find them via
$ kubectl get secrets
NAME TYPE DATA AGE
sh.helm.release.v1.wordpress.v1 helm.sh/release.v1 1 1h
If you want to get more info about the secret, you can try to describe the secret
$ kubectl describe secret sh.helm.release.v1.wordpress.v1
KEY_NAME=MY-SECRET_KEY; ssh-keygen -t ed25519 -a 100 -N "" -f ~/.ssh/"${KEY_NAME}" -C "${KEY_NAME}" | |
# Explanation | |
KEY_NAME=MY-SECRET_KEY The name of the key, also used as filename | |
-t ed25519 Use a ed25519 key | |
-a 100 Use 100 key derivation function rounds (higher = slower) | |
-N "" No password | |
-f ~/.ssh/"${KEY_NAME}" Store the key at this location on your computer | |
-C "${KEY_NAME}" Set the comment to the key name |
[ | |
{ | |
"_id": "74ad2b40-3774-11e8-8bf5-0529df825f82", | |
"_type": "visualization", | |
"_source": { | |
"title": "Amount Errors", | |
"visState": "{\"title\":\"Amount Errors\",\"type\":\"metric\",\"params\":{\"addLegend\":false,\"addTooltip\":true,\"metric\":{\"colorSchema\":\"Green to Red\",\"colorsRange\":[{\"from\":0,\"to\":10000}],\"invertColors\":false,\"labels\":{\"show\":true},\"metricColorMode\":\"None\",\"percentageMode\":false,\"style\":{\"bgColor\":false,\"bgFill\":\"#000\",\"fontSize\":60,\"labelColor\":false,\"subText\":\"\"},\"useRanges\":false},\"type\":\"metric\"},\"aggs\":[{\"id\":\"1\",\"enabled\":true,\"type\":\"count\",\"schema\":\"metric\",\"params\":{\"customLabel\":\"\"}},{\"id\":\"3\",\"enabled\":true,\"type\":\"filters\",\"schema\":\"group\",\"params\":{\"filters\":[{\"input\":{\"query\":\"log: Traceback OR log: error\"},\"label\":\"Error Log Entries\"}]}}]}", | |
"uiStateJSON": "{}", | |
"description": "", | |
"version": 1, |
tunneld
to /usr/local/bin/tunneld
useradd -r tunneld
/etc/tunneld
/usr/local/bin/certstrap
The official guide for setting up Kubernetes using kubeadm
works well for clusters of one architecture. But, the main problem that crops up is the kube-proxy
image defaults to the architecture of the master node (where kubeadm
was run in the first place).
This causes issues when arm
nodes join the cluster, as they will try to execute the amd64
version of kube-proxy
, and will fail.
It turns out that the pod running kube-proxy
is configured using a DaemonSet. With a small edit to the configuration, it's possible to create multiple DaemonSets—one for each architecture.
Follow the instructions at https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/ for setting up the master node. I've been using Weave Net as the network plugin; it see
type: object | |
required: | |
- openapi | |
- info | |
- paths | |
properties: | |
openapi: | |
type: string | |
pattern: ^3\.0\.\d(-.+)?$ | |
info: |