RedHat Container Day 후기

컨테이너를 통한 클라우드 네이티브 실현

What is Cloud Native

 

Cloud Native라면, GCP? Azure? AWS?
이것도 아니라면, DevOps, Container가 갖춰진 서비스? 를 말하는 걸까요?
우선 인터넷에 나온 정의를 보게 된다면,

 

현대적이고 동적인 환경에서 확장 가능한 애플리케이션을 개발하고 실행할 수 있게 해준다.
이 기술은 회복성, 관리 편의성, 가시성을 갖춘 느슨하게 결합된 시스템을 가능하게 한다.
견고한 자동화가 특징이다.

 

• 위 4가지는 RedHat에서 얘기하는 CloudNative에 대한 정의 입니다.

클라우드 네이티브를 실현하기 전에
비즈니스 목적
해결 해야 하는 문제
를 먼저 정의 한 후에 진행 해야 합니다.

• 만약 비즈니스 적으로 생각한다면, Cloud Native를 왜 사용해야 할까? 라는 근본적인 물음에 도달 할 수 있습니다.
• 과연 이 기술을 쓰는 것이 많은 요소 중에서 이득일까?
• 인터넷에 보게 된다면, 여러가지 장점이 나열되어있습니다.
• 실제 스타트업에서 CTO를 맡으면서, Cloud 전환을 하면서 나온 장 단점을 나열해보겠습니다.

클라우드 전환 시 문제점

• FinOps라는 개념이 생겼습니다.
  • 클라우드로 전환이 되면서, 많은 서비스를 테스트 하고, 해당 부분에 대한 관리가 미흡해질 때가 있습니다.
  • 만약 클라우드에서 관리 미흡이 된다면, 클라우드는 사용량으로 요금을 부과하게 되므로, 지속적으로 지출 되면 안되는 돈이 지출 되게 됩니다.
  • 이런 쓸데 없는 지출을 막기 위해서 새로운 FinOps라는 개념이 생기게 됩니다.

 

• 클라우드 기술 인력 부족
• 인원은 그대로이지만, 할일이 늘어났다.
  • 학습 해야할 기술들이 늘어났고, 관리해야할 것들이 늘어났기 때문

DevOps를 추구하기 위해서는 많은 기술들의 검증 및 사용이 필요

새로운 인력에 대한 기대

• 새로운 인력을 충원하여서, DevOps 혹은 클라우드 전향을 생각하고, 구인을 하였다.
• 하지만, 들어오는 사람들은 현재 우리들의 기술 수준이 맞는 사람들만 들어오게 된다.
• 결국은 우리가 그러한 사람들이 들어올 수 있게 그 환경을 맞춰 놓고, 구인을 해야한다

클라우드 전환

첫 걸음 IaC

• IaC(infrastructure as code)를 통해서 인프라 셋팅의 재사용성을 늘려야한다.

컨테이너 도입

• Container 환경을 도입할 때 가장 많이 비교 되는 환경은 VM입니다.
• 하지만, VM과 Container는 추상화 수준이 아예 다릅니다. 애초부터 비교 대상이 아닙니다.

VM과 Container의 차이점

• VM은 하드웨어의 추상화 입니다.
• 하드웨어를 격리 시켜서 각각을 서버로 사용하는 것이죠.
• 하지만, Container는 서비스의 추상화 입니다.
• 서비스 단위로 Container를 구성하여 쪼개서 사용하는 것을 의미합니다.

 

• VM환경에서 Container 환경으로 변경될 때의 장점은 재사용성입니다.
• 즉, 윗 그림처럼 순서가 다릅니다.
• 인프라에서 서버를 셋팅할 때, VM은 우선 Linux 생성하고 설정을 하는 편입니다.
• Container 에서는 우선 Application에 맞게 환경을 설정하고, 생성을 하는 편입니다.
• 즉, Container로 변경하게 된다면, 인프라 적으로 해당 셋팅을 저장 후 재 사용성이 늘어나게 됩니다.
• 해당 서비스가 커지면서, 관리가 힘들다면, 그 때부턴 서비스 인프라의 추상화인 Kubernetes를 사용하는 것입니다.
  • 해당 Kubernetes를 도입하게 된다면, 신기술을 많이 사용할 수 밖에 없다.
  • Kubernetes, Kubernetes관리 도구, Kubernetes를 모니터링 하는 도구 등등,,
  • 많은 도구들을 도입하다보니, 해당 DevOps 의 병목이 생기기 마련입니다.
  • 즉, 이러한 병목 현상 때문에 DevOps는 최대한 자동화를 추구해야합니다.

• 그렇기 때문에, 모듈화, 자동화, 재 사용성을 높여야합니다.
• 개발자가 담당할 영역과 운영자가 담당할 영역, 최고 관리자가 담당할 영역을 나누며 일을 진행 해야 합니다.

재복구, 이중화

• 우선 세션에 들어가기 전에 간단한 용어 정리를 하겠습니다.

용어	설명
RPO	설정된 복구 목표 데이터 양 혹은 시점
RTO	설정된 최대 복구 지연 시간
Disaster	재해, 데이터 센터 서비스 불가 상태, 폭격 등
GTM(GSLB)	글로벌 트래픽 관리자, 글로벌 로드 밸런서
ACM	RedHat Advanced Cluster Managment for Kubernetes, OCP
OCP	RedHat Openshift Container Platform
ODF	RedHat Openshift Data Foundation

• RedHat Openshift에 대한 홍보 세미나 이기에, 관련 용어들이 조금 나오게 됩니다.  
• RedHat Openshift에 대한 자세한 내용은 아래의 사이트를 참조해주세요
  http://www.opennaru.com/redhat/openshift/

OPENSHIFT - 최고의 컨테이너 플랫폼 - Opennaru, Inc.

 

• 재난 상황에서는 데이터를 이중화 시키는 것이 중요한 화두이다.
• 이전 카카오 사건과 네이버의 예시만 봐도 알 수 있다.
• 하지만, 보통 데이터에 대한 것은 이중화를 시키지만, 운영하고 있는 서비스의 MetaData를 옮기는 것이 가장 중요한 요소이다.
  • 이유인 즉, IP, firewall에 대한 셋팅 등등이 갖춰져있지 않다면, Application Data만으로도 엄청나게 오래 걸릴 것이다.
  • 해당 OpenShift는 이런 3Way로 안전하게 구성할 수 있다.
    해당 세션은 Container Day와 관계가 멀기 때문에, 짧게 끝맺었습니다.

컨테이너 보안

• 흔히 컨테이너를 사용을 하지, 보안에는 신경을 쓰지 않습니다.

 

• 하지만, VM 대신 컨테이너로 사용하고 있는 만큼, 즉 인프라를 사용하는 만큼 신경 써야 할 것은 보안입니다.
• NIST SP 800-190 Application Container Security Guide
  • 위의 가이드 문서에는 해당 Container의 보안에 대한 규정을 가이드하고 있습니다.

컨테이너의 보안 표준화

• 컨테이너 보안은 주요 관심사 중 하나입니다.
• 컨테이너 사용의 59%는 해결되지 않는 보안 및 규정 준수 하고 있습니다.
• 요구사항 또는 컨테이너에 대한 위협에 대해 표준이 없으면 자동화 할 수 있는 방안이 없습니다.

• 표준이 없다면, 상자의 크기가 모두 다르기 때문에, 생태계를 활성화 하기는 불가능합니다.
  • 자동화 : 현대의 컨테이너 항구와 같이 완전히 자동화된 환경에서 장애는 경제적으로 치명적인 손실을 발생시킴
    • CI/CD
  • 표준 : 단순한 것, 상호 운용성을 위한 정확한 규격이 필요
    • File & Metadata

컨테이너 표준 + 보안

• 다양한 기구와 단체들이 Container & Kubernetes의 표준을 만들고 있습니다.

NIST SP 800-190 Application Container Security Guide

• 국내에서는 컨테이너 보안 규정 가이드라인이 없습니다.
• 하나의 규정에 대한 가이드는 쉽지 않습니다.

컨테이너 구성 요소 핵심

1. Developer Systems : 이미지를 구축하고 검증 환경에 배포
2. Testing & accredition systems : 콘텐츠 검사나 이미지 서명을 레지스트리에 저장

컨테이너 기술의 핵심 구성요소에 대한 주요 위험 요소

평가의 대상 및 목적

• 컨테이너 기술의 주요 구성 요소인 Image Registry, Orchestration, Container, Host OS에 대한 주요 위험 분석을 고려해야한다.

고려해야할 위협

• Image or Container 권한
• Container를 악용한 다른 컨테이너 Host OS 다른 Host OS에 대한 공격

Image Risk

• 이미지 취약점
• Dockerfile 및 이미지 설정의 미비
• 악성 코드 포함
• 인정 정보 포함 → DB 인증 정보 등
• 신뢰 할 수 없는 이미지 사용

Registry Risk

 

• 비보안 통신의 이용 (HTTP)
• 사용하지 않는 이미지의 취약점
• 인증 및 승인의 미비

Orchestrator Risk

• 사용자 계정 및 권한 관리 미비
• 잘못된 컨테이너 네트워크 분리
• 서로 다른 수준의 워크로드 혼재
• Master와 Node의 신뢰성

Container Risk

• 런타임 소프트웨어의 약점
• 제한 없는 네트워크 접근
• 안전하지 않는 컨테이너 런타임 설정
• 어플리케이션의 취약점

Host OS Risk

• Host OS의 취약점 여부
• 커널 공유
• 불필요한 사용자 권한 부여
• 파일 시스템의 변조

컨테이너 이미지 위협 요소 및 방안

• 컨테이너를 통해 인프라 시스템 전체를 파괴할 수 있다.
• 애플리케이션에 알려진 취약점은 모두 확인이 완료 되었는지, 런타임 OS는 최신 상태인지 체크 해야한다.

Container에 대한 취약성을 보여주는 Clair을 사용하면 취약성을 체크 할 수 있다.

클라우드 네이티브 CI/CD

클라우드 네이티브 CI/CD를 구축할 때 가장 중요한 부분은 CD 부분 입니다.
CD는 종류 별로 두 가지가 존재합니다.

Code Deployment

• Code Delivery의 경우에는 Devloper가 개발을 하고 Git에 push 넣게 된다면, 해당 Jenkins와 같은 CD 프로그램이 이를 감지합니다.
• 그리고 바로 운영 서버에 자동으로 반영 됩니다.

Code Delivery

• Code Delivery는 위의 상태처럼 모두 Automatic 상태로 돌린 다음에, 배포 담당자가 운영 서버에 배포를 결정하는 개념입니다.

Container를 이용한 CI/CD 구조

• Container를 이용하게 된다면, 해당 CI/CD pipeline의 구조는 아래와 같습니다.

• ECR → AWS Container Registry
• Kubernetes 환경에 들어오게 된다면, Jenkins에서 나오는 환경이 잘 호환이 되지 않습니다.
• 그렇다 보니, Kubernetes를 반영한 최신 CD 프로그램인 Tekton Hub를 이용해서, CD를 관리하게 됩니다.

• Tekton Hub는 Jenkins를 만든 Linux Foundation에서 만든 Kubernetes의 호환성을 반영한 최신 CD 프로그램 입니다.
• 위의 프로그램을 통해서 Kubernetes환경에서 CD를 구축 할 수 있습니다.
• Kubernetes CI/CD
• Application이 자동 배포가 되는 것 처럼, Kubernetes도 자동 배포가 필요합니다.
• 이를 통한 새로운 개념이 생기게 됩니다.

GitOps

GitOps란?

인프라의 배포와 운영에 관련된 모든 요소를 코드화하여 깃(Git)에서 관리(Ops)하는 것이 깃옵스의 핵심입니다.
기본 개념은 코드를 이용하여 인프라를 프로비저닝 하고 관리하는 IaC(Infrastructure as Code)에서 나온 것으로 깃옵스는 이를 인프라에서 전체 애플리케이션 범위로 확장하였습니다.

• GitOps라는 새로운 개념으로 Kubernetes를 관리하게 됩니다.

GitOps의 원칙

1. 모든 시스템은 선언적으로 선언되어야한다.
2. 시스템의 상태는 Git의 버전을 따라간다.
3. 승인된 변화는 자동으로 시스템에 적용된다.
4. 배포에 실패하면 이를 사용자에게 경고해야 한다.

ArgoCD

ArgoCD란?

Kubernetes를 위한 CD 툴 이라고 할 수 있습니다.

• Kubernetes의 구성 요소들은 관리 및 배포하기 위해서는 Manifest파일을 구성하여 실행해야 하며,
• 이러한 파일들은 계속해서 변경되기에 지속적인 관리가 필요합니다.
• Git에서 버전 관리 되는 클러스터 및 애플리케이션 구성
• Git에서 클러스터로 구성을 자동으로 동기화
• 드리프트 감지, 시각화 및 조치
• 복잡한 롤아웃에 대한 동기화 순서에 대한 세부적인 제어
• 모든 Git 커밋으로 롤백 및 롤 포워드
• 매니페스트 템플릿 지원(Helm, Kustomize, etc)
• 동기화 상태 및 기록에 대한 시각적 통찰력