Kubernetes overview

What is Kubernetes?

Kubernetes is a portable, extensible open-source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation.

Popular container orchestration system

Why Kubernetes?

  • Automatic binpacking (Managing container)
  • Horizontal scaling
  • Automated rollouts and rollbacks
  • Self-healing
  • Service discovery and load balancing
  • Secret and configuration management

Ref: Kubernetes & helm 활용

kubernetes component

  • Master Components
  • Node Components
  • Addons

Master Components

Master components provide the cluster’s control plane

kube-apiserver

Component on the master that exposes the Kubernetes API. It is the front-end for the Kubernetes control plane.

etcd

Consistent and highly-available key value store used as Kubernetes’ backing store for all cluster data.

kube-scheduler

Component on the master that watches newly created pods that have no node assigned, and selects a node for them to run on.

kube-controller-manager

Component on the master that runs controllers.

  • Node Controller: Responsible for noticing and responding when nodes go down.
  • Replication Controller: Responsible for maintaining the correct number of pods for every replication controller object in the system.
  • Endpoints Controller: Populates the Endpoints object (that is, joins Services & Pods).
  • Service Account & Token Controllers: Create default accounts and API access tokens for new namespaces.

cloud-controller-manager

cloud-controller-manager runs controllers that interact with the underlying cloud providers. (etc. AWS, GCP, AZURE …)

Kube api server image

Node component

kubelet

kubernetes agent on each node

check pod state(running and healthy)

kubelet is not container. -> binary file

kube-proxy

Maintaining network rules on the host and performing connection forwarding.

Container Runtime

Docker, rkt, runc, any OCI runtime-spec implementation.

Addon

Dns

Containers started by Kubernetes automatically include this DNS server in their DNS searches.

Web UI (Dashboard)

Kubernetes Architecture

kubrnetes architecture – 1
kubernetes architecture – 2

Kubernetes API

The Kubernetes API also serves as the foundation for the declarative configuration schema for the system.
The kubectl command-line tool can be used to create, update, delete, and get API objects.

OpenAPI and Swagger definitions

/openapi/v2

To make it easier to eliminate fields or restructure resource representations, Kubernetes supports multiple API versions, each at a different API path, such as /api/v1 or /apis/extensions/v1beta1.

API groups

  1. The core group, often referred to as the legacy group, is at the REST path /api/v1 and uses apiVersion: v1.
  2. The named groups are at REST path /apis/$GROUP_NAME/$VERSION, and use apiVersion: $GROUP_NAME/$VERSION (e.g. apiVersion: batch/v1)
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: dreg.be/tkwon/nginx-test:latest
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 1
  template:
    spec:
      containers:
      - name: nginx
        image: nginx:alpine
        ports:
        - containerPort: 80

API versioning

The Kubernetes API – Kubernetes

Just Only need remember this one.

Use api beta and stable

Kubernetes Object Management

The kubectl command-line tool

kubectl run nginx --image nginx

or

kubectl create deployment nginx --image nginx

or more important object

kubectl apply -f nginx.yaml

Pod

  • A Pod is the basic building block of Kubernetes
  • the smallest and simplest unit
  • Represents a unit of deployment
  • Pods that run a single container.
  • Pods that run multiple containers that need to work together.

Example for multiple containers in the Pod

The specific instances in which your containers are tightly coupled.

Multi Pod structure

Pod detail

Pods provide two kinds of shared resources for their constituent containers: networking and storage.

Containers inside a Pod can communicate with one another using localhost

Pods and Controllers

A Controller can create and manage multiple Pods

  • Deployment
  • StatefulSet
  • DaemonSet

Controllers

Deployment

To provides Declarative updates for Pods and ReplicaSets

deployment, replica set and pod

deployment yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

Statefulset

The workload API object used to manage stateful applications

To provides guarantees about the ordering and uniqueness of these Pods.

Using Statefulset

  • Stable, unique network identifiers.
  • Stable, persistent storage.
  • Ordered, graceful deployment and scaling.
  • Ordered, automated rolling updates.

Limitations

Deleting and/or scaling a StatefulSet down will not delete the volumes associated with the StatefulSet.

Pod Identity

StatefulSet Pods have a unique identity
The identity sticks to the Pod, regardless of which node it’s (re)scheduled on.

$(statefulset name)-$(ordinal). The example above will create three Pods named web-0,web-1,web-2

DaemonSet

A DaemonSet ensures that all (or some) Nodes run a copy of a Pod.

ex> Node exporter for prometheus

Services and Network

Service

Expose Pods and can make commnunication between Pods.

kind: Service
apiVersion: v1
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376

my-service.my-namespace.svc.cluster.local

  • ClusterIP
  • NodePort
  • LoadBalancer
  • Match ELB on AWS
  • ExternalName

Ingress

Similar wih Service, but
Service is kind of L4 network
Ingress is kind of L7 network.

Service map to AWS ELB,
Ingress map to AWS ALB

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: test-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - http:
      paths:
      - path: /testpath
        backend:
          serviceName: test
          servicePort: 80

Storage

  • Volumes
  • Persistent Volumes
  • PersistentVolumeClaim
  • Storage Classes

Configuration

  • Secrets
  • ConfigMap

Kubernetes Pod Network

Pod network

I think network is so importance to understand kubernetes.
You should check below references to understand it.

Network references:
understanding-kubernetes-networking-pods
Container Networking From Scratch
About Linux network namespace

iwinv(가상호스팅)에 docker 적용하기

iwinv(가상호스팅)에 docker 적용하기

iwinv 제가 호스팅을 이전했다는 사실은 지난 글에서 이미 언급한 적이 있습니다.

오늘은 iwinv 로 이전하면서 엄청난 고생을 했던 경험에 대한 이야기 및 해결책에 대한 이야기를 적어 보려 합니다.

Environment

  • Ubuntu 16.04 xenial

삽질의 시작

IwinV Manual

iwinv 홈페이지를 가면 이렇게 도커 적용을 하는 것에 대한 매뉴얼이 있습니다만…

가격의 매리트와 docker 적용에 대한 호기심으로 시작한 이 작업이 이렇게 크나큰 고통을 안겨 줄 것이라는 것을 이 때는 몰랐습니다.

사실 저 메뉴얼이 있는걸 확인 하고 docker 적용에 별 어려움이 없을 것이라고 판단했던 것이 제가 서버 이전을 마음 먹은 것에 큰 이유 중 하나이기도 합니다.
물론 iwinv의 메뉴얼은 저를 속였습니다. (물론 회사가 의도친 않았지만…)ㅎㅎㅎ

이유인 즉, 저 매뉴얼은 반 쪽짜리 매뉴얼 이었기 때문입니다.

물론 간단히 하나의 도커파일만으로 사용할 경우는 별 문제가 없을 지도 모르겠습니다만,
도커 이미지간에 네트웍 통신에는 치명적 문제가 있었습니다.

MTU

위의 매뉴얼 링크를 클릭해보시면 아시겠지만, iwinv는 내부적으로 MTU1450으로 사용하고 있다고 합니다. 이리하여 도커의 MTU 설정을 변경해줘야 한다는 것이 저 글의 요지입니다.

자, 그럼 MTU가 무엇이냐하면,

컴퓨터 네트워킹에서, 레이어의 커뮤니케이션 프로토콜의 최대 전송 단위(maximum transmission unit, MTU)란 해당 레이어가 전송할 수 있는 최대 프로토콜 데이터 단위의 크기(바이트)이다.

최대 전송 단위 – 위키백과, 우리 모두의 백과사전

간단히 말해 네트워크 통신에서의 패킷 사이즈를 결정하는 단위라고 생각하면 될 듯 합니다.

이때는 “아 패킷 사이즈를 iwinv가 적게 쓰는 구나.” 하고 넘어갔습니다.

Docker 설치

매뉴얼대로 도커를 설치합니다.
물론 이 포스팅에서는 매뉴얼과 docker 홈페이지를 적절히 이용해서 설치하겠습니다.
현 시점에서의 설치방법입니다. (2017.6)

먼저 apt-get 업데이트를 합니다.

$ sudo apt-get update
$ sudo apt-get upgrade

도커 설치는 공식페이지를 참고합니다.

오래된 버전의 docker 가 있다면 지웁니다.

$ sudo apt-get remove docker docker-engine

docker 설치에 필요한 패키지를 설치합니다.

$ sudo apt-get install \
apt-transport-https \
ca-certificates \
curl \
software-properties-common

docker 의 공식 GPG key를 추가합니다.

$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

키를 확인합니다.
9DC8 5822 9FC7 DD38 854A E2D8 8D81 803C 0EBF CD88

$ sudo apt-key fingerprint 0EBFCD88

pub 4096R/0EBFCD88 2017-02-22
Key fingerprint = 9DC8 5822 9FC7 DD38 854A E2D8 8D81 803C 0EBF CD88
uid Docker Release (CE deb) <docker@docker.com>
sub 4096R/F273FCD8 2017-02-22

amd64 architecture 를 사용하는 docker 를 설치하겠습니다.

$ sudo add-apt-repository \
"deb [arch=amd64] https://download.docker.com/linux/ubuntu \
$(lsb_release -cs) \
stable"

Docker 가 설치가 잘 되었는지 확인

$ sudo docker run hello-world

...
Hello from Docker!
This message shows that your installation appears to be working correctly.

여기서부터 iwinv의 메뉴얼을 따릅니다.

$ sudo docker pull ubuntu
$ sudo docker run -it ubuntu

※ update가 진행이 안되는 문제 발생하며 ftp 등 일부 서비스에서 문제 발생.

위 증상은 MTU 때문입니다.
이제 MTU를 1450으로 세팅합니다.

$ cp /lib/systemd/system/docker.service /etc/systemd/system/docker.service
$ vi /etc/systemd/system/docker.service

/etc/systemd/system/docker.service

[Unit]
Description=Docker Application Container Engine
Documentation=https://docs.docker.com
After=network.target docker.socket firewalld.service
Requires=docker.socket

[Service]
Type=notify
# the default is not to use systemd for cgroups because the delegate issues still
# exists and systemd currently does not support the cgroup feature set required
# for containers run by docker
ExecStart=/usr/bin/dockerd -H fd:// --mtu=1450
#-H fd://
ExecReload=/bin/kill -s HUP $MAINPID
LimitNOFILE=1048576
# Having non-zero Limit*s causes performance problems due to accounting overhead
# in the kernel. We recommend using cgroups to do container-local accounting.
LimitNPROC=infinity
LimitCORE=infinity
# Uncomment TasksMax if your systemd version supports it.
# Only systemd 226 and above support this version.
TasksMax=infinity
TimeoutStartSec=0
# set delegate yes so that systemd does not reset the cgroups of docker containers
Delegate=yes
# kill only the docker process, not all processes in the cgroup
KillMode=process

[Install]
WantedBy=multi-user.target

ExecStart=/usr/bin/dockerd -H fd:// —mtu=1450

이렇게 변경 후에 아래 명령 실행합니다.

$ sudo systemctl daemon-reload
$ sudo service docker restart

이제 이 전의 명령을 다시 실행해봅니다.

$ sudo docker run -it ubuntu

진행이 정상적으로 되는 것을 확인 할 수 있습니다.

Docker compose

여기까지 설치했다면 iwinv의 메뉴얼 대로 잘 설치된 상황입니다.

허나 함정이 있습니다.
바로 docker-compose를 사용하게 될 때의 문제인데요.

먼저 docker-compose를 알아봅시다.

docker compose 란 간단히 말해서 docker application을 이용한 서비스 환경 구축을 손쉽게 도와주는 tool 이라고 생각하시면 됩니다.

일반적으로 web service 구축을 위해선 web application 과 database 가 필요할 것입니다.
docker compose 는 이 둘을 한번에 구성하기 위한 툴로 보시면 됩니다.

설치방법은 아래 링크를 참고하세요.
docker-compose 설치

docker compose를 설치하고 docker-compose.yml 파일을 작성 후 docker로 서비스를 구축합니다. 여기서는 wordpress 를 구축했습니다.

docker-wordpress-nginx/docker-compose.yml at master · 9to6/docker-wordpress-nginx · GitHub

깃허브 소스를 참고하시면 됩니다.

docker-compose.yml

version: "3.2"
services:
web:
build: .
ports:
- "80:80"
volumes:
- wordpress:/var/www/html
depends_on:
- php
php:
image: wordpress:4.8-php7.1-fpm-alpine
depends_on:
- db
restart: always
ports:
- "9000:9000"
volumes:
- wordpress:/var/www/html
db:
image: mariadb:10.2.6
volumes:
- db_data:/var/lib/mysql
restart: always
ports:
- "3306:3306"

docker compose의 파일을 보면 wordpressmariadb 와 함께 설치해서 wordpress web service 를 구성하게 됩니다.

이제 wordpress 설치를 시작하게 되고 첫 화면이 뜨고 난뒤, plugin 이나 theme 를 추가하기 위해 들어가보면 목록이 나오지 않습니다.
에러가 났다고 나오고, (wp-setting.php ?? 기억이 명확하지 않네요..)의 어떤 부분에서 에러가 났다고 합니다.
이제부터 문제 해결 과정입니다.

docker compose 문제 해결 과정

extra_hosts 추가

위의 에러난 부분을 찾아가서 php 소스를 수정, echo 로 확인해봤습니다.
wordpress 내부에서 https 를 이용 api.wordpress.org 에 request 를 보내는 부분에서 계속 에러가 납니다.

구글링을 해봤더니, wordpress docker 내부에서 api.wordpress.org 의 도메인을 lookup을 못해서 일 것이라는 글을 보고 host를 추가해봤는데,

php:
image: wordpress:4.8-php7.1-fpm-alpine
depends_on:
- db
restart: always
ports:
- "9000:9000"
volumes:
- wordpress:/var/www/html
extra_hosts:
- "api.wordpress.org:66.155.40.202"

같은 증상이었습니다…

iptables 추가

전혀 해결이 되지 않아서 또다른 방법을 찾던 중 나온 방법이 iptables를 수정하는 것이 었습니다.
현재 상황이 패킷이 나가지 않는 문제라고 판단했을 때, iptables 를 이용해서 해결 할 수 있을 것이라고 판단하고 적용해봤습니다.

docker 1.10, 1.11 do not infer MTU from eth0; docker 1.9 does · Issue #22028 · moby/moby · GitHub

좋아요도 두개나 받은 내용으로 적용을 해봤는데…

실행이 되었습니다.

이렇게 해결되었다는 기쁨(?)을 느끼고 이제 마무리를 지었는데…

또다른 문제. 다시 원점으로…

제가 모바일 어플의 서버로 사용하던 rails application을 또다른 docker 파일로 실행했는데, 메일이 나가지 않는 문제를 확인했습니다. 이 rails 앱은 smtp 를 사용해서 메일을 보내는 기능이 있었는데 메일이 나가지 않아서 ruby library 파일을 직접 수정하면서 디버깅을 시작했습니다.

문제는 smtp 를 보내는 부분에서 났기 때문에 네트워크 문제로 판단, 결국 다시 원점으로 돌아갔습니다. ㅠㅠ

이렇게 또다시 하루정도 iptables 룰 도 바꿔보고 구글링도 해보고 이것저것 해보게 되었습니다.

이때쯤 iwinv 서비스 이용을 포기할 생각을 잠시 하게 되었습니다…만, 심기일전 하고 다시 구글링.

결국 찾은 해결책과 원인

마침내 찾은 해결책.
containers in docker 1.11 does not get same MTU as host · Issue #22297 · moby/moby · GitHub

docker network 를 구성할 때 mtu 설정을 별도로 해줘야한다는 것이 었습니다.

이제 뭔가 이해되는 느낌…
docker compose 로 docker application을 실행하게 되면,
docker 엔진이 별도의 sub network 를 구성하게 되고, wordpress web app 과 mariadb는 sub network 안에서 통신을 하게 됩니다.
이 때 mtu 사이즈가 1450 이상이었기 때문에 문제가 발생했던 것입니다.

해결을 위해서는
1. 첫번째로, docker-compose 안에 이렇게 network 구성을 해주는 방법이나,

networks:
default:
driver: bridge
driver_opts:
com.docker.network.driver.mtu: 1450
  1. 두번째로는, 미리 생성된 network를 이용하는 방법입니다.
$ suod docker network create -o "com.docker.network.driver.mtu"="1450"
networks:
default:
external:
name:

이 해결책을 찾아보고 다시 두번째 해결책이었던 iptables의 명령어에 대해 찾아봤는데,

TCPMSS target

Under normal circumstances, this means the size of the MTU (Maximum Transfer Unit) value, minus 40 bytes.

정상적 상황에서 MTU 사이즈에서 40바이트를 빼주는 것이라고 하네요.
아마 이래서 잘 작동했었나 봅니다. SMTP 의 패킷은 40을 빼줘도 더 1450보다 더 패킷 사이즈가 컸나 봅니다.

하지만 보다 정확한 해결책은 MTU사이즈 수정입니다.

이제 다시 SMTP 로 메일을 보내봅니다. 정상적으로 동작합니다.

결론

  • iwinvdocker 를 사용은 비추
  •  그러나 이 글을 읽어봤다면 추천;;;
  • docker 를 사용하지 않으면 손쉽게 사용가능 하니 좋은 서비스 저렴하게 사용 가능
  • docker 사용을 하시겠다면 매뉴얼의 MTU 설정과 별도 docker networkMTU 설정도 유념해야 함