본문 바로가기

전체 글

Ceph Pacific 버전의 Multi-site 구성 동기화 과정
2022. 3. 7. 들어가기 전... 해당 분석은 Ceph Pacific 버전으로 진행된 Multi-site 간의 Log 기반의 동기화를 분석한 것으로 아직 rgw_default_data_log_backing fifo에 대한 정보가 부족하여 깊게는 확인하지 못하였다. (부족한 지식으로 작성한 것이기에 틀린 부분이 있다면 댓글 부탁드립니다 :) ) 하지만, 확실한 것은 기존 rgw_default_data_log_backing omap의 방식 때보다 실제 Object 기반의 Omap 이 아닌 Pipe Fifo를 이용하였기에 중복 처리나, Large Omap과 같은 이슈에 대처하기 용이 해 진 것은 맞는 것 같다. Master와 Slave의 구분은 Ceph에 아직 소스 코드상으로 Master Slave로 구분되어 있어서 동일하게..
Nginx Architecture 분석
2021. 12. 31. 아래 작성된 글은 개인적으로 Nginx에 대하여 분석하기 위하여 여러 정보들을 수집 및 테스트한 결과를 정리한 것으로 잘못된 부분이 있거나, 인용이 잘못된 부분이 있을 수도 있습니다. 피드백 주시면 수정 하겠습니다 :) Traditional Web Server 전통적인 웹서버에서는 threads/process 기반으로 사용하는 경우가 많다. 이러한 경우 Client 요청당 하나의 Thread 가 처리하는 구조로 요청하는 량이 많아 짐에 따라서 생성되는 Thread 가 많아지게 된다. 이러한 방법은 메모리에 TCB나 PCB를 생성 하기 위한 공간이 많아지고 , Process 나 Thread를 관리하기 위한 추가 적인 CPU 작업이 많아지게 되고 이는 잦은 Context Switching으로 연결된다. 그래..
ExternalTrafficPolicy 설정을 위한 kubernetes service 분석
2021. 3. 24. 물리적인 로드밸런서 혹은 Metallb와 같은 Kubernetes 에서 논리/물리적인 로드밸런싱이 상단에서 이뤄진다면, 로드밸런싱이 2번 이상 될테고 그럴경우 다양한 문제를 발생 할 수 있기에 service 의 트래픽 flow 를 확인 하고 대처 하는 방안데 대하여 이야기 하고자 한다. 해당 kubernetes 버전은 1.19를 kubespray 로 배포되어 있는 상태이다. 테스트 환경은 다수의 worker 노드들 중에서 test-node=nginx 인 worker 노드들을 대상으로 진행 된다. 해당 kubernetes cluster의 cni는 calico를 ip-in-ip 터널링이 always 설정되어 있는 구조 이다. root@cy01-ceph120:~# kubectl get nodes -L test..
MetalLB BGP 모드를 이용한 Loadbalaning
2021. 3. 14. 기본적인 구성은 아래와 같이 worker3대가 10.10.2.0/24의 인터페이스가 연결되어 있으며, 같은 네트워크에 BGP를 사용할 L3SW가 연결 되어 있다. 그리고 Client 는 172.16.100.0 대역대로 L3SW와 연결 되어 있다. NXOS-9K로 구성된 상단 스위치의 인터페이스 설정은 아래와 같다. interface Ethernet1/1 no switchport ip address 10.10.2.210/24 no shutdown interface Ethernet1/2 no switchport ip address 172.19.100.210/24 no shutdown ... metallb 구성을 위하여 kubernetes 에서 kube-proxy strictARP true로 변경 해야 한다...
Rook Oeperator 환경의 RGW MultiSite 구성
2021. 3. 7. Rook환경으로 Ceph를 다양한 CRD를 이용하여 배포/관리 할수 있다. 만약 서로 다른 Kubernetes 환경에서 서로 다른 Ceph Cluster를 Rook을 이용하여 배포 하여 서로 Active-Active 구성으로 하기 위해서는 Multisite 구성을 통하여 진행할 수 있다. Rook환경에서는 Multisite 구성을 위한 realm,zongroup,zone을 CRD형태로 제공하고 있으며, 실제 구성상에서 어떻게 사용했는지를이야기 하고자 한다. Master Ceph Cluster 구성 Master Kubernetes에 외부 RGW Endpoint 연결을 위해서 MetalLB를 구성 한다. 만일, 실제 환경에서 물리적인 Loadbalancer가 있다면 MetalLB를 사용할 필요는 없다. ro..
Radosgw Object 저장과 삭제 과정
2021. 3. 4. raodsgw로 구성된 오브젝트 서비스에서 client 가 파일을 업로드 시 어떻게 ceph rados에 object로 저장되는 과정을 이야기하고자 한다. how to upload object 테스트를 위하여 cy-zone-a 이름의 zone을 생성하여 해당이름의 pool들이 생성된 것을 확인할 수 있다. 지금은 버킷이나 오브젝트가 업로드된 것이 아닌 초기 상태이기 때문에 오브젝트가 없이 나온다. # ceph osd pool ls device_health_metrics .rgw.root cy-zone-a.rgw.log cy-zone-a.rgw.control cy-zone-a.rgw.meta cy-zone-a.rgw.buckets.index cy-zone-a.rgw.buckets.non-ec cy-zone..
openstack instance and kubernetes pod communication using ovs
2020. 8. 9. openstack helm으로 구성된 openstack과 kubernetes pod네트워크를 간단하게 표현하였다. 각 worker노드 (compute)에는 instance와 pod들이 있으며 pod는 calico와 같은 cni를 이용하여 별도의 네트워크를 통하여 다른 pod들 간의 네트워크가 연결되며 필요한 경우 외부와 통신한다. 반면, instance는 provider network를 사용하지 않고 vxlan , vlan 등과 같이 tenant network로 구성할 경우 해당 instance에 있는 tunnel interface로 다른 instance들 간의 통신을 할 것이고 외부로 통신하기 위해서는 qrouter가 있는 호스트를 거쳐 통신하게 된다. 즉, pod와 instance 간의 통신은 외부 ..
openstack helm을 이용한 kubernetes환경에서 openstack 배포
2020. 8. 2. Openstack Helm을 Centos 환경에서 Ceph RBD로 구축하는 방법에 대하여 이야기한다. 공식 매뉴얼이 Ubuntu 및 Swift기반이기 때문에 커스텀하게 수정한 부분이 다소 존재한다. 하지만, 기본 배경은 공식 문서(https://docs.openstack.org/openstack-helm/latest/)를 기반으로 작성되었다. Openstack helm? openstack helm은 이름에서 알 수 있듯이 openstack을 kubernetes환경에서 helm chart를 이용하여 배포할 수 있는 프로젝트이다. Kubernetes의 기본 기능인 Self-Healing을 비롯하여 Kubernetes의 많은 장점들을 이용하여 Openstack을 관리하기 때문에 확장 등의 라이프 사이클 관리..
Antrea Overview
2020. 7. 30. 해당 문서는 https://github.com/vmware-tanzu/antrea 기반으로 번역된 문서입니다. Antrea Architecture Antrea는 Kubernetes 중심 및 Kubernetes 네이티브가 되도록 설계되어있다. Kubernetes 클러스터의 네트워킹 및 보안에 중점을 두고 최적화되었다. 구현은 가능한 한 Kubernetes 및 Kubernetes 기본 설루션을 활용한다. Antrea는 Open vSwitch를 네트워킹 data plane.으로 사용된다. Open vSwitch는 Linux 및 Windows를 모두 지원하는 고성능 프로그래밍 가능 가상 스위치이다. Antrea는 Open vSwitch를 사용하여 Kubernetes 네트워크 정책을 고성능으로 효율적으로 구현할 ..
Kubernetes1.17 Hard Way (Libvirt) using docker,flannel
2020. 3. 22. Kubernetes1.17 Hard Way (Libvirt) using docker,flannel 해당 문서는 https://github.com/alosadagrande/kubernetes-the-hard-way-libvirt-kvm/blob/master/docs/01-prerequisites.md,https://veerendra2.github.io/kubernetes-the-hard-way-3/ 를 기반으로 테스트된 문서 입니다. Prerequisites 호스트 서버에서 설정되어 있는 인스턴스는 아래와 같이 배포를 위한 서버기반으로 master 인스턴스3개와 worker 인스턴스 3개로 구성된다. 이중 master 인스턴스틑 worker의 역할과 같이 진행 할 수 있도록 한다. kubernetes 배포..
Spinnaker 를 통한 Kubernetes환경의 Application 배포(2)-CI/SCM연동
2020. 1. 1. 앞의 문서(https://cyuu.tistory.com/161) 에서 Spinnaker의 전반적인 구조를 이야기 했었다. 이어서 Spinnaker의 장점중 하나인 다양한 CI /SCM연동을 위한 방법을 이야기 하려고 한다. 해당 문서에서는 Gitlab과 Jenkins연동을 이야기 하려고 한다. Configure a GitLab artifact account Spinnaker의 artifact는 원격지의 artifact를 이용하여 원격지의 파일 및 이미지를 가져와서 활용할 수 있는 리소스이다. 해당 문서에서는 Gitlab를 artifact로 등록 하여 Git에 저장되어 있는 파일을 호출하여 Kubernetes의 Manifset파일을 Spinnaker에서 직접 관리하는것이 아닌, 외부 Gitlab의 Git으..
Spinnaker 를 통한 Kubernetes환경의 Application 배포(1)
2019. 12. 25. Spinnaker? •Spinnaker는 에서 Netflix에서 구축 된 클라우드 배포 모범 사례를 염두에 두고 구축 •Spinnaker의 목적은 응용 프로그램을 안정적으로 배포하기 위해 기본 클라우드 플랫폼의 전문가의 도움없이 배포를 안정적으로 하는 것 •대신 그들은 실제 문제 영역에 더 집중할 수 있고 롤아웃의 복잡성에 덜 집중 •엔지니어링 팀은 일관된 개념적 모델을 사용하여 지속적으로 전용 운영 팀에 참여하지 않고도 다양한 클라우드 플랫폼에 배포 •적은 노력으로 Netflix와 Google에서 정의한 모범 사례를 기반으로 배포 Application-centric Control Plane •Spinnaker는 가상 머신 및 컨테이너에서 로드밸런서 및 보안 그룹에 이르는 모든 애플리케이션 리소스에 대한..

티스토리툴바