CI/CD-06: Podman을 이용한 컨테이너 관리 4 및 Kubernetes 서비스 전환

Node1에서 Podman을 이용한 컨테이너 관리 및 Kubernetes 서비스 전환 과정

이번 포스팅에서는 Node1에서 Podman을 사용하여 다양한 컨테이너 기반 서비스를 설정하고, 이를 Kubernetes 환경으로 이전하는 과정을 다루었다.

각 단계별로 필요한 명령어와 설정 방법을 상세하게 설명한다.

---

Apache, Nginx, Kubernetes 및 Kubernetes 플레이북에 대한 설명

Apache와 Nginx의 역할

Apache HTTP Server와 Nginx는 둘 다 웹 서버 소프트웨어로, 클라이언트(보통 웹 브라우저)로부터의 HTTP 요청을 받아서 웹 페이지를 제공하는 역할을 한다.

• Apache HTTP Server
  • 역할: Apache는 클라이언트 요청을 처리하고, 정적 웹 페이지 또는 동적 콘텐츠(PHP, Python, Perl 등)로 응답한다. Apache는 모듈 기반 아키텍처를 채택하여 다양한 기능(인증, 캐싱, URL 재작성 등)을 모듈로 추가할 수 있다.
  • 기능: 여기서 Apache는 웹 서버로서 웹 페이지를 제공하는 기본적인 역할을 한다. dnf install httpd -y 명령어로 설치하고, systemctl start httpd 명령어로 서비스를 시작했다. 이를 통해 웹 브라우저에서 http://example.com으로 접근할 수 있게 된다.
• Nginx
  • 역할: Nginx는 주로 정적 콘텐츠 제공, 리버스 프록시, 로드 밸런싱, 캐싱, 스트리밍 등의 기능을 제공한다. Nginx는 이벤트 기반 아키텍처로 고안되어 높은 성능과 낮은 메모리 사용량을 자랑한다.
  • 기능: Nginx는 여기서 컨테이너로 실행되어 웹 서버로서의 역할을 한다. podman run -d --name nginx docker.io/library/nginx:latest 명령어로 Nginx 컨테이너를 실행하고, 이후 Kubernetes YAML 파일로 변환하여 Kubernetes 환경으로 이전한다.

Kubernetes로 서비스를 이전하는 이유

Kubernetes는 컨테이너화된 애플리케이션의 배포, 확장, 운영을 자동화하기 위한 오픈 소스 플랫폼이다.

• 이점:
  • 자동화된 배포 및 관리: Kubernetes는 컨테이너의 배포 및 관리를 자동화하여 운영자의 수고를 덜어준다.
  • 확장성: 수평적 확장이 가능하여 부하에 따라 컨테이너 인스턴스를 자동으로 늘리거나 줄일 수 있다.
  • 자체 복구 기능: 컨테이너가 실패할 경우 자동으로 재시작하거나, 노드 장애 시 다른 노드로 이동시키는 등 높은 가용성을 보장한다.
  • 서비스 디스커버리 및 로드 밸런싱: 클러스터 내에서 컨테이너가 서로를 쉽게 찾을 수 있도록 하며, 로드 밸런서를 통해 트래픽을 분산시킨다.

Kubernetes로 서비스를 이전함으로써 애플리케이션의 배포와 관리가 용이해지고, 확장성과 가용성이 크게 향상된다.

Kubernetes 플레이북이란?

Kubernetes 플레이북은 Kubernetes 리소스를 정의한 YAML 파일로, 이 파일을 통해 Kubernetes 클러스터에서 배포할 애플리케이션의 구성, 배포 방식, 서비스 정의 등을 설정할 수 있다.

• 구성 요소:
  • Pod: 하나 이상의 컨테이너가 함께 실행되는 단위.
  • Deployment: 애플리케이션의 배포 및 업데이트를 관리.
  • Service: 네트워크 서비스 추상화를 통해 Pod 간 통신을 제공.
  • ConfigMap, Secret: 설정과 보안 정보 관리.

예를 들어, 아래 명령어는 Nginx 컨테이너를 기반으로 Kubernetes YAML 파일을 생성한다.

podman generate kube nginx --file nginx.yaml

생성된 nginx.yaml 파일은 Kubernetes 클러스터에서 Nginx 서비스를 배포하는 데 사용된다.

---

1. 기존 컨테이너 중지 및 제거

먼저, Node1에서 모든 기존 컨테이너를 중지하고 제거했다.

podman stop container --all
podman rm --all

2. Apache HTTP 서버 설치 및 시작

Apache HTTP 서버를 설치하고 시작했다.

dnf install httpd -y
systemctl start httpd

설치가 완료되면 웹 브라우저에서 http://example.com을 열어 설정이 올바르게 되었는지 확인했다.

3. Podman을 이용한 YAML 파일 생성

Podman을 사용하여 컨테이너 기반의 YAML 파일을 생성하여 Kubernetes로 이전할 수 있다.

이를 위해 먼저 Nginx 컨테이너를 실행했다.

podman run -d --name nginx docker.io/library/nginx:latest

그 후, Nginx 컨테이너를 기반으로 Kubernetes YAML 파일을 생성했다.

podman generate kube nginx --file nginx.yaml

Pod 단위로 YAML 파일을 생성할 수도 있다.

podman generate kube pod-web-service --file pod-web-service.yaml

Podman 컨테이너를 Kubernetes 배포(deployment)로 변환하여 YAML 파일을 생성했다.

podman generate kube <POD_NAME>/<CONTAINER_NAME> --file --type deployment

Kubernetes 서비스로 이전하기 위해 YAML 파일을 생성했다.

podman generate kube <POD_NAME>/<CONTAINER_NAME> --file kubernetes-service.yaml --type deployment --service

4. Podman Kubernetes 플레이북 실행

생성된 YAML 파일을 사용하여 Podman Kubernetes 플레이북을 실행했다.

podman kube play podman-service.yaml

실행 중인 Kubernetes 서비스를 중단했다.

podman kube down podman-service.yaml

5. 네트워크 관리

Podman 네트워크를 확인하고 관리했다.

podman network ls

6. GitHub 레포지토리 클론

필요한 소스를 GitHub에서 클론하여 가져왔다.

dnf install python3-pip
pip install github-clone
git clone https://github.com/tangt64/codelab/

이번 포스팅에서는 Node1에서 Podman을 사용하여 다양한 서비스를 설정하고 이를 Kubernetes로 전환하는 과정을 다루었다.

각 단계별로 필요한 명령어와 설정 방법을 자세히 설명하였다.

이를 통해 효율적이고 안정적인 네트워크 환경을 구축할 수 있다.

---

네트워크 설정 및 Podman을 이용한 컨테이너 관리

네트워크 설정

• nmtui:
  • 네트워크 설정을 위한 텍스트 기반의 사용자 인터페이스이다.
  • nmtui 명령어를 입력하여 네트워크 설정 메뉴에 진입한다.
  • Edit a connection을 선택하여 네트워크 인터페이스를 수정할 수 있다.
• eth0 및 eth1 설정:
  • Profile name과 Device 항목을 확인한 후, IPv4 CONFIGURATION 항목을 설정한다.
  • 각각의 주소, 게이트웨이, DNS 서버를 설정한다. 예를 들어:
    • DNS 서버: 10.10.0.10
    • 노드1: 10.10.0.20
    • 노드2: 10.10.0.30
• nmcli 명령어:
  • nmcli con up eth1 명령어를 사용하여 설정한 네트워크 인터페이스를 활성화한다.

---

Podman Pod 및 컨테이너 설정 해설

이 이미지에서는 Podman을 이용하여 Pod와 컨테이너를 설정하는 과정을 설명하고 있다.

주요 명령어 및 구성 요소 설명

1. Podman Pod 생성:

podman pod --publish 80:5000

• podman pod 명령어는 Podman을 이용해 새로운 Pod를 생성하는 명령어이다.
• --publish 80:5000 옵션은 호스트의 포트 80을 컨테이너의 포트 5000에 매핑하는 것을 의미한다. 이렇게 하면 호스트의 포트 80으로 접근하면 컨테이너의 포트 5000으로 연결된다.

2. 데이터베이스 컨테이너 옵션 설정:

• 컨테이너에서 데이터베이스를 사용하기 위해 필요한 환경 변수를 설정해야 한다.

-e POSTGRES_USER=blog -e POSTGRES_PASSWORD=blog -e POSTGRES_DB=blog

• -e POSTGRES_USER=blog: PostgreSQL 데이터베이스의 사용자 이름을 blog로 설정한다.
• -e POSTGRES_PASSWORD=blog: PostgreSQL 데이터베이스의 비밀번호를 blog로 설정한다.
• -e POSTGRES_DB=blog: 사용할 PostgreSQL 데이터베이스 이름을 blog로 설정한다.

이미지 내 포트 번호 설명

1. 포트 번호 매핑:
   • 5432->5432/tcp: PostgreSQL 데이터베이스가 사용하는 포트 번호이다. 호스트와 컨테이너 모두 5432 포트를 사용한다.
   • 0.0.0.0:8080->8080, tomcat: Tomcat 서버가 사용하는 포트 번호이다. 호스트와 컨테이너 모두 8080 포트를 사용하며, 모든 인터페이스(0.0.0.0)에서 접근이 가능하다.

전체 구성 설명

1. Actor:
   • 사용자가 Pod에 접근하는 것을 의미한다. 사용자는 호스트의 포트 80으로 접근하게 되며, 이는 컨테이너의 포트 5000으로 연결된다.
2. Pod:
   • 하나 이상의 컨테이너를 포함하는 논리적인 단위이다. 이 예시에서는 하나의 Pod 안에 여러 컨테이너가 존재할 수 있으며, 그 중 PostgreSQL 데이터베이스와 Tomcat 서버가 포함된다.
3. 컨테이너:
   • 각각의 컨테이너는 독립적으로 실행되며, 설정된 포트를 통해 외부와 통신한다.
   • 사용자는 설정된 포트를 통해 컨테이너에 접근할 수 있으며, 컨테이너 내부의 애플리케이션이 이를 처리한다.

추가적인 설명

• 이 이미지는 Podman을 사용하여 어떻게 Pod와 컨테이너를 생성하고 설정하는지 보여주며, 특히 포트 매핑과 환경 변수 설정을 강조하고 있다.
• PostgreSQL 데이터베이스와 Tomcat 서버의 설정 예시를 통해 실제 애플리케이션 환경에서 사용되는 설정 방법을 이해할 수 있다.

이로써 Podman을 이용한 컨테이너와 Pod 설정, 포트 매핑, 환경 변수 설정에 대해 쉽게 이해할 수 있을 것이다.

---

PostgreSQL, 흔히 줄여서 "Postgres"라고 불리는, 오픈 소스 관계형 데이터베이스 관리 시스템(RDBMS)이다.

PostgreSQL은 데이터베이스의 데이터 저장, 관리 및 검색을 담당하며, 다양한 기능과 확장성을 제공하여 많은 기업과 개발자들이 널리 사용하고 있다.

주요 특징

1. 오픈 소스:
   • PostgreSQL은 오픈 소스 소프트웨어로서 누구나 무료로 사용하고 수정할 수 있다. 또한, 활발한 커뮤니티 지원을 받는다.
2. SQL 표준 준수:
   • PostgreSQL은 SQL 표준을 준수하며, 다양한 SQL 기능을 지원한다. 이를 통해 복잡한 쿼리를 작성하고 데이터베이스를 효율적으로 관리할 수 있다.
3. ACID 특성:
   • PostgreSQL은 트랜잭션의 일관성과 신뢰성을 보장하는 ACID(Atomicity, Consistency, Isolation, Durability) 특성을 지원한다.
4. 확장성:
   • PostgreSQL은 저장 프로시저, 사용자 정의 함수, 트리거 등 다양한 확장 기능을 제공하여 데이터베이스 기능을 확장할 수 있다.
   • 다양한 데이터 타입과 인덱스를 지원하여 복잡한 데이터 모델링이 가능하다.
5. JSON 지원:
   • PostgreSQL은 JSON 데이터를 저장하고 쿼리하는 기능을 제공하여 NoSQL 데이터베이스의 일부 기능을 통합했다. 이를 통해 유연한 데이터 모델링이 가능하다.
6. 복제 및 클러스터링:
   • PostgreSQL은 데이터베이스 복제 및 클러스터링 기능을 지원하여 고가용성과 확장성을 제공한다.

사용 사례

1. 웹 애플리케이션:
   • PostgreSQL은 안정성과 성능 덕분에 많은 웹 애플리케이션의 백엔드 데이터베이스로 사용된다. 예를 들어, Django와 같은 웹 프레임워크는 PostgreSQL을 기본 데이터베이스로 지원한다.
2. 데이터 분석:
   • PostgreSQL의 강력한 쿼리 기능과 확장성 덕분에 데이터 분석 작업에 자주 사용된다.
3. GIS 애플리케이션:
   • PostgreSQL의 PostGIS 확장을 통해 지리 정보 시스템(GIS) 애플리케이션에서 공간 데이터를 저장하고 처리할 수 있다.

베어메탈과 포드만 환경에서의 애플리케이션 배포

이 이미지는 애플리케이션을 베어메탈 환경과 포드만(Podman) 환경에서 배포하는 과정을 시각적으로 설명하고 있다. 각 단계를 쉽게 이해할 수 있도록 세부적으로 설명하겠다.

• 베어메탈 서버:
  • 하드웨어 자원을 직접 사용.
  • 고성능, 예측 가능한 성능 제공.
  • 단일 테넌트 환경, 높은 보안성.
• 가상화 서버:
  • 하드웨어 위에 하이퍼바이저를 통해 여러 가상 머신 운영.
  • 자원의 유연한 분배, 효율적인 사용.
  • 멀티 테넌트 환경, 관리의 용이성.

1. 베어메탈 환경

1. Maven
   • java test.java: Java 소스 파일(test.java)을 컴파일하고 실행하는 명령어이다.
   • pom.xml: 프로젝트 객체 모델(POM) 파일로서, 프로젝트의 종속성, 빌드 구성 등을 정의한다.
   • mvn clean package: Maven을 사용하여 프로젝트를 빌드하고, 패키지로 만든다. 이 명령어는 소스 코드를 컴파일하고, 테스트를 실행한 후, 패키지(JAR 또는 WAR 파일)를 생성한다.
2. Spring
   • javac: Java 컴파일러를 사용하여 소스 파일을 바이트코드(.class 파일)로 컴파일한다.
   • war/jar: Spring 애플리케이션은 JAR 또는 WAR 파일로 패키징된다.

2. 포드만(Podman) 환경

1. PostgreSQL
   • 포드만 환경에서는 PostgreSQL 데이터베이스가 애플리케이션의 데이터 저장소 역할을 한다.
   • JDBC와 META-INF: 애플리케이션은 JDBC(Java Database Connectivity)를 통해 PostgreSQL 데이터베이스와 통신한다. META-INF 디렉토리는 애플리케이션 메타데이터를 포함한다.
2. Tomcat
   • 애플리케이션 서버 역할을 하며, 웹 애플리케이션(WAR 파일)을 실행하는 데 사용된다.
   • table.sql: 데이터베이스 테이블을 설정하기 위한 SQL 스크립트 파일이다.
3. Container Image
   • buildah bud -f Dockerfile: Buildah를 사용하여 Dockerfile을 기반으로 컨테이너 이미지를 빌드한다.
   • 이 이미지에는 애플리케이션 코드와 실행 환경이 포함된다.

3. 결과

1. Infra-container (POD)
   • podman pod create: 포드만을 사용하여 새로운 POD를 생성한다.
   • 이 POD는 여러 컨테이너를 하나의 네임스페이스 내에서 실행할 수 있는 단위이다.
2. Web and DB Containers
   • web/8080: 웹 애플리케이션 컨테이너는 포드 내에서 8080 포트를 사용한다.
   • db/3456: 데이터베이스 컨테이너는 포드 내에서 3456 포트를 사용한다.
   • infra-container: 네트워크 인터페이스 및 기타 설정을 포함하는 기본 컨테이너이다.
3. /etc/hosts
   • 호스트 파일을 수정하여 로컬 네임스페이스 내에서 컨테이너 간 통신을 용이하게 한다. 예를 들어, 127.0.0.1 blog-web 및 127.0.0.1 blog-db 항목을 추가한다.
4. User Interaction
   • 사용자는 웹 브라우저를 통해 애플리케이션에 접근한다. 예를 들어, web/80 포트로 접속하면 애플리케이션 웹 인터페이스를 사용할 수 있다.

요약

이 이미지는 베어메탈 환경에서 애플리케이션을 개발하고 포드만 환경에서 배포하는 전체 프로세스를 보여준다.

주요 단계는 다음과 같다:

• Maven을 사용한 소스 코드 컴파일 및 패키징.
• PostgreSQL 및 Tomcat을 사용하여 데이터베이스와 애플리케이션 서버 설정.
• Buildah와 포드만을 사용하여 컨테이너 이미지를 빌드하고 POD를 생성하여 배포.
• 사용자가 웹 브라우저를 통해 애플리케이션에 접근.

이를 통해 애플리케이션을 효율적으로 개발하고 배포할 수 있는 방법을 이해할 수 있다.

이미지 설명: 포드만 환경과 쿠버네티스 환경에서의 애플리케이션 배포

이 이미지는 포드만(Podman) 환경과 쿠버네티스(Kubernetes) 환경에서 애플리케이션을 배포하는 과정을 시각적으로 설명하고 있다. 각각의 단계와 주요 구성 요소들을 쉽게 이해할 수 있도록 자세하게 설명하겠다.

포드만 환경

1. POD
   • 포드만 환경에서 하나의 POD 안에 여러 컨테이너가 포함된다.
   • 각 컨테이너는 애플리케이션의 특정 서비스를 제공한다.
2. 포트 설정
   • 80: HTTP 트래픽을 처리하기 위한 포트.
   • 5000: 레지스트리(Registry) 서비스를 위한 포트.
3. POD 내 컨테이너
   • database와 tomcat 두 개의 주요 컨테이너가 있다.
   • database 컨테이너는 데이터베이스 서비스를 제공한다.
   • tomcat 컨테이너는 웹 애플리케이션을 호스팅한다.
4. Proxy
   • Proxy 서버는 외부 트래픽을 POD 내부의 적절한 컨테이너로 라우팅한다.
   • blog.example.com:8080을 통해 웹 애플리케이션에 접근할 수 있다.
5. Developers와 Users
   • 개발자와 사용자가 각각 특정 엔드포인트를 통해 서비스에 접근한다.
   • 개발자는 git.example.com:80와 registry.example.com:5000을 통해 애플리케이션을 관리한다.

쿠버네티스 환경

1. Cluster 구성
   • 쿠버네티스 클러스터는 여러 노드로 구성되어 있으며, 여기서는 Control Node와 Compute Node로 나뉜다.
2. CI/CD (Continuous Integration/Continuous Deployment)
   • CI/CD 시스템이 자동으로 코드를 빌드하고 배포한다.
   • 새로운 코드를 감지하면, 빌드하고 테스트한 후 쿠버네티스 클러스터에 배포한다.
3. 네임스페이스
   • namespace: blog은 애플리케이션의 모든 리소스를 하나의 네임스페이스에 그룹화한다.
   • 이를 통해 관리와 격리가 용이해진다.
4. Kubernetes YAML 파일
   • kubectl create -f blog-v1.yaml: YAML 파일을 사용하여 쿠버네티스 리소스를 생성한다.
   • YAML 파일에는 POD, 서비스, 디플로이먼트 등의 설정이 포함된다.
5. 컨테이너 레지스트리
   • registry.example.com:5000에서 컨테이너 이미지를 가져와서 배포한다.
   • 이미지가 새로운 버전으로 업데이트되면, CI/CD 파이프라인이 이를 자동으로 배포한다.
6. Ingress 설정
   • Ingress: 외부 트래픽을 클러스터 내부의 서비스로 라우팅한다.
   • kubectl apply -f https://.../ingress.yaml: Ingress 설정을 적용하여 외부 트래픽을 적절한 서비스로 보낸다.
7. 서비스 배포
   • kubectl apply -f blog.yaml: 애플리케이션 서비스를 정의한 YAML 파일을 통해 배포한다.
   • 서비스는 자동으로 스케일링되고, 로드 밸런싱이 제공된다.
8. DNS 설정
   • dns1.example.com과 같은 DNS 설정을 통해 클러스터 내외부의 네트워크 통신을 관리한다.

요약

이 이미지는 포드만과 쿠버네티스 환경에서 애플리케이션을 배포하는 과정을 비교하고 설명하고 있다.

• 포드만 환경: 간단한 컨테이너 관리와 포드 설정을 통해 애플리케이션을 배포하고, Proxy 서버를 통해 트래픽을 라우팅한다.
• 쿠버네티스 환경: 더 복잡한 클러스터 설정과 CI/CD 파이프라인을 통해 애플리케이션을 자동으로 배포하고 관리한다. YAML 파일을 사용하여 리소스를 정의하고, Ingress 설정을 통해 외부 트래픽을 관리한다.

이를 통해 각각의 환경에서 애플리케이션 배포와 관리가 어떻게 이루어지는지 쉽게 이해할 수 있다.

Kubernetes 클러스터 설치 및 설정 가이드

아래는 node1과 node2에서 Kubernetes 클러스터를 설정하는 단계별 명령어와 그 기능에 대한 설명입니다. 이 가이드는 블로그 포스팅 용도로 작성되었습니다.

---

1. 공통 설정 (node1과 node2 모두에서 실행)

1. Kubernetes 저장소 설정

   cat <<EOF> /etc/yum.repos.d/kubernetes.repo
   [kubernetes]
   name=Kubernetes
   baseurl=https://pkgs.k8s.io/core:/stable:/v1.26/rpm/
   enabled=1
   gpgcheck=1
   gpgkey=https://pkgs.k8s.io/core:/stable:/v1.26/rpm/repodata/repomd.xml.key
   EOF

• Kubernetes 패키지를 설치하기 위한 저장소를 설정하는 명령어이다.

2. Kubeadm 설치

   dnf install kubeadm -y

• Kubernetes 클러스터를 초기화하고 설정하기 위한 도구인 kubeadm을 설치한다.

3. SELinux 설정 변경

   vi /etc/selinux/config
   SELINUX=permissive
   SELINUXTYPE=targeted

• SELinux를 permissive 모드로 설정하여, 보안 정책을 허용하고 경고만 출력하게 한다.

4. 방화벽 비활성화 및 스왑 해제

   systemctl disable --now firewalld.service
   swapoff -a

• 방화벽을 비활성화하고, 스왑을 해제하여 Kubernetes 설치에 필요한 네트워크 설정을 방해하지 않도록 한다.

5. 필요 패키지 설치

   dnf install iproute-tc -y

• iproute-tc 패키지를 설치하여 트래픽 제어 도구를 제공한다.
• iproute-tc는 리눅스 시스템에서 네트워크 트래픽을 제어하고 관리하기 위한 도구 모음입니다. iproute-tc 패키지에는 ip와 tc 명령어가 포함되어 있으며, 네트워크 인터페이스 설정, 라우팅, 트래픽 제어(QoS) 등을 수행할 수 있습니다. Kubernetes 설치 시에는 네트워크 트래픽 관리 및 제어를 위해 이 패키지가 필요합니다.

6. Kubelet 활성화

   systemctl enable --now kubelet

• Kubernetes 노드 에이전트인 kubelet을 활성화하고 시작한다.
• Kubelet은 Kubernetes 클러스터의 각 노드에서 실행되는 에이전트입니다. Kubelet은 API 서버와 통신하며, 노드에서 컨테이너가 올바르게 실행되고 있는지 확인하고, 필요한 경우 컨테이너를 생성, 업데이트, 삭제합니다. Kubelet은 노드의 상태를 주기적으로 API 서버에 보고하고, 클러스터 내 파드의 라이프사이클을 관리합니다.

7. CRI-O 저장소 설정

   cat <<EOF | tee /etc/yum.repos.d/cri-o.repo
   [cri-o]
   name=CRI-O
   baseurl=https://pkgs.k8s.io/addons:/cri-o:/prerelease:/main/rpm/
   enabled=1
   gpgcheck=1
   gpgkey=https://pkgs.k8s.io/addons:/cri-o:/prerelease:/main/rpm/repodata/repomd.xml.key
   EOF

• 컨테이너 런타임인 CRI-O를 설치하기 위한 저장소를 설정한다.
• CRI-O는 Kubernetes에서 컨테이너를 실행하기 위해 사용되는 오픈 소스 컨테이너 런타임입니다. CRI-O는 Kubernetes의 CRI(Container Runtime Interface)를 구현한 런타임으로, Docker와는 별개로 가볍고 안정적인 컨테이너 실행 환경을 제공합니다. 주로 오버헤드가 적고 보안이 강화된 환경에서 사용됩니다.

8. 필요한 패키지 설치

   dnf install -y \
       conntrack \
       container-selinux \
       ebtables \
       ethtool \
       iptables \
       socat

• Kubernetes 설치에 필요한 네트워크 관련 패키지들을 설치한다.

9. CRI-O 설치 및 활성화

   dnf install cri-o -y
   systemctl enable --now crio

• CRI-O를 설치하고 활성화하여 Kubernetes가 컨테이너를 관리할 수 있도록 한다.

10. 모듈 로드

modprobe br_netfilter
modprobe overlay
cat <<EOF> /etc/modules-load.d/k8s-modules.conf
br_netfilter
overlay
EOF

 

- Kubernetes 네트워킹에 필요한 커널 모듈들을 로드하고, 시스템 부팅 시 자동으로 로드되도록 설정한다.

 

11. 시스템 설정 

cat <<EOF> /etc/sysctl.d/k8s-mod.conf
net.bridge.bridge-nf-call-iptables=1
net.ipv4.ip_forward=1
net.bridge.bridge-nf-call-ip6tables=1
EOF
sysctl --system
systemctl daemon-reload

 

- 네트워크 관련 시스템 설정을 적용하여 Kubernetes 네트워킹이 올바르게 동작하도록 설정한다.

---

2. Node1 설정

1. Kubernetes 클러스터 초기화

   kubeadm init --apiserver-advertise-address=192.168.10.20 --pod-network-cidr=192.168.0.0/16 --service-cidr=10.90.0.0/16

• Kubernetes 클러스터를 초기화하고 API 서버와 네트워크 범위를 설정한다.

2. Kubeconfig 설정

   export KUBECONFIG=/etc/kubernetes/admin.conf

• 클러스터 관리에 필요한 kubeconfig 파일을 환경 변수로 설정한다.

3. 노드 및 파드 상태 확인

   kubectl get node
   kubectl get pod

• 클러스터 내 노드와 파드의 상태를 확인한다.

4. Node2 가입용 토큰 생성

   KUBECONFIG=/etc/kubernetes/admin.conf kubeadm token create --print-join-command
   # 출력된 명령어 예시: kubeadm join 192.168.10.20:6443 --token hu4j6d.nmwpommshmm70e93 --discovery-token-ca-cert-hash sha256:c60f43defd89ecf3f6a9e80ff3f8d8cce0f07a0021b0633301ea1f7dcc1914c7

• Node2가 클러스터에 가입할 수 있는 토큰을 생성하고, 가입 명령어를 출력한다.
• 노드 가입용 토큰은 새로운 노드를 기존 Kubernetes 클러스터에 가입시키기 위해 사용되는 일회용 토큰입니다. kubeadm token create 명령어를 사용하여 생성되며, 클러스터의 컨트롤 플레인 노드와 통신할 수 있는 인증 정보를 제공합니다. 이를 통해 새로운 노드가 클러스터에 안전하게 가입할 수 있습니다.

5. Calico 네트워크 플러그인 설치

Calico는 Kubernetes 클러스터 내에서 컨테이너 네트워킹을 담당하는 오픈 소스 네트워크 플러그인입니다. Calico는 네트워크 정책을 설정하고 관리하며, 클러스터 내의 파드들이 서로 통신할 수 있도록 해줍니다. 주로 Layer 3 라우팅을 기반으로 동작하여 고성능, 낮은 지연시간, 뛰어난 확장성을 제공합니다.

   kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.24.5/manifests/tigera-operator.yaml
   kubectl create -f https://raw.githubusercontent.com/tangt64/training_memos/main/opensource-101/kubernetes-101/files/calico-quay-crd.yaml

• Calico 네트워크 플러그인을 설치하여 Kubernetes 클러스터의 네트워킹을 설정한다.

6. Calico 파드 상태 확인

   kubectl get pods -n calico-system

• Calico 시스템 네임스페이스 내 파드 상태를 확인한다.
• 파드 상태 확인은 kubectl get pods 명령어를 통해 Kubernetes 클러스터 내에서 실행 중인 파드(pod)의 상태를 조회하는 것을 의미합니다. 이를 통해 파드가 정상적으로 실행 중인지, 오류가 발생했는지, 재시작이 필요한지 등의 정보를 확인할 수 있습니다.

---

3. Node2 설정

1. Node1에서 출력된 명령어를 사용하여 클러스터에 가입

   kubeadm join 192.168.10.20:6443 --token hu4j6d.nmwpommshmm70e93 --discovery-token-ca-cert-hash sha256:c60f43defd89ecf3f6a9e80ff3f8d8cce0f07a0021b0633301ea1f7dcc1914c7

• Node1에서 생성된 토큰을 사용하여 Node2를 클러스터에 가입시킨다.

2. 클러스터에 가입 성공 메시지 확인

   This node has joined the cluster

• 클러스터에 성공적으로 가입되었음을 나타내는 메시지를 확인한다.

---

위 과정들을 차례로 따라하면 Kubernetes 클러스터를 설정할 수 있습니다. 각 명령어는 설정 과정에서 중요한 역할을 하므로, 단계별로 꼼꼼하게 확인하고 실행하시기 바랍니다.

이 이미지는 Kubernetes 클러스터의 구조와 서비스 배포 과정을 시각적으로 설명한 다이어그램입니다. 각 구성 요소와 연결 관계를 이해하기 쉽게 설명해드리겠습니다.

구성 요소 설명

1. Kubernetes Node 1 (CONTROL):
   • 제어 노드로, Kubernetes 클러스터의 관리 및 제어 기능을 담당합니다.
   • CI/CD 파이프라인과 연결되어 지속적인 통합 및 배포 작업을 자동화합니다.
2. Kubernetes Node 2 (COMPUTE):
   • 작업 노드로, 실제 애플리케이션이 실행되는 곳입니다.
   • 컨테이너화된 애플리케이션이 배포되고 실행됩니다.
3. CI/CD 시스템:
   • Continuous Integration/Continuous Deployment 시스템으로, 소스 코드의 변경 사항을 자동으로 빌드하고 배포합니다.
   • 개발자가 코드를 커밋하면 CI/CD 시스템이 이를 감지하고, 자동으로 빌드 및 배포를 수행합니다.
4. 외부 네트워크 (demo.io):
   • 외부 네트워크로, 인터넷과 연결되어 있습니다.
   • 외부 사용자가 애플리케이션에 접근할 수 있는 경로입니다.
5. 내부 네트워크 (example.com):
   • 내부 네트워크로, 회사 내부 사용자나 시스템 간의 통신을 담당합니다.
   • 내부 자원 간의 안정적인 연결을 제공합니다.
6. Gateway Server (dns1):
   • 게이트웨이 서버로, 네트워크 트래픽을 관리하고 라우팅합니다.
   • DNS 서버 기능을 하며, 도메인 이름을 IP 주소로 변환합니다.
7. 개발 워크스테이션 (dev_workstation):
   • 개발자가 사용하는 컴퓨터로, 코드 작성 및 테스트를 수행합니다.
   • CI/CD 시스템과 연결되어 지속적인 개발 환경을 제공합니다.

연결 관계 설명

• CI/CD 시스템과 Kubernetes Node 1:
  • CI/CD 시스템은 제어 노드와 직접 연결되어 지속적인 배포를 자동화합니다.
  • 소스 코드 변경 시 CI/CD 시스템이 이를 감지하고, 새로운 애플리케이션 버전을 빌드하여 제어 노드에 배포합니다.
• Kubernetes Node 1과 Node 2 간의 연결:
  • 제어 노드는 작업 노드와 상호작용하여 애플리케이션을 배포하고 관리합니다.
  • 제어 노드에서 작업 노드로 명령을 전송하여 컨테이너를 실행합니다.
• 외부 네트워크와 eth0 연결:
  • 외부 네트워크는 eth0 인터페이스를 통해 제어 노드와 연결됩니다.
  • 외부 사용자가 인터넷을 통해 애플리케이션에 접근할 수 있도록 합니다.
• 내부 네트워크와 eth1 연결:
  • 내부 네트워크는 eth1 인터페이스를 통해 작업 노드와 연결됩니다.
  • 내부 자원 간의 안정적인 통신을 보장합니다.
• Gateway Server와 개발 워크스테이션:
  • 게이트웨이 서버는 DNS1 역할을 하며, 도메인 이름을 IP 주소로 변환하여 네트워크 트래픽을 라우팅합니다.
  • 개발 워크스테이션은 CI/CD 시스템과 상호작용하여 개발 및 배포 작업을 수행합니다.

서비스 배포 과정

• 서비스 배포:
  • 개발자가 코드를 커밋하면 CI/CD 시스템이 이를 감지하고 자동으로 빌드 및 배포를 수행합니다.
  • 새로운 애플리케이션 버전이 Kubernetes Node 1 (CONTROL)에 배포됩니다.
  • 제어 노드는 작업 노드에 명령을 전송하여 애플리케이션 컨테이너를 실행합니다.
• 사용자 접근:
  • 외부 사용자는 외부 네트워크를 통해 애플리케이션에 접근할 수 있습니다.
  • 내부 사용자는 내부 네트워크를 통해 애플리케이션에 접근할 수 있습니다.

이 다이어그램은 Kubernetes 클러스터의 기본 구조와 CI/CD 시스템을 통한 자동화된 배포 과정을 시각적으로 설명합니다. 각 구성 요소와 그 연결 관계를 이해하면 Kubernetes 환경에서의 애플리케이션 배포와 관리 방법을 더 잘 이해할 수 있습니다.

---

외부 네트워크와 내부 네트워크를 분리하는 이유는 여러 가지가 있다. 주된 이유는 보안, 성능, 관리 용이성 등을 들 수 있다. 각각의 이유에 대해 자세히 설명해 보겠다.

1. 보안

• 위협 격리: 외부 네트워크(예: 인터넷)는 많은 보안 위협이 존재하는 환경이다. 내부 네트워크를 외부 네트워크로부터 분리함으로써 외부로부터의 공격을 격리하고 내부 시스템을 보호할 수 있다.
• 액세스 제어: 내부 네트워크에 있는 중요한 데이터와 시스템에 대한 접근을 제어하기 위해 네트워크를 분리한다. 이를 통해 외부 사용자나 시스템이 내부 자원에 직접 접근하지 못하게 한다.
• 침입 탐지 및 예방: 네트워크를 분리하면 침입 탐지 시스템(IDS)이나 침입 방지 시스템(IPS)을 더 효율적으로 운영할 수 있다.

2. 성능

• 트래픽 관리: 외부 네트워크의 트래픽이 내부 네트워크로 영향을 미치지 않도록 하여 내부 네트워크의 성능을 최적화할 수 있다.
• 네트워크 대역폭: 중요한 내부 네트워크 트래픽이 외부 네트워크 트래픽과 경쟁하지 않도록 하여 대역폭을 효율적으로 사용한다.

3. 관리 용이성

• 정책 적용: 내부 네트워크와 외부 네트워크에 각각 다른 보안 정책과 네트워크 관리 정책을 적용할 수 있다.
• 네트워크 구조: 네트워크를 분리함으로써 각 네트워크의 구조를 단순화하고, 관리와 모니터링을 쉽게 할 수 있다.

4. 규정 준수

• 법적 요구사항: 많은 산업 분야에서 데이터 보호 및 개인정보 보호를 위해 네트워크를 분리할 것을 요구하는 법적 규제가 있다. 예를 들어, 금융기관이나 의료기관에서는 고객 데이터 보호를 위해 네트워크 분리가 필수적이다.
• 산업 표준: PCI DSS(지불 카드 산업 데이터 보안 표준)나 HIPAA(건강 보험 이동 및 책임에 관한 법) 같은 산업 표준을 준수하기 위해 네트워크 분리가 필요하다.

5. 장애 복구 및 유지보수

• 문제 격리: 내부 네트워크와 외부 네트워크를 분리하면 네트워크 문제 발생 시 문제의 원인을 쉽게 파악하고 격리할 수 있다.
• 유지보수: 내부 네트워크와 외부 네트워크를 별도로 관리하면 유지보수 작업을 수행하는 데 있어서도 편리하다. 예를 들어, 내부 네트워크에서만 필요한 유지보수 작업을 할 때 외부 네트워크 트래픽을 차단할 필요가 없다.

이처럼 외부 네트워크와 내부 네트워크를 분리하는 것은 네트워크 보안과 성능을 향상시키고, 관리 효율성을 높이는 중요한 전략이다. 이를 통해 조직은 네트워크 환경을 더 안전하고 효율적으로 운영할 수 있다.

---

 

 

이 이미지는 블로그 서비스를 쿠버네티스로 이전하는 과정을 설명하는 다이어그램입니다. 각 단계와 그에 해당하는 명령어, 파일 구성 등을 순차적으로 설명하겠습니다.

1. 서비스 도메인 테스트 구성

• 도메인 설정과 관련된 파일을 편집합니다.
  • named/demo.io.zone 파일과 ingress-www.demo.io.yaml, ingress-blog.demo.io.yaml 파일을 편집하여 도메인과 인그레스 설정을 정의합니다.

2. 블로그 서비스 쿠버네티스로 이전 준비

• 기존 블로그 서비스를 쿠버네티스 환경으로 이전하기 위해 필요한 준비 작업을 수행합니다.
  • kubectl apply -f blog.yaml 명령어를 통해 블로그 서비스 배포 파일을 적용합니다.
  • kubectl get pod 명령어를 통해 배포된 파드의 상태를 확인합니다.

3. 블로그 서비스 배포 과정

1. 블로그 서비스 배포 파일 적용
   • kubectl apply -f blog.yaml 명령어로 블로그 서비스 배포 파일을 적용합니다.
   • 이 파일에는 블로그 서비스의 배포 구성 및 설정이 포함되어 있습니다.
2. 파드 상태 확인
   • kubectl get pod 명령어로 배포된 파드의 상태를 확인합니다.
   • 파드가 정상적으로 실행되고 있는지, 오류가 발생했는지 등을 확인할 수 있습니다.
3. Docker 이미지를 태그 및 푸시
   • podman tag registry.example.com:5000/tang/blog:latest 명령어로 Docker 이미지를 태그합니다.
   • podman push registry.example.com:5000/tang/blog:latest 명령어로 이미지를 레지스트리에 푸시합니다.
   • 이 과정은 새로운 이미지를 레지스트리에 업로드하여 쿠버네티스에서 사용할 수 있도록 준비하는 단계입니다.
4. Podman을 사용한 컨테이너 실행
   • podman pod create --name blog -p 8080:8080 명령어로 새로운 Pod를 생성합니다.
   • podman container run -d --name web --pod blog registry.example.com:5000/tang/blog:web 명령어로 웹 컨테이너를 실행합니다.
   • 이 과정은 Podman을 사용하여 로컬 환경에서 컨테이너를 실행하는 단계입니다.

4. 쿠버네티스 배포 파일

• 쿠버네티스 배포 파일에는 서비스의 구성 및 설정이 포함되어 있습니다.
  • YAML 형식으로 작성되며, 각 서비스에 필요한 포트, 환경 변수, 이미지 정보 등을 정의합니다.

5. 블로그 서비스 화면 확인

• 배포된 블로그 서비스가 정상적으로 동작하는지 확인하기 위해 웹 브라우저에서 서비스 URL에 접속합니다.
  • 정상적으로 동작하면 블로그 페이지가 표시됩니다.

6. 오류 해결 과정

• 블로그 서비스 배포 중 발생할 수 있는 오류를 해결합니다.
  • 로그를 확인하여 오류 원인을 분석하고, 필요한 경우 설정 파일을 수정하거나 이미지를 재배포합니다.

이 다이어그램은 블로그 서비스를 쿠버네티스 환경으로 이전하는 전체 과정을 시각적으로 설명합니다. 각 단계에서 사용되는 명령어와 파일 구성, 오류 해결 방법 등을 이해하면 쿠버네티스 환경에서의 애플리케이션 배포 과정을 더 잘 이해할 수 있습니다.

 

DevOps 라이프사이클

첫 번째 이미지는 DevOps 라이프사이클을 설명하고 있다. DevOps는 소프트웨어 개발(Dev)과 운영(Ops)을 통합하여, 지속적인 통합 및 지속적인 배포(CI/CD) 과정을 통해 소프트웨어 개발 프로세스를 자동화하고 개선한다. 이미지에서는 DevOps의 주요 단계를 시각적으로 나타내고 있으며, 각 단계에 사용되는 도구들이 언급되어 있다.

1. 코드 작성(CODE):
   • Git: 분산 버전 관리 시스템으로, 소스 코드를 관리하고 협업하는 데 사용된다.
2. 빌드(BUILD):
   • Maven: 프로젝트 빌드, 보고서 및 문서화를 관리하는 도구이다. 주로 자바 프로젝트에서 사용된다.
   • SonarQube: 코드 품질 및 보안 검사를 자동화하는 도구로, 코드의 잠재적인 버그, 취약성 등을 검토한다.
3. 테스트(TEST):
   • JUnit: 자바 언어를 위한 단위 테스트 프레임워크로, 코드의 기능이 기대한 대로 작동하는지 확인한다.
4. 릴리스(RELEASE):
   • 이 단계는 소프트웨어를 배포 가능한 상태로 만드는 과정이다.
5. 배포(DEPLOY):
   • 소프트웨어를 실제 운영 환경에 배포하는 단계이다.
6. 운영(OPERATE):
   • 배포된 소프트웨어를 모니터링하고 유지보수하는 과정이다.
7. 모니터링(MONITOR):
   • 배포된 소프트웨어의 성능과 상태를 지속적으로 확인하고 문제를 발견하는 단계이다.

이 전체 과정이 반복되면서 소프트웨어는 지속적으로 개선되고, 빠르게 배포될 수 있다.

 

 

소프트웨어 라이프 사이클 프로세스

두 번째 이미지는 소프트웨어 개발의 라이프 사이클 프로세스를 보여준다. 이는 소프트웨어의 패치 및 새로운 기능 추가 과정을 설명하고 있다.

1. 컴파일(Compile):
   • 소스 코드를 기계어로 번역하여 실행 가능한 프로그램을 만든다.
2. 패키지화(Package):
   • 컴파일된 코드를 배포 가능한 형식(예: .war, .jar 파일)으로 패키징한다.
3. 컨테이너 이미지 생성(Container Image):
   • 패키지된 파일을 컨테이너 이미지로 변환하여, 다양한 환경에서 일관되게 실행될 수 있도록 준비한다.
4. 컨테이너 테스트(Container Test):
   • Podman을 사용하여 컨테이너 이미지를 테스트한다. Podman은 도커와 유사한 기능을 제공하는 컨테이너 엔진이다.
5. 패치 및 기능 추가(Patch, Add Feature):
   • 소프트웨어에 새로운 기능을 추가하거나 버그를 수정하여 다시 컴파일하고 패키징하는 과정을 반복한다.

이 라이프 사이클은 지속적인 통합 및 지속적인 배포(CI/CD)의 핵심 원칙을 따르며, 소프트웨어 개발의 효율성과 품질을 높이는 데 기여한다.

 

 

SOA(service-oriented architecture)는 서비스 인터페이스를 통해 소프트웨어 구성 요소의 재사용과 상호 운용성을 가능하게 하는 방법을 정의합니다. 서비스는 공통 인터페이스 표준과 아키텍처 패턴을 사용하므로 새로운 애플리케이션에 신속하게 통합될 수 있습니다. 이로써 애플리케이션 개발자는 기존의 기능을 재개발 또는 복제하거나 기존의 기능을 연결하거나 상호 운용성을 제공하는 방법을 알아야 했던 수고를 덜 수 있습니다.