Starting to Learn Kubernetes a Step Behind - 10. config&storage Part 1 -

Story

Last Time

In Starting to Learn Kubernetes a Step Behind - 09. discovery&LB Part 2 -, we learned about various services. This time, we will learn about the config in config&storage.

config&storage

In Kubernetes, there are types of resources as follows.

Classification of Resources	Content
Workloads Resources	Resources related to the execution of containers
Discovery＆LB Resources	Resources that provide endpoints to expose containers externally
Config＆Storage Resources	Resources related to configuration, secret information, persistent volumes, etc.
Cluster Resources	Resources related to security and quotas
Metadata Resources	Resources for operating resources

※ Kubernetes Workloads Resources (Part 1)

Environment Variables

It seems there are static settings, settings for Pods and containers, and settings for secrets.

# sample-env.yaml
apiVersion: v1
kind: Pod
metadata:
  name: sample-env
  labels:
    app: sample-app
spec:
  containers:
    - name: nginx-container
      image: nginx:1.12
      env:
        - name: MAX_CONNECTION
          value: "100"
        - name: POD_IP
          valueFrom:
            fieldRef:
              fieldPath: status.podIP
        - name: LIMITS_CPU
          valueFrom:
            resourceFieldRef:
              containerName: nginx-container
              resource: limits.cpu

pi@raspi001:~/tmp $ k apply -f sample-env.yaml
pi@raspi001:~/tmp $ k exec -it sample-env env
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
...
MAX_CONNECTION=100
POD_IP=10.244.1.97
LIMITS_CPU=4
...

MAX_CONNECTION can be set statically. Pod or container settings can be set with POD_IP,KIMITS_CPU. Pod or container information can be obtained with k get pods sample-env -o yaml. I see.

Secret

Secret encrypts confidential information such as passwords. There are several types of methods as follows.

Generic
TLS
Docker Repository
Service Account

In the case of Generic, it is schema-less, so it allows for highly versatile specification. I think I'll try using that. (In the case of TLS, tls.crt,tls.key are required）

The ways to use it are file reference, envfile reference, direct specification, and manifest specification. I'll try each one.

File Reference

pi@raspi001:~/tmp $ echo -n "root" > ./username
pi@raspi001:~/tmp $ echo -n "rootpassword" > ./password
pi@raspi001:~/tmp $ k create secret generic --save-config sample-db-auth --from-file=./username --from-file=./password
pi@raspi001:~/tmp $ sudo apt-get install jq
pi@raspi001:~/tmp $ k get secrets sample-db-auth -o json | jq .data
{
  "password": "cm9vdHBhc3N3b3Jk",
  "username": "cm9vdA=="
}

envfile Reference

# env-secret.txt
username=root
password=rootpassword

pi@raspi001:~/tmp $ k create secret generic --save-config sample-db-auth2 --from-env-file ./env-secret.txt
pi@raspi001:~/tmp $ k get secrets sample-db-auth2 -o json | jq .data
{
  "password": "cm9vdHBhc3N3b3Jk",
  "username": "cm9vdA=="
}

Direct Specification

pi@raspi001:~/tmp $ k create secret generic --save-config sample-db-auth3 --from-literal=username=root --from-literal=password=rootpassword
pi@raspi001:~/tmp $ k get secrets sample-db-auth3 -o json | jq .data
{
  "password": "cm9vdHBhc3N3b3Jk",
  "username": "cm9vdA=="
}

Manifest Specification

# sample-db-auth.yaml
apiVersion: v1
kind: Secret
metadata:
  name: sample-db-auth4
type: Opaque
data:
  username: cm9vdA== # root
  password: cm9vdHBhc3N3b3Jk # rootpassword

pi@raspi001:~/tmp $ k apply -f sample-db-auth.yaml
pi@raspi001:~/tmp $ k get secrets sample-db-auth4 -o json | jq .data
{
  "password": "cm9vdHBhc3N3b3Jk",
  "username": "cm9vdA=="
}

All of them worked correctly. I don't think I'll use it as a product, but it's easy to handle and good for checking out Generic.

Now, let's use the values we set.

Using Secret

The methods are either environment variables or Volume.

Using Secret from Environment Variables

# sample-secret-single-env.yaml
apiVersion: v1
kind: Pod
metadata:
  name: sample-secret-single-env
spec:
  containers:
    - name: secret-container
      image: nginx:1.12
      env:
        - name: DB_USERNAME
          valueFrom:
            secretKeyRef:
              name: sample-db-auth
              key: username

pi@raspi001:~/tmp $ k apply -f sample-secret-single-env.yaml
pi@raspi001:~/tmp $ k exec -it sample-secret-single-env env | grep DB_USERNAME
DB_USERNAME=root

When using from environment variables, the value becomes fixed. (static)

Using Secret from Volume

# sample-secret-single-volume.yaml
apiVersion: v1
kind: Pod
metadata:
  name: sample-secret-single-volume
spec:
  containers:
    - name: secret-container
      image: nginx:1.12
      volumeMounts:
        - name: config-volume
          mountPath: /config
  volumes:
    - name: config-volume
      secret:
        secretName: sample-db-auth
        items:
          - key: username
            path: username.txt

pi@raspi001:~/tmp $ k apply -f sample-secret-single-volume.yaml
pi@raspi001:~/tmp $ k exec -it sample-secret-single-volume cat /config/username.txt
root

It seems that you can dynamically rewrite this. It must be looking at the Volume sequentially. (In the case of environment variables, they are fixed at the time of content startup)

pi@raspi001:~/tmp $ cat << EOF | k apply -f -
> apiVersion: v1
> kind: Secret
> metadata:
>   name: sample-db-auth
> type: Opaque
> data:
>  username: YMRtaW4=
>  # root > admin
> EOF
pi@raspi001:~/tmp $ k exec -it sample-secret-single-volume cat /config/username.txt
amin

It's being rewritten dynamically. OK!

※ The 'a' in admin was garbled...

ConfigMap

You can register configuration information in Key-Value format. The methods are the same as before: file reference, direct reference, and manifest reference. Since it's the same as before, let's try only file reference.

# sample.txt
hogehoge
fugafuga

pi@raspi001:~/tmp $ k create configmap --save-config sample-configmap --from-file=./sample.txt
pi@raspi001:~/tmp $ k get configmaps sample-configmap -o json | jq .data
{
  "sample.txt": "hogehoge\nfugafuga\n"
}

It feels the same as secret. Apparently, you can save any file (up to 1MB). Like secret, the data you set can be referenced from two places: environment variables and Volume.

Cleaning up

pi@raspi001:~/tmp $ k delete -f sample-env.yaml -f sample-db-auth.yaml -f sample-secret-single-env.yaml -f sample-secret-single-volume.yaml
pi@raspi001:~/tmp $ k delete secret sample-db-auth sample-db-auth2 sample-db-auth3
pi@raspi001:~/tmp $ k delete configmap sample-configmap

Finally

We learned about how to set environment variables. In personal development, when incorporating external services into an application, I develop by registering the API_KEY as an environment variable. This time, we saved the Secret as Generic, but in a product, Is it common to use service_account?

Next time, we will learn about Storage. Here it is.

If it was helpful, support me with a ☕!

Related tags

Kubernetes