rbankston

2015.05.13, Version 0.12.3 (Stable)

* V8: update to 3.28.71.19

* uv: upgrade to 1.5.0

* npm: upgrade to 2.9.1

* V8: don't busy loop in v8 cpu profiler thread (Mike Tunnicliffe)

rbankston

Keybase proof

I hereby claim:

• I am rbankston on github.
• I am rbankston (https://keybase.io/rbankston) on keybase.
• I have a public key whose fingerprint is B17C E15F B9DE F392 24E0 B5DF E16E 8DC8 EA5B 3C8A

To claim this, I am signing this object:

rbankston

# The "crio" table contains all of the server options.
[crio]

# CRI-O reads its storage defaults from the containers/storage configuration
# file, /etc/containers/storage.conf. Modify storage.conf if you want to
# change default storage for all tools that use containers/storage.  If you
# want to modify just crio, you can change the storage configuration in this
# file.

# root is a path to the "root directory". CRIO stores all of its data,

rbankston

{
	"defaultAction": "SCMP_ACT_ERRNO",
	"archMap": [
		{
			"architecture": "SCMP_ARCH_X86_64",
			"subArchitectures": [
				"SCMP_ARCH_X86",
				"SCMP_ARCH_X32"
			]
		},

rbankston

#!/bin/bash
set -e
set -o pipefail

# Add user to k8s using service account, no RBAC (must create RBAC after this script)
if [[ -z "$1" ]] || [[ -z "$2" ]]; then
 echo "usage: $0 <service_account_name> <namespace>"
 exit 1
fi

rbankston

root@ip-172-31-0-160:/etc/cni/net.d# date
Thu Sep 20 16:42:20 UTC 2018
root@ip-172-31-0-160:/etc/cni/net.d# ifconfig | grep -A 2 cali
cali0ab4c0cd5c4 Link encap:Ethernet  HWaddr ee:ee:ee:ee:ee:ee
          inet6 addr: fe80::ecee:eeff:feee:eeee/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:8981  Metric:1
--
cali63b7f4dbf1a Link encap:Ethernet  HWaddr ee:ee:ee:ee:ee:ee
          inet6 addr: fe80::ecee:eeff:feee:eeee/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:8981  Metric:1

rbankston

Resources

• https://kubernetes.io/docs/tasks/administer-cluster/access-cluster-api/
• https://thenewstack.io/taking-kubernetes-api-spin/ <-- This is just in case.

Main Stuff

There are two ways you can talk to the KUBE API.

Kube-proxy

Start a kube proxy server which will act as a reverse proxy for the client.

rbankston

#!/bin/bash -e

# Usage ./k8s-service-account-kubeconfig.sh ( namespace ) ( service account name )

TEMPDIR=$( mktemp -d )

trap "{ rm -rf $TEMPDIR ; exit 255; }" EXIT

SA_SECRET=$( kubectl get sa -n $1 $2 -o jsonpath='{.secrets[0].name}' )

rbankston

time="2019-08-10T02:14:57Z" level=info msg="setting log-level to INFO"
time="2019-08-10T02:14:57Z" level=info msg="Starting Velero server v1.0.0 (72f5cadc3a865019ab9dc043d4952c9bfd5f2ecb)" logSource="pkg/cmd/server/server.go:165"
time="2019-08-10T02:14:57Z" level=info msg="registering plugin" command=/velero kind=BackupItemAction logSource="pkg/plugin/clientmgmt/registry.go:100" name=velero.io/pod
time="2019-08-10T02:14:57Z" level=info msg="registering plugin" command=/velero kind=BackupItemAction logSource="pkg/plugin/clientmgmt/registry.go:100" name=velero.io/pv
time="2019-08-10T02:14:57Z" level=info msg="registering plugin" command=/velero kind=BackupItemAction logSource="pkg/plugin/clientmgmt/registry.go:100" name=velero.io/serviceaccount
time="2019-08-10T02:14:57Z" level=info msg="registering plugin" command=/velero kind=VolumeSnapshotter logSource="pkg/plugin/clientmgmt/registry.go:100" name=velero.io/aws
time="2019-08-10T02:14:57Z" level=info msg="registering plugin" command=/velero kind=VolumeSnapshot

rbankston

apiVersion: velero.io/v1
kind: Backup
metadata:
  creationTimestamp: "2019-08-10T02:17:41Z"
  generation: 1
  name: maybe
  namespace: velero
  resourceVersion: "140836"
  selfLink: /apis/velero.io/v1/namespaces/velero/backups/maybe
  uid: d31e24e5-e5c8-4369-b91e-b0b01973535b