반응형

 


 

 

Rook를 이용하여 Ceph 설치한 날짜: 2023년 2월 1일
Rook version: 1.10.10
Ceph version: 17.2.5(quincy) and 15.2.17 (octopus)      ## 이 두 버전 모두 잘 동작했다.

 

지난 2년 동안 NFS server를 이용하여 Kubernetes PV(Persistent Volume)의 Storage로 사용했었는데, 별로 좋지 않음을 경험하고는 Ceph를 사용해야겠다는 결단이 생겼다.

Ceph 설치가 만만치 않은 작업이지 않을까 걱정했는데, 괜한 걱정이었다.

Rook operator official document의 설명을 따라서 설치하니까 30분 만에 Ceph cluster가 뚝딱하고 만들어졌다.

Test용 Example App까지 Rook operator에 포함되어 있어서 Test까지 다 포함해서 1시간이 채 안 걸렸다.

 

일단, 아래 공식 문서인 Rook Ceph document를 읽고 따라하면 일사천리로 설치와 테스트가 모두 끝난다.

 

 

Quickstart - Rook Ceph Documentation

Quickstart Welcome to Rook! We hope you have a great experience installing the Rook cloud-native storage orchestrator platform to enable highly available, durable Ceph storage in your Kubernetes cluster. If you have any questions along the way, please don'

rook.io

 

 


그럼... 설치를 시작해보자 !

 

설명은 위 공식 문서에 있으니까, 설정을 생략하고 명령만 적어 놓겠다. 

그냥 아래 명령어를 따라 수행하면 된다. 

 

Ceph 설치 전에 준비할 내용:
  Kubernetes worker node에 Ceph가 Storage로 사용할 Raw device가 있어야 한다.
  (즉, 한번도 사용하지 않은 깨끗한 SSD, HDD 같은 것이 필요하다. Format이 안 되어 있어서 Filesystem도 없는 상태면 딱 좋다.)
  나는 깡통 qcow2 이미지를 각 worker node의 Virtual disk로 사용했다.
  그리고 Ceph는 3-node cluster로 구성할 것이니까, worker node 3개에 각각 Raw device가 1개씩 있어야 한다.

모든 worker node에 Raw device를 추가 장착했다면, 아래와 같이 `lsblk -f` 명령을 수행하여 깡통 상태의 Storage가 있는지 확인한다.

아래 명령 결과에서 vdb가 아무도 사용하지 않는, 그리고 formatting도 하지 않은 완전한 깡통 상태의 Storage 이다.

$  lsblk -f

NAME                  FSTYPE      LABEL UUID                                   MOUNTPOINT
vda
└─vda1                LVM2_member       >eSO50t-GkUV-YKTH-WsGq-hNJY-eKNf-3i07IB
  ├─ubuntu--vg-root   ext4              c2366f76-6e21-4f10-a8f3-6776212e2fe4   /
  └─ubuntu--vg-swap_1 swap              9492a3dc-ad75-47cd-9596-678e8cf17ff9   [SWAP]

vdb    ## <- 이 "vdb" 저장 장치와 같이 아무 설정도 없는 상태의 Storage가 있어야 한다.

$

모든 workder node에서 위 명령으로 vdb storage 정보를 확인했다면, 이제 본격적으로 설치 작업을 한다.

 

 

아래 명령은 kubernetes bastion node 또는 kubectl 수행이 가능한 PC에서 수행한다.
########################################################################
## GitHub에서 Rook operator를 내려 받는다.
########################################################################
$  git clone --single-branch --branch v1.10.10 https://github.com/rook/rook.git

$  cd rook/deploy/examples


########################################################################
## Rook operator 운영에 필요한 custom resource definition을 생성하고
## Rook operator 리소스를 kubernetes cluster에 배포한다.
########################################################################
$  kubectl create -f crds.yaml -f common.yaml -f operator.yaml

########################################################################
## 참고:
##   내가 테스트할 때, 위 명령으로 ceph operator를 구동하고, 바로 아래의 cluster를
##   구축하려고 하니까 OSD orchestration 단계에서 실패했다.
##   정확한 원인은 모르겠는데, operator 구동 시작 후 20초 정도 기다렸다가 cluster 구축
##   하는 명령을 수행하면 오류없이 잘 cluster가 구축되었다.
########################################################################

########################################################################
## rook-ceph-operator pod가 running 상태인지 확인한다.
########################################################################
$  kubectl -n rook-ceph get pod


########################################################################
## Ceph cluster를 생성한다.
########################################################################
$  kubectl create -f cluster.yaml

########################################################################
## 주의:
##   내가 사용한 CPU는 "Intel(R) Xeon(R) E-2124G CPU @ 3.40GHz" 인데,
##   이 CPU를 사용했을 때 Ceph cluster 구성이 완료되려면 대략 3분 정도 시간이 걸렸다.
##   따라서, 아래와 같이 rook-ceph-operator 로그를 보면서 진행 과정을 보는 것이 좋다.
##   대략 3분 정도 로그가 올라가다가 마지막 부분에 "op-osd: finished .... "
##   이런 문구가 출력되면 작업이 끝난 것이다.
########################################################################
$  kubectl -n rook-ceph logs -l app=rook-ceph-operator -f

... 중간 생략 ...

2023-01-06 07:05:19.680387 I | cephclient: successfully disallowed pre-quincy osds and enabled all new quincy-only functionality
2023-01-06 07:05:19.681868 I | op-osd: finished running OSDs in namespace "rook-ceph"
2023-01-06 07:05:19.682577 I | ceph-cluster-controller: done reconciling ceph cluster in namespace "rook-ceph"

<< 위 문장이 출력되면, 끝난 것이다. Ctrl+C 키를 눌러서 kubectl log 명령을 종료시킨다 >>

########################################################################
## 만약 3분이 지났는데 'done reconciling ceph cluster ..." 로그가 출력되지 않는다면
## cluster, operator, crds를 모두 삭제하고 다시 시작해야 한다.
##  (예: kubectl delete -f cluster.yaml -f operator.yaml -f ...)
########################################################################

########################################################################
## Ceph 관련 pod가 running 상태인지 확인한다.
########################################################################
$  kubectl -n rook-ceph get pod
NAME                                                 READY   STATUS      RESTARTS   AGE
csi-cephfsplugin-provisioner-d77bb49c6-n5tgs         5/5     Running     0          140s
csi-cephfsplugin-provisioner-d77bb49c6-v9rvn         5/5     Running     0          140s
csi-cephfsplugin-rthrp                               3/3     Running     0          140s
csi-rbdplugin-hbsm7                                  3/3     Running     0          140s
csi-rbdplugin-provisioner-5b5cd64fd-nvk6c            6/6     Running     0          140s
csi-rbdplugin-provisioner-5b5cd64fd-q7bxl            6/6     Running     0          140s
rook-ceph-crashcollector-minikube-5b57b7c5d4-hfldl   1/1     Running     0          105s
rook-ceph-mgr-a-64cd7cdf54-j8b5p                     1/1     Running     0          77s
rook-ceph-mon-a-694bb7987d-fp9w7                     1/1     Running     0          105s
rook-ceph-mon-b-856fdd5cb9-5h2qk                     1/1     Running     0          94s
rook-ceph-mon-c-57545897fc-j576h                     1/1     Running     0          85s
rook-ceph-operator-85f5b946bd-s8grz                  1/1     Running     0          92m
rook-ceph-osd-0-6bb747b6c5-lnvb6                     1/1     Running     0          23s
rook-ceph-osd-1-7f67f9646d-44p7v                     1/1     Running     0          24s
rook-ceph-osd-2-6cd4b776ff-v4d68                     1/1     Running     0          25s
rook-ceph-osd-prepare-node1-vx2rz                    0/2     Completed   0          60s
rook-ceph-osd-prepare-node2-ab3fd                    0/2     Completed   0          60s
rook-ceph-osd-prepare-node3-w4xyz                    0/2     Completed   0          60s


########################################################################
## Rook toolbox를 이용하여 Ceph cluster 상태 정보를 조회한다.
##   toolbox에 대한 자세한 설명은 아래 Web document를 확인
##     https://rook.io/docs/rook/v1.10/Troubleshooting/ceph-toolbox/
########################################################################

########################################################################
## Rook toolbox를 설치한다.
########################################################################
$  kubectl create -f deploy/examples/toolbox.yaml


########################################################################
## Rook toolbox pod 내부에서 `ceph status` 명령을 수행하여 ceph cluster 상태를 조회한다.
########################################################################
$  kubectl -n rook-ceph exec -it deploy/rook-ceph-tools -- bash
  
bash-4.4$ ceph status
  cluster:
    id:     661d89a0-d4c5-432b-97d7-6a4d06beaf52
    health: HEALTH_OK

  services:
    mon: 3 daemons, quorum a,b,d (age 10m)
    mgr: b(active, since 11m), standbys: a
    osd: 3 osds: 3 up (since 10m), 3 in (since 11m)

  data:
    pools:   1 pools, 1 pgs
    objects: 2 objects, 449 KiB
    usage:   62 MiB used, 750 GiB / 750 GiB avail
    pgs:     1 active+clean

bash-4.4$
bash-4.4$
bash-4.4$
bash-4.4$ ceph df
--- RAW STORAGE ---
CLASS     SIZE    AVAIL    USED  RAW USED  %RAW USED
hdd    750 GiB  750 GiB  62 MiB    62 MiB          0
TOTAL  750 GiB  750 GiB  62 MiB    62 MiB          0

--- POOLS ---
POOL  ID  PGS   STORED  OBJECTS     USED  %USED  MAX AVAIL
.mgr   1    1  449 KiB        2  1.3 MiB      0    237 GiB

bash-4.4$ exit

$

 

 

예제 App을 이용하여 Ceph 동작 유무를 확인한다.

 

 

###############################################################################
## `git clone`한 소스 코드에 examples 디렉토리가 있다.
## examples 디렉토리로 이동하여 예제 App을 구동해보자.
## 당연히, 위 Ceph에서 PV를 할당받는 예제이다.
###############################################################################
$  cd /deploy/examples

###############################################################################
## 예제 App이 사용할 StorageClass를 생성한다.
###############################################################################
$  kubectl apply -f csi/rbd/storageclass.yaml
cephblockpool.ceph.rook.io/replicapool created
storageclass.storage.k8s.io/rook-ceph-block created

$  kubectl create -f mysql.yaml
service/wordpress-mysql created
persistentvolumeclaim/mysql-pv-claim created
deployment.apps/wordpress-mysql created

$  kubectl get pvc
NAME             STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS      AGE
mysql-pv-claim   Bound    pvc-6d458ff1-54bf-4f34-b010-a0f4b2a0966e   20Gi       RWO            rook-ceph-block   94s

$  kubectl create -f wordpress.yaml
service/wordpress created
persistentvolumeclaim/wp-pv-claim created
deployment.apps/wordpress created

$  kubectl get pod
NAME                               READY   STATUS    RESTARTS   AGE
wordpress-7cf5c5c8b-5cgqk          1/1     Running   0          42s
wordpress-mysql-6f99c59595-9vs7z   1/1     Running   0          4m8s

$  kubectl get svc  wordpress
NAME              TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
wordpress         LoadBalancer   10.96.232.248   10.1.4.160    80:31494/TCP   27s

 

참고로, wordpress pod가 구동되고 1분 정도 경과된 후에 Web browser로 접속하는 것이 좋다.
(wordpress가 MySQL DB에  초기 설정값을 만드느라 시간을 좀 쓰는 듯...)

 

Web browser를 이용하여 EXTERNAL-IP에 출력된 주소로 접속해보자.

아래처럼 Wordpress 설정 화면이 출력되면, 정상 동작하는 것이다.

 

 

 

Ceph를 설치하고, Storage를 할당 받아서 PV(Persistent Volume)을 사용하는 것까지 완벽하게 동작한다.

 

 


 

Ceph Dashboard

아래의 Web Docs를 보고 따라 설정하면 된다.

 

1) Prometheus를 먼저 설치한다.

 

Prometheus Monitoring - Rook Ceph Documentation

Prometheus Monitoring Each Rook Ceph cluster has some built in metrics collectors/exporters for monitoring with Prometheus. If you do not have Prometheus running, follow the steps below to enable monitoring of Rook. If your cluster already contains a Prome

rook.io

2) Dashboard를 설치한다.

 

Ceph Dashboard - Rook Ceph Documentation

Ceph Dashboard The dashboard is a very helpful tool to give you an overview of the status of your Ceph cluster, including overall health, status of the mon quorum, status of the mgr, osd, and other Ceph daemons, view pools and PG status, show logs for the

rook.io

 

위 설명을 따라하면, 아래와 같이 Web UI, Dashboard를 볼 수 있다.

Ceph Dashboard / Cluster 상태 정보 조회

 

Ceph Dashboard / OSD 정보 조회

 

Ceph Dashboard / Pool list 조회


 

참고: Ceph 관련하여 읽으면 도움이 되는 문서

SKT TACO(Openstack) 개발자가 직접 Ceph를 설치하면서 작성한 블로그. 

 

K8S 클러스터의 영구저장소로 ceph 사용하기

 

devocean.sk.com

 

 

SKT Kubernetes solution(TKS) 개발자 "엄주관" 님이 직접 Rook를 이용하여 Ceph 및 예제 앱을 설치하면서 작성한 블로그.  

 

Kubernetes 스토리지 오퍼레이터 Rook 맛보기

 

devocean.sk.com

 

 


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

 

 

반응형

Amazon EKS, Azure AKS, Google GKE 등과 비슷하게 Oracle OKE에서도 Network LB가 제공된다.

 

Managed Kubernetes를 사용할 때 항상 등장하는 Load Balancer와 Network Load Balancer가 비슷하면서 약간 다른데,

Oracle Cloud Infrastructure의 User Manual에는 아래와 같이 설정하고 있다.

 

 

Load Balancer

Oracle OKE - Load Balancer

  A Load Balancer improves resource utilization, facilitates scaling, and helps ensure high availability. You can configure multiple load balancing policies and application-specific health checks to ensure that the load balancer directs traffic only to healthy instances. Includes: advanced proxy features such as layer-7 routing and SSL termination.

그림에서 묘사한 것처럼

  • HTTP
  • HTTPS
  • TCP

프로토콜을 사용하는 Backend 서비스만 지원한다. 

따라서 UDP나 Dedicated Protocol을 사용하는 Backend 서비스가 있는 경우에 이 LB를 사용할 수 없다. ㅠㅠ

 

Network Load Balancer (일명, NLB)

Oracle OKE - Network Load Balancer (NLB)

A Network Load Balancer is a non-proxy layer-4 load balancing solution. It offers a scalable VIP to the customer and additionally provides the benefits of flow high availability, low latency, and source IP and port preservation.
Includes: layer-4 pass-through load balancing and client header preservation.

그림에서 묘사한 것처럼

  • TCP
  • UDP                                             # <-- 이것이 LB와 NLB가 다른 부분이다. 
  • 기타... 아무거나 다 (Any ~~~)      # <-- 이것이 LB와 NLB가 다른 부분이다.  

프로토콜을 사용하는 Backend 서비스를 지원한다. 

그런데 Oracle Cloud Infra에서는 이 NLB(Network LB)는 3개까지만 사용하도록 제한하고 있다.

OCI Web Console에서는 이 NLB Max Limit을 설정하는 메뉴가 안 보이는데, 아마 Oracle에 직접 전화해서 NLB 개수를 Upgrade해야 하는 것 같다. (아직, 확실하진 않고... 내일 Oracle에 한번 전화해서 물어봐야겠다..)

반응형

Public Cloud의 Kubernetes(예: AWS AKS, Azure AKS, Oracle OKE 등)을 사용하다보면,

Public Network에서 들어오는 UDP 트래픽을 Network LB(NLB)가 처리하지 못하는 것처럼 보일 때가 있다.

 

예를 들어 아래와 같은 Service Manifest를 적용했다고 가정해보자.

 

apiVersion: v1
kind: Service
metadata:
  name: almighty
  annotations:
    oci.oraclecloud.com/load-balancer-type: "nlb"  # <- 이 내용을 추가해야 한다.
spec:
  selector:
    app: almighty
  ports:
    - name: myweb
      protocol: TCP
      port: 8080
      targetPort: 8080
    - name: yourweb
      protocol: TCP
      port: 80
      targetPort: 80
    - name: myudp
      protocol: UDP       # <- 테스트를 위해 UDP를 추가한다.
      port: 9090
      targetPort: 9090
  type: LoadBalancer      # <- Service Type을 LoadBalancer로 설정한다.

 

위 Service Manifest를 적용하면, External-IP 항목이 Public IP 값으로 설정되지만 실제로 Pod로 UDP 트래픽이 전달되지 못하는 현상이 생길 것이다.

 

왜 이런 문제가 생길까?

 

Public Network에서 유입되는 UDP 트래픽이 Pod에 전달되지 못하는 정확한 원인은 아래와 같다.

Public Cloud Service 제공사가 제공하는 NLB(Network Load Balancer)는 제대로 UDP 트래픽을 처리한 것이 맞다.

단지, Cloud Infra가 제공하는 K8S Node의 Security Rule에 의해서 UDP 트래픽이 Block되는 것이다.

따라서 Security Rule에 UDP 트래픽이 Pass 되도록 Rule을 추가하기만 하면 된다. (즉, Linux Firewall 설정 하듯이~)

 

AWS AKS, Azure AKS, Oracle OKE 모두 비슷하게 NLB가 UDP 트래픽을 처리하고 Security Rule도 비슷하기 때문에 Oracle의 OCI OKE만 이용해서 설명하면 아래와 같다.

 

아래의 순서로 메뉴/화면을 찾아서 들어간다.

[ Kubernetes Clusters (OKE) ]

-> Clusters 화면에서 특정 Cluster의 VCN을 선택/클릭한다.

-> VCN을 클릭하면, 여러개의 Subnets이 목록이 보여지는데 oke-svclbsubnet-xxxxoke-nodesubnet-yyyy을 선택하여 Security Lists를 확인한다.

-> [ Security Lists ] 화면에 있는 Rule 이름을 선택한다.

-> [ Ingress Rules ]와 [ Egress Rules ] 화면에서 UDP, TCP 트래픽을 모두 허용하도록 Rule을 추가한다.

     예를 들어, 115.33.55.0/24, 특정 UDP 포트(예: 9090), 특정 TCP 포트(예: 8080) 허용으로 설정하면 된다.

 

아래 화면을 참고~~~

 

 

 

이렇게 Security Rule을 추가하고, 다시 Public IP와 UDP 포트를 이용하여 트래픽을 보내보면, Pod 내부까지 UDP 트래픽이 잘 전달되는 것을 확인할 수 있다.

 

 


조심해야 할 사항:
  Security Rule 설정하고, 40초 후에 Traffic Test해야 한다.
  Node Security Rule이 적용되기 까지 40초가 걸리기 때문에 그 이후에 Traffic Test를 해야 제대로 Traffic이 Pod까지 전달된다.
  

 


생각해볼 내용:
  Node Security List에 TCP Rule을 추가할 때, 왜 Egress Rule도 추가해야 하는지 잘 이해가 안 된다.
  Cluster 외부에서 Ingress Rule에 따라 TCP Traffic을 허용해주면, ConnTrack DB에 Pin Hole 같은게 생기면서
  TCP의 응답 패킷도 알아서 Pass(Forward)시켜주는게 일반적인 Traffic 처리가 아닐까라고 생각했는데... 이게 아닌가 보다.
  아무튼 귀찮지만 Ingress에 추가한 Rule을 Egress에도 꼭 추가해야 한다. (잊지 말자 !!!)

 

 

 

 

참고하면 좋은 Web Docs

Oracle OCI Network Load Balancer 사용하기

https://thekoguryo.github.io/release-notes/20220315-support-for-oci-network-load-balancers/

 

Support for OCI Network Load Balancers

OKE에서 Service Type을 Load Balancer를 사용할때 이제는 OCI Network Load Balancer을 추가적으로 지원합니다.

thekoguryo.github.io

 

위 문서는 간단하게 사용법 위주로 설명되어 있고, 아래 문서는 내부 동작에 관해 자세하게 내용을 다루고 있다.

특히, Service Manifest의 externalTrafficPolicy: local 방식에 관해 궁금하다면 아래 문서를 보는 것이 좋다.

 

https://blogs.oracle.com/cloud-infrastructure/post/network-load-balancer-support-on-oracle-kubernetes-engine

 

Using a network load balancer for Kubernetes services

Announcing network load balancer support on Oracle Container Engine for Kubernetes.

orasites-prodapp.cec.ocp.oraclecloud.com

 

더 자세히 파고 들어가고 싶다면, Oracle 공식 Web Docs를 보길~~~

 

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

 

Defining Kubernetes Services of Type LoadBalancer

Include in the backend set:

docs.oracle.com

 

반응형

 

준비 작업: Oracle Cloud 사용을 위한 계정 생성

아래 Web Page에서 Oracle Cloud 사용을 위해서 Account를 생성한다.

https://cloud.oracle.com/

 

내 경우, 계정 생성하다가 마지막 "검증" 단계에서 실패했는데  Oracle에 전화해서 물어보니 

요즘 Block Chain Mining을 위해 Cloud Infra를 악용하는 사례가 있어서

계정 생성시 입력한 정보 중에서 블랙 해커로 의심되는 정보가 있으면, Oracle Machine Learning이 계정 생성을 Blocking 한다고 설명해줬다.

혹시 계정 생성하다 실패하면, 계정 정보를 다르게 해서 다시 생성하는 것이 정신 건강에 좋다.

 

 

OKE Cluster 생성하기

Oracle Cloud의 TOP 메뉴에서

[ Developer Services ] -> [ Kubernetes Cluters (OKE) ]

순서로 메뉴를 클릭하고, Quick Start 방식로 몇 가지 기본 설정 값만 정해주면 너무나 간단하게 Kubernetes Cluster가 생성된다.

 

주의: 
동일한 Spec의 Cluster 구축이라고 하더라도 Cluster Infra 상황에 따라 어떤 경우는 5분만에 Cluster가 생성되고,
어떤 경우는 15분이 넘도록 Cluster 생성이 완료되지 않는다.
그래서 마음편하게, Cluster 생성 버튼을 누르고 20분 정도 다른 업무를 하다가 오는 것이 좋다.

 

내 PC (Macbook)에서 OKE Cluster에 접근하기 (Bastion 구성)

Oracle이 너무 간단하게 만들어 놓아서 굳이 장황하게 설명할게 없다.

아래 Web Page에서 아래 빨간 번호 순서로 따라 하기만 하면 된다.

당연한 말이겠지만, 내 Macbook은 Public Network을 통해서 Oracle Cloud Infra에 접근해야 하니까, 아래 그림의 (6)번 절차에서 "VNC-Native public endpoint"와 관련된 명령을 복사해서 내 Macbook의 iTerm에 붙여 넣어야 한다.

 

 

위 절차를 끝낸 후, 내 Macbook의 iTerm 터미널에서 아래와 같이 명령을 수행하면 명령이 잘 수행되는 것을 확인할 수 있다.

 

$  kubectl  get node
NAME          STATUS   ROLES   AGE     VERSION
10.0.10.121   Ready    node    3m7s    v1.24.1
10.0.10.124   Ready    node    2m59s   v1.24.1
10.0.10.127   Ready    node    2m55s   v1.24.1
$

 

 

주의:
위 절차를 따라할 때, (5) ~ (6) 단계 사이에서 아래의 명령을 한번 수행해야 한다.
기존에 사용하던 KUBECONFIG 환경 변수가 설정된 경우라면, (6) 단계가 실패한다.
$  unset KUBECONFIG

 

 

 

Tip:
  [ Multi cluster를 운영하는 경우 ]
  예를 들어서 OKE kubernetes에서 cluster2, cluster3 등 2개의 cluster를 생성하여 운영하는 경우라면
  아래와 같이 .kube/config 파일 이름을 변경해서 사용하는 것을 추천.

 

$ mv $KUBECONFIG/config $KUBECONFIG/config.cluster2


$ cat .bashrc

... 중간 생략 ...

function use-oke-cluster2() {
  AA=$(printf "\033[")
  export KUBECONFIG=~/.kube/config.cluster2
  echo "${AA}32m"
  echo "Cluster Name      :" $(cat $KUBECONFIG | yq '.clusters[0].name')
  echo "Cluster API Server:" $(cat $KUBECONFIG | yq '.clusters[0].cluster.server')
  echo "${AA}0m"
}

... 중간 생략 ...

$ use-oke-cluster2

Cluster Name      : cluster-cja9kqodr9l
Cluster API Server: https://193.135.212.37:6443

$ kubectl get node
NAME          STATUS   ROLES   AGE    VERSION
10.0.10.115   Ready    node    11d    v1.25.4
10.0.10.117   Ready    node    11d    v1.25.4
$
반응형

2022년 11월 현재,  EFK(ElasticSearch, FluentBit, Kibana)를 설치해보려 한다.

공식 홈피에서 자료를 찾아서 읽고, 설치해야 하겠지만

오늘은 업무 때문에 해야 할 일이 많고, 여유 시간이 없어서 아래의 블로그를 읽고 따라해보려 한다.

만약 EFK 구축이 잘 되면, 추가로 글을 남겨보겠다 ^^

 

 

https://heartsavior.medium.com/kubernetes-%EC%97%90%EC%84%9C-efk-elasticsearch-fluentbit-kibana-stack-%EC%84%A4%EC%B9%98%ED%95%98%EA%B8%B0-17a4866a018

 

Kubernetes 에서 EFK (ElasticSearch/FluentBit/Kibana) stack 설치하기

역시 마찬가지로 디테일은 없다. 디테일은 레퍼런스 문서를 참고하자.

heartsavior.medium.com

 

반응형

 

Kubernetes Cluster를 설치한 날짜: 2022년 12월 21일

 


참고:
한땀 한땀 설치 과정을 이해하고 테스트하면서 kubernetes 내부 구성을 스터디하는 것이 목적이 아니라면,
아래 블로그를 읽고 kubespray로 설치하는 것을 추천한다.
  https://andrewpage.tistory.com/305

https://andrewpage.tistory.com/305

 

 

 

 

Kubernetes cluster(쿠버네티스 클러스터) 구축을 도와주는 여러 도구(kubeadm, kubespray, kops)가 있다.

이 문서에는 그런 kubernetes cluster 구축 도구 중에서 kubeadm을 이용하여 kubernetes cluster를 구축하는 방법을 설명한다.

 

참고로, kubeadm 도구가 가장 수작업이 많고 사람 손을 많이 탄다. 

그렇지만 Kubernetes 내부 구성을 이해하고 싶거나 작동 원리를 알고 싶다면 kubeadm 도구를 이용해서 설치하면 좋다.

즉, kubernetes를 공부하는 것이 목적이라면 kubeadm 관리 도구를 사용하는 것을 추천한다.

 

 

Kubernetes Cluster 구축을 위한 계획하기

Ubuntu 22.04 를 설치한 Master node와 Worker node를 준비한다.

  • Master Node: 1개 (master-0)
  • Worker Node: 2개 (worker-0, worker-1)

 

Master Node와 Worker Node 준비 작업

master node와 worker node 모두에서 아래의 작업을 수행한다.

kubernetes는 iptables를 이용하여 pod간 통신을 가능하게 한다. 따라서 iptables가 정상 동작하도록 하기 위해 아래와 같이 설정한다.

 

cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF

sudo modprobe overlay
sudo modprobe br_netfilter

# sysctl params required by setup, params persist across reboots
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-iptables  = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward                 = 1
EOF

# Apply sysctl params without reboot
sudo sysctl --system

 

모든 master node, worker node에서 swap 영역을 비활성화한다.

 

$  sudo sed -i '/swap/d' /etc/fstab

##
## 또는 위와 명령 대신, /etc/fstab 파일을 열어서 swap 과 관련있는 filesystem 항목을
## 주석으로 막아도 된다.
##

$  sudo swapoff -a

$  free -h
              total        used        free      shared  buff/cache   available
Mem:            15G        1.0G         13G         13M        925M         14G
Swap:            0B          0B          0B
$

 

방화벽(Firewalld)를 비활성화한다.

(원칙은 kubernetes가 사용하는 service port만 allow 설정해야 하지만, 여기서는 간단하게 firewalld를 종료하는 것으로 하겠다)

$  systemctl stop firewalld
$  systemctl disable firewalld

 

 

Container Runtime Interface(CRI) 설치하기 (여기서는 CRI-O를 설치!)

master node와 worker node 모두에서 아래의 작업을 수행한다.

$ sudo -s

$ apt update && sudo apt upgrade

$ OS=xUbuntu_22.04

##
## 주의: Kubernetes 1.25를 설치할 것이기 때문에
##      CRIO도 1.25를 설치하는 것이다. (즉, 2개의 버전이 일치해야 한다)
##

$ CRIO_VERSION=1.25

$ echo "deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /"|sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list

$ echo "deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$CRIO_VERSION/$OS/ /"|sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$CRIO_VERSION.list

$ curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$CRIO_VERSION/$OS/Release.key | sudo apt-key add -

$ curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | sudo apt-key add -

$ sudo apt update

$ sudo apt install cri-o cri-o-runc

$ apt show cri-o

$ systemctl enable --now crio.service

$ systemctl status crio

$ apt install cri-tools

$ crictl info

##
## cri-o가 잘 동작하는지 확인하기 위해 아래와 같이 container image를 pulling하는 테스트한다.
##

$ crictl pull busybox

$ crictl images

 

 

 

 

 

 

 


여기까지 설명이  master node, worker node에서 준비해야 할 작업이다.
이 다음 설명부터 실제 kubernetes cluster를 구축하기 위한 작업이다.

 

 


 

kubeadm, kubelet, kubectl 설치

kubeadm: kubernetes cluster를 구축하기 위한 명령 도구

kubelet: master node, worker node에서 데몬 프로세스로 기동되어 있으면서, container와 pod를 생성/삭제/상태를 감시한다.

kubectl: 사용자가 kubernetes cluster에게 작업 요청하기 위한 명령 도구 (예를 들어, 'pod를 생성해달라!'  'pod의 개수를 늘려달라!' 같은 사용자 명령을 kunernetes API server에게 전달)

 

아래의 명령을 따라 하여 kubeadm, kubelet, kubectl 명령 도구를 설치한다.

(모든 장비에서 수행해야 한다. 즉, Master Node와 Worker Node 모두에 해당하는 작업이다.)

 

$ sudo -s

##
## Update the apt package index and 
## install packages needed to use the Kubernetes apt repository:
## 

$ apt-get update

$ sudo apt-get install -y apt-transport-https ca-certificates curl


##
## Download the Google Cloud public signing key:
## 

$ curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg

##
## Add the Kubernetes apt repository:
##

$ echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list

##
## Update apt package index, install kubelet, kubeadm and kubectl, and pin their version:
##

$ apt-get update

$ apt-get install -y kubelet kubeadm kubectl

 

 

Kubernetes Cluster 생성하기

아래 명령을 master-0 node에서 수행한다.

 

##
## 주의: Master-0 노드에서만 수행해야 한다.
##

$ sudo -s

$  kubeadm init --apiserver-advertise-address 10.10.1.10
...
...


##
## Cluster 초기화는 2~3분 정도 걸린다.
## 초기화 작업이 끝나면 아래의 명령을 수행한다.
##

$ mkdir -p $HOME/.kube

$ cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

$ chown $(id -u):$(id -g) $HOME/.kube/config

 

위 명령을 수행하고 바로 Container Network Interface(CNI) 설치하는 작업을 수행해야 한다.

 

 

CNI 설치

CNI에는 많은 종류가 있지만, 사용하기 쉽고 대중적인 Calico 또는 Flannel CNI를 설치하겠다.

(Case A)  Calico를 설치하는 경우  <-- 추천

## 참고: 2023년 4월 23일 현재, v3.25.1을 설치하는 것을 권장.
$ kubectl apply  -f https://raw.githubusercontent.com/projectcalico/calico/v3.25.1/manifests/calico.yaml

##
## 주의: 위 명령을 수행하고 나서, `kubectl get pod -A` 명령으로 calico 관련 pod가 모두 기동했는지
##      확인한 후에 다음 절차를 수행해야 한다.
##

(Case B)  Flannel을 설치하는 경우 <-- 나는 개인적으로 별루~  (몇 달 운영하다가 Error  발생한 경험이 있어서)

$  kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

 

 

※ 참고

위 명령 `kubectl apply -f .......calico.yaml` 을 수행 후 CNI 설치에 문제가 있었다면, Pod 'coredns-xxxxxx'  구동하지 못하고 'pending' 상태로 남게 된다.

그런 경우는 대부분 `kubeadm init --pod-network-cidr=10.244.0.0/16` 명령을 수행했을 때 사용했던 CIDR 값이 master node, worker node의 물리 주소와 겹치는 경우에 문제가 발생한다. 따라서 '10.244.0.0/16' 값이 아닌 다른 값으로 다시 변경해서 kubernetes cluster를 생성해보면 문제가 해결될 수 있다.

 

 

잠깐:
  위 명령을 수행하고 대략 3분 쯤 지난 후, 아래와 같이 Pod의 기동 상태를 확인하자!
  모든 Pod가 Running 상태로 변경된 이후에 나머지 작업을 진행한다.
root@master-a:~# kubectl get pod -A
NAMESPACE     NAME                                       READY   STATUS    RESTARTS   AGE
kube-system   calico-kube-controllers-74677b4c5f-88gzk   1/1     Running   0          55s
kube-system   calico-node-g2dcp                          1/1     Running   0          55s
kube-system   coredns-565d847f94-8mgrs                   1/1     Running   0          3m9s
kube-system   coredns-565d847f94-gsd5q                   1/1     Running   0          3m9s
kube-system   etcd-master-a                              1/1     Running   0          3m16s
kube-system   kube-apiserver-master-a                    1/1     Running   0          3m15s
kube-system   kube-controller-manager-master-a           1/1     Running   0          3m14s
kube-system   kube-proxy-vbg6h                           1/1     Running   0          3m10s
kube-system   kube-scheduler-master-a                    1/1     Running   0          3m15s
root@master-a:~#

 

 

Worker node joining

위에서 `kubeadm init` 명령을 수행했을 때, 출력되었던 메시지 중에 `kubeadm join ....` 과 같은 형태의 메시지가 있었을 것이다.

그 메시지를 복사해서  모든 worker node에서 수행한다.

# worker-0, worker-1에서 아래의 명령을 수행한다.
kubeadm join 10.1.3.170:6443 --token pdfjgjas.psdfjbh kajsdjhasdfv \
    --discovery-token-ca-cert-hash sha256:3nasklj46kj234k5lj12k3j4gkfdjjgdsfh51a3a686

위 명령이 수행된 이후에 master-0 node에서 아래의 명령으로 cluster 구축된 결과를 확인한다.

$  kubectl get node
NAME                         STATUS   ROLES                  AGE    VERSION
master-0.kube.sejong.space   Ready    control-plane,master   3m     v1.25.2
worker-0.kube.sejong.space   Ready    <none>                 1m     v1.25.2
worker-1.kube.sejong.space   Ready    <none>                 1m     v1.25.2

 

Kubernetes cluster 삭제 (Tear down)

만약 깔끔하게 kubernetes cluster를 지우고, 처음부터 다시 구축하고 싶다면 아래와 같이 cluster를 reset 한다.

$  apt install ipvsadm

$  kubeadm reset;   rm -rf  $HOME/.kube  /etc/kubernetes;   rm -rf /etc/cni;  ipvsadm --clear

 

 

Bastion Node 설정

위 설명에서는 kubectl 명령을 master-0 node에서 수행했다.

그러나 일반적으로 master-0에 직접 SSH 접속해서 kubectl 명령을 수행하는 것을 권장하지 않는다.

kubernetes cluster node는 운영 node이기 때문에 개발자가 접속하는 것이 바람직하지 않다.

(어쩌면, 보안 규정상 개발자가 master node에 SSH 접속하는 것 자체를 허용하지 않는 회사도 있을 것이다)

따라서 master-0 node가 아닌 본인의 PC(예를 들어 MacBook 같은 PC)에서 접속하는 방법을 사용하는 것을 권장한다.

방법은 간단하다.

master-0 node에 있는 /etc/kubernetes/admin.conf 파일을 내 PC(예를 들어 Macbook)에 복사하기만 하면 된다.

# MacOS를 사용한다고 가정하고 설명하겠다.
$  mkdir -p $HOME/.kube
$  cd $HOME/.kube
$  master-0 node의 '/etc/kubernetes/admin.conf' 파일을 내 PC로 내려받는다.
$  mv  admin.conf  config

# 내 PC에서 Kubernetes cluster의 API 서버로 잘 접속하는지 아래와 같이 명령을 수행해본다.
$  kubectl get node
NAME                         STATUS   ROLES                  AGE    VERSION
master-0.kube.sejong.space   Ready    control-plane,master   128m   v1.25.2
worker-0.kube.sejong.space   Ready    <none>                 126m   v1.25.2
worker-1.kube.sejong.space   Ready    <none>                 126m   v1.25.2
$

 


 

이 아래 부분에서 설명하는 작업 절차는 Kubernetes를 운영하는 데 있어서 꼭 필요한 것은 아니고, Web Dashboard로 좀 더 예쁘게 Kubernetes cluster를 모니터링하고 싶은 경우에 아래 Web Dashboard 설정 작업을 해주면 좋다.

 

Kubernetes Web Dashboard 설치 및 설정

내가 참고했던 Web docs(https://waspro.tistory.com/516) 가 있고, 이 문서에서 설명한 3가지 방식 중에서 3번째 방식(Kubernetes API Server 연동 방식)을 사용하는 것을 권장한다.

이 Web Docs에 설명이 잘 되어 있어서 내가 별도 설명할 필요 없을 것이고, 내가 수행했던 명령만 로그로 남겨보겠다.

 

$  kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-beta8/aio/deploy/recommended.yaml
$  kubectl proxy   &

# Service Account 생성

$  cat <<EOF | kubectl create -f -
 apiVersion: v1
 kind: ServiceAccount
 metadata:
   name: admin-user
   namespace: kube-system
EOF
$

# ClusterRoleBinding을 생성

$  cat <<EOF | kubectl create -f -
 apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRoleBinding
 metadata:
   name: admin-user
 roleRef:
   apiGroup: rbac.authorization.k8s.io
   kind: ClusterRole
   name: cluster-admin
 subjects:
 - kind: ServiceAccount
   name: admin-user
   namespace: kube-system
EOF
$

# 사용자 계정의 Token 확인
$  kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep admin-user | awk '{print $1}') 
Name:         admin-user-token-p9ldd
Namespace:    kube-system
Labels:       <none>
Annotations:  kubernetes.io/service-account.name=admin-user
              kubernetes.io/service-account.uid=041cb7ec-946a-49b6-8900-6dc90fc08464

Type:  kubernetes.io/service-account-token

Data
====
ca.crt:     1025 bytes
namespace:  11 bytes
token:      eyJhbGciOiJSUzI1NiIsImtpZCI6InFmdGVUUnB6QmhoOHhlSDBJLUNLVHlEWWxpd2ZVaDhBVjZOQXE5TElhVWsifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlLXN5c3RlbSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJhZG1pbi11c2VyLXRva2VuLWZ2dG5uIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6ImFkbWluLXVzZXIiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiJjOGExZTY3MS00NmY1LTQwZjctODNkYy02YTE4N2NiYzkzYmYiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6a3ViZS1zeXN0ZW06YWRtaW4tdXNlciJ9.lKKD4yEvlpFJ7-BNuPTyO3YRuFYYdQMgPX5azXwn4bZiki2Y886k1dnNM16L4YuA_SSahrPtitSzPfevlAoeC5msdDg1DKRdFuGuYkkI_u_KvOv7orMopDDgZs0zuXFrHIZa1-qiWbgvHfgokOMvndchCcMHyo8pKD3vdBAq_AxtGlCIPImkfALM_d41FrBKIXEjdoCcHkPu7Cz13UAxNRBRs-d274g2UNz-MUnNiomDhJlcYFXTXeooKjHhUiyoFLCgP-V6Wh_1QSCwdfYZGQ1bF0QcZINQZdwluyOtP43AjXHxdSBrAGIPfaY7qsBR_b2upuUDnQsA1w7qkaQB0g     <== 이 빨간색 token을 Web dashboard login 화면에 붙여 넣고, "Sign-in" 버튼을 누른다.
$

 

위와 같이 ServiceAccount와 ClusterRole을 설정하고, secret을 생성/등록한 후에 Web Browser에서 접속하면 된다.

 

접속 주소 예시:  http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/

 

 

 

 


 

Troubleshooting & How to clear the issue

kubeadm join  명령이 실패하는 경우.

대부분 master node에서 생성한지 1시간이 초과된 token 값을 이용해서 worker node에서 join하려고 하면 

'kubeadm join' 명령이 실패한다.

worker node 1, 2, ... 9 이런 식으로 순차적으로 작업하다가 보면, 거의 끝 부분에 있는 worker node 9는 이미 1 시간이 지난 뒤에

'kubeadm join'을 하게 되므로 종종 실패하게 된다.

그러나 심각한 문제는 아니고, master node에서 'kubeadm token create ...' 명령을 사용해서 다시 token 값을 생성해주기만 하면 된다.

아래와 같이 master node에서 token create하고, worker node에서 새로 만들어진 token 값으로 `kubeadm join'하면 된다.

##
## On master node.
##
$ kubeadm token create --print-join-command

kubeadm join 10.10.3.33:6443 --token z53s7g.aa...zc --discovery-token-ca-cert-hash sha256:372...3a686


##
## On worker node.
##
$ kubeadm join 10.10.3.33:6443 --token z53s7g.aa...zc --discovery-token-ca-cert-hash sha256:372...3a686

[preflight] Running pre-flight checks
[preflight] Reading configuration from the cluster...
[preflight] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Starting the kubelet
[kubelet-start] Waiting for the kubelet to perform the TLS Bootstrap...

This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.

Run 'kubectl get nodes' on the control-plane to see this node join the cluster.

$


##
## 위와 같이 worker node의 joining이 성공하면, 
## 그 동안 activating (auto-restart) 상태였던 kubelet에 아래와 같이 active(running) 상태로 바뀐다.
## On worker node.
##

$ systemctl status kubelet

● kubelet.service - kubelet: The Kubernetes Node Agent
   Loaded: loaded (/usr/lib/systemd/system/kubelet.service; enabled; vendor preset: disabled)
  Drop-In: /usr/lib/systemd/system/kubelet.service.d
           └─10-kubeadm.conf
   Active: active (running) since Thu 2021-11-11 15:38:54 KST; 17s ago
   ...
   ...
   
 $

위와 같이 Active: active (running) 상태로 출력되면, 정상적으로 kubelet이 기동되고 Master node와 연동된 것이다.

 

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

 

 

반응형

kubernetes 로그를 볼 때, 현재 발생한 로그부터 보고 싶을 때는 -f --tail={LINE-NUM} 옵션을 추가한다.

 

아래 명령 예시대로 수행~

$ kubectl logs -f --tail=3 my-pod

 

반응형

 

OCP Cluster를 구축한 직후에  ovs-vsctl 명령으로 Open vSwitch의 구성을 확인해봤다.

 

특징한 살펴보면, 

  • br-int Bridge에 각 Kube Node로 가는 물리 Port(50.50.51.2x)는 geneve 터널링 방식을 사용.
    (아래 ovs-vsctl 명령 결과에서 geneve로 검색하면 됨)

 

[root@worker1 ~]# ovs-vsctl show
9cad81c8-d7be-4b18-90e8-03aadd86a8cb
    Bridge br-ex
        Port enp131s0f0
            Interface enp131s0f0
                type: system
        Port patch-br-ex_worker1.twcm.cloud-to-br-int
            Interface patch-br-ex_worker1.twcm.cloud-to-br-int
                type: patch
                options: {peer=patch-br-int-to-br-ex_worker1.twcm.cloud}
        Port br-ex
            Interface br-ex
                type: internal
    Bridge br-int
        fail_mode: secure
        datapath_type: system
        Port ovn-5e8778-0
            Interface ovn-5e8778-0
                type: geneve
                options: {csum="true", key=flow, remote_ip="50.50.51.22"}
        Port "83cf7b04f35b763"
            Interface "83cf7b04f35b763"
        Port br-int
            Interface br-int
                type: internal
        Port d10af31c1d33dac
            Interface d10af31c1d33dac
        Port "460c3ee2f55e7c9"
            Interface "460c3ee2f55e7c9"
        Port ovn-f95ec3-0
            Interface ovn-f95ec3-0
                type: geneve
                options: {csum="true", key=flow, remote_ip="50.50.51.21"}
        Port patch-br-int-to-br-ex_worker1.twcm.cloud
            Interface patch-br-int-to-br-ex_worker1.twcm.cloud
                type: patch
                options: {peer=patch-br-ex_worker1.twcm.cloud-to-br-int}
        Port ovn-84a2f7-0
            Interface ovn-84a2f7-0
                type: geneve
                options: {csum="true", key=flow, remote_ip="50.50.51.23"}
        Port "5fe45b331cff8df"
            Interface "5fe45b331cff8df"
        Port ovn-k8s-mp0
            Interface ovn-k8s-mp0
                type: internal
        Port "59a37a9be52afdb"
            Interface "59a37a9be52afdb"
    ovs_version: "2.15.4"

 

 

실제 Pod가 사용하는 Overlay Network Portovn-k8s-mp0는 아래 보이는 것처럼 MTU가 1400 bytes이다.

geneve 터널링을 위해 100 byte를 사용해야 하므로, MTU1400 bytes가 된 것이다.

 

[root@worker1 ~]# ifconfig ovn-k8s-mp0
ovn-k8s-mp0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1400
        inet 10.131.0.2  netmask 255.255.254.0  broadcast 10.131.1.255
        inet6 fe80::ec45:a3ff:fe53:665  prefixlen 64  scopeid 0x20<link>
        ether ee:45:a3:53:06:65  txqueuelen 1000  (Ethernet)
        RX packets 248078  bytes 20827992 (19.8 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 264379  bytes 23121981 (22.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

 

 

Pod가 IP Networking은 일반적인 L2 Switching 통해서 처리되므로, 아래 routing table을 참조하여 이웃하는 Worker, Master Node로 전달된다. 

10.128.0.0  10.131.0.0 network가 Pod가 사용하는 Network이다.

 

[root@worker1 ~]# netstat -nr
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         50.50.51.10     0.0.0.0         UG        0 0          0 br-ex
10.128.0.0      10.131.0.1      255.252.0.0     UG        0 0          0 ovn-k8s-mp0
10.131.0.0      0.0.0.0         255.255.254.0   U         0 0          0 ovn-k8s-mp0
50.50.51.0      0.0.0.0         255.255.255.0   U         0 0          0 br-ex
169.254.169.0   50.50.51.10     255.255.255.252 UG        0 0          0 br-ex
169.254.169.3   10.131.0.1      255.255.255.255 UGH       0 0          0 ovn-k8s-mp0
172.30.0.0      50.50.51.10     255.255.0.0     UG        0 0          0 br-ex

 

 

Netfilter를 살펴보면,

Pod와 Service 리소스를 생성하면서 Netfilter의 Chain Rule 변화 여부를 모니터링 해봤는데, 변화가 없다.

 

[root@worker1 ~]# iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
OVN-KUBE-ETP  all  --  anywhere             anywhere
OVN-KUBE-EXTERNALIP  all  --  anywhere             anywhere
OVN-KUBE-NODEPORT  all  --  anywhere             anywhere

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
OVN-KUBE-SNAT-MGMTPORT  all  --  anywhere             anywhere
KUBE-POSTROUTING  all  --  anywhere             anywhere             /* kubernetes postrouting rules */

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
OVN-KUBE-EXTERNALIP  all  --  anywhere             anywhere
OVN-KUBE-NODEPORT  all  --  anywhere             anywhere

Chain KUBE-MARK-MASQ (0 references)
target     prot opt source               destination
MARK       all  --  anywhere             anywhere             MARK or 0x4000

Chain KUBE-MARK-DROP (0 references)
target     prot opt source               destination
MARK       all  --  anywhere             anywhere             MARK or 0x8000

Chain KUBE-POSTROUTING (1 references)
target     prot opt source               destination
RETURN     all  --  anywhere             anywhere             mark match ! 0x4000/0x4000
MARK       all  --  anywhere             anywhere             MARK xor 0x4000
MASQUERADE  all  --  anywhere             anywhere             /* kubernetes service traffic requiring SNAT */ random-fully

Chain KUBE-KUBELET-CANARY (0 references)
target     prot opt source               destination

Chain OVN-KUBE-SNAT-MGMTPORT (1 references)
target     prot opt source               destination
SNAT       all  --  anywhere             anywhere             /* OVN SNAT to Management Port */ to:10.131.0.2

Chain OVN-KUBE-NODEPORT (2 references)
target     prot opt source               destination

Chain OVN-KUBE-EXTERNALIP (2 references)
target     prot opt source               destination

Chain OVN-KUBE-ETP (1 references)
target     prot opt source               destination
[root@worker1 ~]#

 

그리고 위 상황에서 Service  리소스를 한개를 ClusterIP type에서 NodePort type으로 변경했더니,

아래와 같이 OVN-KUBE-NODEPORT에 Chain Rule 한개 추가되었다.

 

[root@worker1 ~]# iptables -L -t nat

... 중간 생략 ...

## 이 내용이 추가되었음.

Chain OVN-KUBE-NODEPORT (2 references)
target     prot opt source               destination
DNAT       tcp  --  anywhere             anywhere             ADDRTYPE match dst-type LOCAL tcp dpt:31785 to:172.30.44.86:80

## 참고로 위 Chain Rule은 iptables 명령으로 추가한다면, 아래와 같이 실행하면 된다.
## (설명) destination port가 31785이면, 172.30.44.86:80 주소로 DNAT 처리하는 Rule을
##       OVN-KUBE-NODEPORT 체인에 추가하라는 명령.
# -A OVN-KUBE-NODEPORT -p tcp -m addrtype --dst-type LOCAL -m tcp --dport 31785 -j DNAT --to-destination 172.30.44.86:80

... 중간 생략 ...

 

이하, 작성 중...

+ Recent posts