sejong.jeonjo@gmail.com

2019년 3월에 작성된 Web Docs이지만, 오늘(2021년 11월) 따라서 수행해봤는데 잘 동작한다.

https://kubernetes.io/blog/2019/03/15/kubernetes-setup-using-ansible-and-vagrant/

위 블로그를 읽으면서, 나한테 필요한 만큼 playbook을 다시 작성했다.

아래 Playbook의 내용을 간략하게 설명하면,

1. Kubernetes Master Node에서  `kubeadm token create --print-join-command`를 수행하여 새로운 Node Join을 위한 `kubeadm join ....` 명령행을 생성하고,
   이렇게 얻은 kubeadm 명령행을 'join-command' 스크립트 파일에 Dump한다.
2. 바로 위에서 얻은 'join-command'를 새롭게 추가할 Worker Node의 /tmp/join-command.sh 경로에 복사하고 실행(Run)한다.
   그러면 새로운 Worker Node가 Master Node에 추가(Join)될 것이다.

단, 아래 Playbook YAML 파일에서 inventory(즉, hosts를 정의한 항목)을 생략했으니까 그 부분을 감안하고 보면 좋을 듯~~~

## 위 Web docs에서 중요한 부분만 발췌했다.
## 원문 그대로는 아니고, 내가 필요한 만큼 각색했다.  

## Filename: my-playbook.yaml

- name: Joining Job Step 1 on Master node
  hosts: kubemaster
  tasks:
    - name: Generate join command
      command: kubeadm token create --print-join-command
      register: join_command
    - name: Copy join command to local file
      local_action: copy content="{{ join_command.stdout_lines[0] }}" dest="./join-command"

- name: Joining Job Step 2 on Worker node
  hosts: kubeworker
  tasks:
    - name: Copy the join command to server location
      copy: src=join-command dest=/tmp/join-command.sh mode=0777
    - name: Join the node to cluster
      command: sh /tmp/join-command.sh

작성일: 2024년 3월 1일

Pod 생성 방법 - A

급하게 Pod만 생성해서 Kubernetes 기능을 확인해야 할 경우가 있다.

이럴 때, 아래와 같이 명령 한번 실행해서 Pod를 deploy할 수 있다.

$ kubectl  create  deployment  nginx  --image=nginx

또는 아래와 같이  YAML 형식으로 Pod 배포가 가능하다.

Pod 생성 방법 - B

$  kubectl  create  namespace  andrew
$  kubectl  apply  -n andrew  -f -  <<EOF

apiVersion: v1
kind: Pod
metadata:
  name: almighty
  labels:
    app: almighty
spec:
  terminationGracePeriodSeconds: 3
  containers:
  - name: almighty
    image: docker.io/andrewloyolajeong/almighty:0.2.4
    
EOF

[ 참고 ]
docker.io/andrewloyolajeong/almighty 컨테이너 이미지 내부 동작에 대한 설명
    - NGINX 서버 구동 (TCP 80 포트를 Listening)
    - SSHD 서버 구동 (TCP 22 포트를 Listening)
    - Golang으로 구현한 Simple HTTP Server 구동 (TCP 8080 포트를 Listeing)
    - Golang으로 구현한 UDP 서버 구동 (UDP 9090, 9091, 9092 포트를 사용)

그런 후에 아래와 같이 Service Resource도 만들 수 있다.

Service 리소스 생성 방법

$  kubectl  apply  -n andrew  -f -  <<EOF

apiVersion: v1
kind: Service
metadata:
  name: almighty
  annotations:
    ## 아래 nlb 타입은 UDP 패킷을 LB 처리하기 위한 설정이다.
    ## 만약, UDP 패킷을 처리할 일이 없다면, "nlb" 타입을 지정하지 않아도 된다.
    oci.oraclecloud.com/load-balancer-type: "nlb"  ## Oracle Cloud를 사용하는 경우 설정
spec:
  type: LoadBalancer
  externalTrafficPolicy: Local     ## Public Cloud를 사용하는 경우 설정
  selector:
    app: almighty
  ports:
    - name: myweb
      protocol: TCP
      port: 8080
      targetPort: 8080
    - name: yourweb
      protocol: TCP
      port: 1080
      targetPort: 80
    - name: myudp
      protocol: UDP
      port: 9090
      targetPort: 9090
  
EOF

PV 생성

진짜 간단하게 PV, PVC 생성에 관해서 작성하려고 했는데 Private Cloud 환경과 Public Cloud 환경에 따라 생성 방법이 다르고,

Public Cloud Infra를 제공하는 회사마다 Manifest 작성 방법이 다 달라서 이 부분은 아래와 같이 해당 Public Cloud Infra의 Web Docs 주소를 남기는 것으로 마무리하겠다.

가장 많이 사용되는 CSI[Cluster Storage Interface] 몇 가지 사례만 사용법을 익히면 될듯하다.

Oracle Cloud Infra를 사용한다면, 아래 Web Docs를 읽고 예제를 따라하면 잘 동작한다.

https://docs.oracle.com/en-us/iaas/Content/ContEng/Tasks/contengcreatingpersistentvolumeclaim.htm

Kubernetes나 Docker를 이용해서 이것저것 사용하다보면, 나중에는 사용하지 않고 남아 있는 쓰레기 image들이 있다.

이것들을 한방에 지우는 스크립트를 작성했다.

아래 Script는 ":5000" 문자열을 포함하는 container image만 찾아서 지운다.

#!/usr/bin/bash

REMOVE_ITEM_LIST=$(docker image ls | grep ":5000" | awk '{ printf "%s:%s\n", $1, $2 }')

for REMOVE_ITEM in $REMOVE_ITEM_LIST
do
  echo "TO Remove:  $REMOVE_ITEM"
  docker image rm $REMOVE_ITEM
done

아래의 글이 쉽게 설명되어 있다. 시간될 때, 다시 꼼꼼하게 읽어봐야겠다.

참고: istio v1.2  kubernetes v1.14로 테스트한 과정이 설명되어 있다.

http://itnp.kr/post/istio-circuit-break

Kubernetes service의 manifest를 작성하다보면, port와 targetport가 헷갈린다.

각 term이 의미하는 것을 지금 이해해도, 몇 개월 뒤에 다시 service resource에 대한 manifest를 작성하려고 보면 또 헷갈려서 다시 문서를 뒤적거리게 된다.

• Port
  • Service Object 자체의 Port.  즉, 여러 Pod를 묶어서 이 Port 값으로 노출시킨다.
  • 한 kubernetes cluster 내에서 다른 pod가 내 pod에게 Layer 4 메시지를 전송할 때 바라보는 port number.
  • 만약 MetalLB, NGINX 같은 Ingress Gateway를 사용하는 경우라면, 이 'port' 값이 Cluster 외부에서 LB(즉, Ingress Gateway)를 통해 들어오는 Port number가 된다.
    예를 들어,   http://{EXTERNAL-IP}:{SERVICE-PORT}
    이런 형태가 된다.
• TargetPort
  • 내 pod 안에 있는 container가 listening하고 있는 port number.
  • container(즉, app)이 어떤 port를 listening하고 있는지 정확한 값을 알고 설정해야 한다. (HTTPD 설정시 기본 값을 이용했다면, 대부분 80이지 않을까?)
• NodePort
  • kubernetes 밖으로 노출시킬 port number.
  • Ingress Gateway 또는 Istio를 사용하는 경우에는 딱히 설정할 필요없는 설정 항목.

Example

만약 2개의 TCP Port를 Service로 오픈하고 싶다면, 아래와 같이 Service Resource와 Pod Resource를 설정한다.

##
## Service Manifest Example
##
kind: Service
metadata:
... 중간 생략 ...
spec:
  ports:
  - name: metrics
    port: 24231
    protocol: TCP
    targetPort: metrics
  - name: logfile-metrics
    port: 2112
    protocol: TCP
    targetPort: logfile-metrics
... 중간 생략 ...   
    


##
## Pod Manifest Example
##
kind: Pod
metadata:
... 중간 생략 ...
spec:
  containers:
    name: my-container  
    ports:
    - containerPort: 24231
      name: metrics
      protocol: TCP
    - containerPort: 2112
      name: logfile-metrics
      protocol: TCP
... 중간 생략 ...

만약, Kubernetes cluster network 외부에서 kubernetes service에 access한다고 가정하면

아래와 같이 kubectl port-forward 명령으로 외부 IP traffic을 허용할 수 있다.

Example: Jenkins Web Dashboard 접속한다고 가정하고 테스트해보기

• 구성 예시:
  • kubernetes service의 port는 8080
  • Web browser로 접속할 port는 8180

즉, 외부에서 8180으로 접속시도하면, 8080으로 port forward하도록 하려면, 아래와 같이 명령을 수행하면 된다.

##
## --addresss=0.0.0.0은 모든 IP Address를 수용하겠다는 뜻이다.
##
## 8180:8080은 Kubernetes Cluster 외부의 Client가 8180 포트로 접속 요청하면
## Kubernetes Cluster 내부의 8080 서비스 포트로 Forward해주겠다는 뜻이다.
##

$ kubectl  port-forward  --address=0.0.0.0 \
     $(kubectl get pod -l app.kubernetes.io/name=jenkins -o jsonpath='{.items[0].metadata.name}') \
     8180:8080

위와 같이 설정하고 Web browser에서 bastion node로 접속 시도한다.  (아래 예제 명령처럼 접속한다.)

$  curl  http://bastion.my-kube.node:8180/

위 예시는 Pod Name을 이용한 것이고, Service 이름을 이용해서도 port-forward 설정할 수 있다. (아래 명령을 참고)

##
## Cluster 밖의 Client가 9999 port 번호로 요청하면,
## 80 port 번호로 바꾸어서 almighty 네임스페이스의 almighty 서비스로 forwarding한다.
##

$ kubectl port-forward --address=0.0.0.0 -n almighty service/almighty 9999:80
Forwarding from 0.0.0.0:9999 -> 8080
Handling connection for 9999
...

참고:
위 kubectl port-forward 명령을 수행한 node가 bastion이라면, web browser가 접속할 Server(Target) 주소도 bastion의 IP address이어야 한다.

게시물 작성자: sejong.jeonjo@gmail.com

Ingress Concept

‘호롤리’가 작성한 Ingress Gateway의 개념 설명과 실습 절차이다.
https://gruuuuu.github.io/cloud/k8s-service/#

위 블로그를 따라 해도 Ingress Gateway가 잘 동작하고, 아래와 같이 내가 만든 Practice YAML을 이용해도 Ingress Gateway가 잘 동작한다.

Practice

일반적인 준비 절차:

K8s cluster에 'ingress controller'가 동작 중인지 확인한다.

(만약 설치된 ingress controller가 없으면, nginx ingress controller를 설치할 것!)

$ kubectl get all -n ingress-nginx
NAME                                 READY   STATUS    RESTARTS   AGE
pod/ingress-nginx-controller-2bzz7   1/1     Running   0          6h23m
pod/ingress-nginx-controller-5rnw8   1/1     Running   0          6h23m
pod/ingress-nginx-controller-69jf2   1/1     Running   0          6h23m
pod/ingress-nginx-controller-j9nwr   1/1     Running   0          6h22m
pod/ingress-nginx-controller-xzc79   1/1     Running   0          6h22m

NAME                               TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)                      AGE
service/ingress-nginx-controller   LoadBalancer   10.233.15.71   10.10.9.180   80:31302/TCP,443:31071/TCP   57d

NAME                                      DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
daemonset.apps/ingress-nginx-controller   5         5         5       5            5           kubernetes.io/os=linux   57d

가능하면, 위 예제처럼 service type이 ‘LoadBalancer’가 되도록하고, cluster 외부에서 직접 접속 가능한 주소를 할당한다. (예: 10.10.9.180)
위 예제대로라면, Cluster 밖에 있는 Web Browser는 80, 443 포트로 접속 가능하다.

Ingress Object 설정 및 생성

내 Pod에 접근할 수 있는 Ingress object를 생성한다.

아래와 같이 내 서비스에 접근할 수 있도록 Ingress manifest 파일을 작성한다.

##
## Filename: ingress.yaml
##
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: mymusic
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: andrewapp.peter.space    # web browser에서 'http://andrewapp.peter.space/'로 요청이 들어온다면...
    http:
      paths:
      - path: /mymusic      # web browser에서 'http://.../mymusic/...' 로 요청이 들어온다면...
        backend:
          serviceName: andrewapp   # 'andrewapp'이름의 '80' 포트 서비스 Object로 패킷을 Forward한다.
          servicePort: 80

위에서 작성한 ingress.yaml을 kubernetes cluster에 적용한다.

$ kubectl apply  -n andrew  -f ingress.yaml

Example App을 이용한 테스트

Service manifest 파일을 생성한다.

##
## Filename: service.yaml
##
apiVersion: v1
kind: Service
metadata:
  name: andrewapp          # 이 값이 위 ingress에서 설정한 'serviceName: andrewapp'과 일치해야 한다.
spec:
  ports:
  - port: 80               # 이 값이 위 ingress에서 설정한 'servicePort: 80'과 일치해야 한다.
    protocol: TCP
    targetPort: 80
  selector:
    app: mymusic
  type: ClusterIP

위에서 작성한 yaml을 kubernetes cluster에 적용한다.

$ kubectl apply  -n andrew  -n service.yaml

실제 application이 돌아가는 예제 Web 서버를 구동한다.

##
## deploy.yaml
##
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mymusic
spec:
  selector:
    matchLabels:
      app: mymusic
  replicas: 1
  template:
    metadata:
      labels:
        app: mymusic           # service.yaml에서 사용한 selector 정보와 동일해야 한다.
    spec:
      containers:
      - name: mymusic
        image: nginx:1.14.2
        ports:
        - containerPort: 80

위에서 작성한 yaml을 kubernetes cluster에 적용한다.

$ kubectl apply  -n andrew  -n deploy.yaml

PC에서 Web browser로 접속한다.

주소는 ingress object에 설정했던 ‘andrewapp.peter.space/......’이다.

짜잔~~~  Web Page가 잘 보일 것이다.

MetalLB v0.13.x  설치 및 테스트 (2023년 2월 14일)

MetalLB의 버전에 따라 설치 결과가 조금씩 달라서 MetalLB를 설치한 날짜를 밝힌다.

아래 절차를 따라하면 MetalLB 설치, 그리고 예제 앱 테스트 모두 잘 동작한다.

MetalLB 설치에 관한 공식 문서는 아래 Web Docs를 참고
   https://metallb.universe.tf/installation/

위 Web Docs는 여러 도구를 이용한 설치 방법을 설명하지만, 나는 Manifest  방식을 이용하여 MetalLB를 설치했다.

위 Web docs를 보면서 따라해보면, 막힘없이 쭉쭉~ 잘 설치되었다.

설치 완료한 이후에 LB 테스트를 해봤는데 잘 동작했다.

내가 설치한 환경은 이렇다.

Kubernetes: v1.25.3
CNI: Calico v3.24.5

내가 Web docs를 보면서 수행했던 명령 및 설정 파일 편집한 내역만 추려보면 이렇다.

strict ARP mode 활성화하기

아래 예제처럼 kube-proxy  configmap을 수정한다. 

(strictARP 항목을 false 에서 true 로 변경)

## 아래 명령을 수행
$  kubectl edit configmap -n kube-system kube-proxy

... 중간 생략 ...

apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
mode: "ipvs"
ipvs:
  strictARP: true  ## 이 부분을 수정한다.  false -> true

... 중간 생략 ...

Manifest 이용하여 Metal LB 설치하기

아래 명령을 따라서 수행한다.

$  kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.13.7/config/manifests/metallb-native.yaml


##
## MetalLB가 잘 설치되었다면,
## 아래와 같이 metallb-controller와 metallb-speaker pod가 Running 상태로 보일 것이다.
##

$  kubectl get -n metallb-system pod
NAME                          READY   STATUS    RESTARTS   AGE
controller-84d6d4db45-g94mh   1/1     Running   0          31s
speaker-6jqzw                 1/1     Running   0          31s
speaker-hlrg7                 1/1     Running   0          31s
speaker-sq94q                 1/1     Running   0          31s


## 참고: speaker가 running 상태가 되려면 대략 25~30초 정도 걸린다.
##      Pod의 상태가 ConfigErr로 보인다고 당황해하지 않아도 된다.
##      30초 후에 Running 상태로 변경될거다.

IP Address Pool 설정하기

$  cat >> my-network.yaml <<-EOF

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: first-pool
  namespace: metallb-system
spec:
  addresses:
  - 10.1.4.160/28
  - 10.1.4.176/28
  - 10.1.4.192-10.1.4.200

---

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: second-pool
  namespace: metallb-system
spec:
  addresses:
  - 10.1.4.150-10.1.4.159


---


apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: my-network-l2
  namespace: metallb-system
spec:
  ipAddressPools:
  - first-pool
  - second-pool
  
EOF

$  kubectl apply -n metallb-system -f my-network.yaml

ipaddresspool.metallb.io/first-pool created
ipaddresspool.metallb.io/second-pool created
l2advertisement.metallb.io/my-network-l2 created

$

주의할 점:
  위와 같이 L2Advertisement, IPAddressPool을 변경하고 적용해도 실제로 Service resource가 생성될 때,
  과거의 IPAddressPool을 이용한다.
  아마 MetalLB  버그 같은데, 과감하게 metallb-system 네임스페이스의 controller pod를 종료시키고 재기동하면 
  새로운 IPAddressPool이 적용된다. (아래 명령을 참고)

$ kubectl get -n metallb-system pod -l component=controller

NAME                          READY   STATUS    RESTARTS   AGE
controller-84d6d4db45-vgt9r   1/1     Running   0          6m12s

$ kubectl delete -n metallb-system pod controller-84d6d4db45-vgt9r

## 20초 정도 후에 Pod가 재기동되고, 그 뒤로 새로운 IPAddressPool이 정상적으로 반영된다.

Example App을 이용하여 MetalLB 동작 확인

$  cat >> my-example.yaml <<-EOF
apiVersion: v1
kind: Pod
metadata:
  name: almighty
  labels:
    app: almighty
spec:
  terminationGracePeriodSeconds: 3
  containers:
  - name: almighty
    image: docker.io/andrewloyolajeong/almighty:0.2.4

---

apiVersion: v1
kind: Service
metadata:
  name: almighty
spec:
  type: LoadBalancer
  externalTrafficPolicy: Local
  selector:
    app: almighty
  ports:
    - name: myweb
      protocol: TCP
      port: 8080
      targetPort: 8080
    - name: yourweb
      protocol: TCP
      port: 80
      targetPort: 80

EOF

$

$  kubectl create ns ns1


$  kubectl apply -n ns1 -f my-example.yaml


$  kubectl get -n ns1 svc

NAME       TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)                       AGE
almighty   LoadBalancer   10.104.156.217   10.1.4.150    8080:30859/TCP,80:31917/TCP   116s

$

##
## 위 결과에서 EXTERNAL-IP에 적절한 IP Address가 출력되면, 잘 되는 것이다.
## 그리고 아래와 같이 실제로 MetalLB가 할당해준 10.1.4.150 주소를 통해 Networking이 되는지 확인한다.
##

$  curl 10.1.4.150:8080

 Hello from example application. (written by Andrew)
 
$  curl 10.1.4.150:80

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
...
...
<p><em>Thank you for using nginx.</em></p>
</body>
</html>

$

올레~~~ 잘 동작한다 ^^

참고:  ping 명령으로 EXTERNAL-IP 통신 여부를 확인하지 말 것 !!!

MetalLB 설치하고, 많은 사용자들이 실수하는 것이 아래처럼 ping 명령으로 External-IP로 ICMP 패킷이 전달되는지 체크한다.

$ ping 10.10.12.43

MetalLB가 만든 External-IP 주소는 K8S Cluster의 특정 Worker Node의 Netfilter에만 존재하는 Chain Rule일 뿐이다.

즉, OS Kernel이 물린 Network Port의 MAC Address에 Binding한 IP Address가 아니다보니, OS Kernel이 ICMP Echo Request에 대해 반응할리 없다. 단, K8s LoadBalancer 구현체(즉, MetalLB)의 구현에 따라서 MetalLB가 직접 ICMP Echo Response를 만들 수는 있지만, 이것은 구현체의 버전에 따라 다를 수 있으니까 ICMP Echo(즉, Ping)에 대한 테스트를 시도하지 않는 것이 좋다.

아래와 같이 CURL을 이용하여 테스트하는 것이 정확한 테스트 방법이다.

$ curl  https://10.10.12.43:8443

다시 한번 강조한다.  절대 ping 명령으로 MetalLB의 External-IP 동작 유무를 체크하지 말자 !!!

참고:  Address 설정은  모든 대역의 주소가 다 가능한다.

아래 설정 예제처럼 특정 addresses 대역을 사용하겠다고 지정하면, MetalLB Speaker가 알아서 동일한 Broadcast Domain에 해당하는 Network Port로 GARP(Gratuitous ARP)를  Broadcasting한다.

$  vi metallb/values.yaml
... 중간 생략 ...
configInline:
  address-pools:
   - name: default
     protocol: layer2
     addresses:
     - 10.10.12.40/29
... 중간 생략 ...

따라서 Worker Node에 Network Port가 여러 개 있다면, 위 address-pools에 설정된 ip address 대역 중에서 broadcast domain이 일치하는 Network Port로 GARP 패킷이 흘러나간다.

참고:  특정 Service에 특정 External-IP(Public IP)를 고정해서 사용하기

External-IP는 Kubernetes Cluster 밖에 있는 Client App이 접근하기 위한 주소이기 때문에 고정하는게 운영상 편하다.

그런데 MetalLB는 IP Address Range를 설정하도록 되어 있기 때문에 K8s Service 생성시 어떤 External-IP가 K8s Service에 할당될지 알 수 없다.

이럴 때 아래와 같이 K8s Service에 설정을 추가하면 특정 External-IP(즉, Public IP Address)를 고정해서 사용할 수 있다.

$ cat  my-svc.yaml

apiVersion: v1
kind: Service
metadata:
  name: mysvc
  
(... 중간 생략 ...)

spec:
  type: LoadBalancer
  ## MetalLB의 IP Address Range가 211.10.3.160 ~ 190 이라고 가정하고
  ## 이 mysvc에 211.10.3.165 주소를 고정해서 사용하고 싶아면 아래와 같이 사용한다.
  loadBalancerIP: 211.10.3.165

(... 중간 생략 ...)

게시물 작성자: sejong.jeonjo@gmail.com