강2월드

2022.12.26 - [DevOps/aws] - AWS Cloud Practitioner Essentials | 모듈1: AMAZON WEB SERVICES 소개

2022.12.26 - [DevOps/aws] - AWS Cloud Practitioner Essentials | 모듈 2: 클라우드 컴퓨팅

2022.12.27 - [DevOps/aws] - AWS Cloud Practitioner Essentials | 모듈 3: 글로벌 인프라 및 안정성

모듈 4 소개

학습 목표

• 네트워킹의 기본 개념을 설명할 수 있습니다.
• 퍼블릭 네트워킹 리소스와 프라이빗 네트워킹 리소스의 차이점을 설명할 수 있습니다. 
• 실제 시나리오를 사용하여 가상 프라이빗 게이트웨이를 설명할 수 있습니다. 
• 실제 시나리오를 사용하여 Virtual Private Network(VPN)를 설명할 수 있습니다.
• AWS Direct Connect의 이점을 설명할 수 있습니다. 
• 하이브리드 배포의 이점을 설명할 수 있습니다. 
• IT 전략에서 사용되는 보안 계층을 설명할 수 있습니다.
• 고객이 AWS 글로벌 네트워크와 상호 작용하기 위해 사용하는 서비스를 설명할 수 있습니다.

vpc

사용자가 정의한 가상 네트워크에서 AWS 리소스를 실행할 수 있는 논리적으로 격리된 aws 클라우드 섹션을 프로비저닝 할 수 있다.

AWS 와의 연결

Amazon Virtual Private Cloud(Amazon VPC)

vpc는 본질적으로 aws에서의 사용자 고유 프라이빗 네트워크 입니다.

서브넷은 vpc 내의 ip 주소 모음으로 리소스를 그룹화 할 수 있게 도와준다 .

AWS 서비스를 사용하는 수백만 명의 고객을 상상해 보십시오. 또한 이들 고객이 생성한 Amazon EC2 인스턴스와 같은 수백만 개의 리소스를 상상해 보십시오. 이러한 모든 리소스에 경계가 없으면 네트워크 트래픽이 제한 없이 리소스 간에 흐를 수 있습니다. 

AWS 리소스에 경계를 설정하는 데 사용할 수 있는 네트워킹 서비스가 Amazon Virtual Private Cloud(Amazon VPC)입니다.

=> VPC 로 네트워크 간 경계를 만든다.

Amazon VPC를 사용하여 AWS 클라우드의 격리된 섹션을 프로비저닝할 수 있습니다. 이 격리된 섹션에서는 사용자가 정의한 가상 네트워크에서 리소스를 시작할 수 있습니다. 한 Virtual Private Cloud(VPC) 내에서 여러 서브넷으로 리소스를 구성할 수 있습니다. 서브넷은 리소스(예: Amazon EC2 인스턴스)를 포함할 수 있는 VPC 섹션입니다.

인터넷 게이트웨이

인터넷의 퍼블릭 트래픽이 VPC에 액세스하도록 허용하려면 인터넷 게이트웨이를 VPC에 연결합니다.

=> 인터넷 게이트웨이를 통해 퍼블릭 트래픽이 vpc에 액세스 할 수 있다.

인터넷 게이트웨이는 VPC와 인터넷 간의 연결입니다. 인터넷 게이트웨이는 고객이 커피숍에 들어가기 위해 사용하는 출입문과 비슷한 것으로 생각할 수 있습니다. 인터넷 게이트웨이가 없으면 아무도 VPC 내의 리소스에 액세스할 수 없습니다.

가상 프라이빗 게이트웨이

VPC 내의 비공개 리소스에 액세스하려면 가상 프라이빗 게이트웨이를 사용할 수 있습니다. 

다음은 가상 프라이빗 게이트웨이 작동 방식의 예입니다. 인터넷은 집과 커피숍 사이의 도로로 생각할 수 있습니다. 이 도로를 보디가드와 함께 지나간다고 가정해 보십시오. 다른 고객과 동일한 도로를 사용하고 있지만 추가 보호 계층이 있습니다.

보디가드는 주변의 다른 모든 요청으로부터 인터넷 트래픽을 암호화(또는 보호)하는 가상 프라이빗 네트워크(VPN) 연결과 같습니다. 

가상 프라이빗 게이트웨이는 보호된 인터넷 트래픽이 VPC로 들어오도록 허용하는 구성 요소입니다. 커피숍까지 가는 도로에는 추가적인 보호 기능이 있지만 다른 고객과 동일한 도로를 사용하고 있기 때문에 교통 체증이 발생할 수 있습니다. 

가상 프라이빗 게이트웨이를 사용하면 VPC와 프라이빗 네트워크(예: 온프레미스 데이터 센터 또는 회사 내부 네트워크) 간에 가상 프라이빗 네트워크(VPN) 연결을 설정할 수 있습니다. 가상 프라이빗 게이트웨이는 승인된 네트워크에서 나오는 트래픽만 VPC로 들어가도록 허용합니다.

=> 가상 프라이빗 게이트웨이를 통해 특정한 네트워크(VPN)로부터의 접속만 허용할 수 있다.

AWS Direct Connect

AWS Direct Connect가 제공하는 비공개 연결은 네트워크 비용을 절감하고 네트워크를 통과할 수 있는 대역폭을 늘리는 데 도움이 됩니다.

=> AWS Direct connect 를 통해 데이터 센터와 vpc 사이의 전용 연결을 설정할 수 있다. 

서브넷 및 네트워크 액세스 제어 목록

vpc 에 들어가기 위해서 게이트웨이를 걸쳐야한다.

vpc에서 서브넷을 사용해야하는 유일한 기술적인 이유는 게이트웨이에 대한 액세스 관리를 위해서이다. 

인터넷 게이트 웨이 -> acl( 서브넷 경계) -> 보안그룹 (인스턴스 단에서 )

보안그룹 

인바운드는 체크하지만

아웃바운드는 들어온 패킷에 대해서는 자유롭게 나가게 해준다. 

보안그룹은 상태를 저장한다.

acl은 stateless 하다.( 상태 비저장)

들어오고 나갈때 다 체크한다.

VPC 내에서 서브넷의 역할에 대해 자세히 알아보기 위해 다음과 같은 커피숍 예를 살펴보겠습니다.

먼저, 고객이 계산원에게 음료를 주문합니다. 그러면 계산원이 바리스타에게 주문을 전달합니다. 이 프로세스를 통해 더 많은 고객이 들어오더라도 계속 원활하게 주문을 받을 수 있습니다. 

일부 고객이 계산원을 건너 뛰고 바리스타에게 직접 주문하려 한다고 가정해 보십시오. 그러면 주문 흐름이 중단되고 고객이 커피숍의 제한 구역에 접근하게 됩니다.

=> 고객이 바리스타에게 바로 접근하는 경우를 막아야한다.

이는 AWS 네트워킹 서비스를 사용하여 리소스를 격리하고 네트워크 트래픽의 흐름을 정확히 결정하는 것과 비슷합니다.

커피숍의 카운터 영역을 VPC로 생각할 수 있습니다. 카운터 영역은 계산원의 워크스테이션과 바리스타의 워크스테이션을 위해 두 개의 영역으로 나뉩니다. VPC에서 서브넷은 리소스를 그룹화하는 데 사용되는 별개의 영역입니다.

=> vpc 내를 서브넷 으로 그룹화 한다. 

서브넷

서브넷은 보안 또는 운영 요구 사항에 따라 리소스를 그룹화할 수 있는 VPC 내의 한 섹션입니다. 서브넷은 퍼블릭 또는 프라이빗일 수 있습니다.

퍼블릭 서브넷에는 온라인 상점의 웹 사이트와 같이 누구나 액세스할 수 있어야 하는 리소스가 포함됩니다.

프라이빗 서브넷에는 고객의 개인 정보 및 주문 내역이 포함된 데이터베이스와 같이 프라이빗 네트워크를 통해서만 액세스할 수 있는 리소스가 포함됩니다. 

VPC 내에서 서브넷은 서로 통신할 수 있습니다. 예를 들어 퍼블릭 서브넷에 있는 Amazon EC2 인스턴스가 프라이빗 서브넷에 있는 데이터베이스와 통신하는 애플리케이션이 있을 수 있습니다.

=> 퍼블릭 서브넷과 프라이빗 서브넷으로 나뉜다.

VPC의 네트워크 트래픽

고객이 AWS 클라우드에서 호스팅되는 애플리케이션에 데이터를 요청하면 이 요청은 패킷으로 전송됩니다. 패킷은 인터넷이나 네트워크를 통해 전송되는 데이터의 단위입니다.

=> 패킷 단위로 전송된다.

패킷은 인터넷 게이트웨이를 통해 VPC로 들어갑니다. 패킷이 서브넷으로 들어가거나 서브넷에서 나오려면 먼저 권한을 확인해야 합니다. 이러한 사용 권한은 패킷을 보낸 사람과 패킷이 서브넷의 리소스와 통신하려는 방법을 나타냅니다.

=> 패킷은 인터넷 게이트웨이를 거쳐 vpc로 진입한다.

서브넷의 패킷 권한을 확인하는 VPC 구성 요소는 네트워크 ACL(액세스 제어 목록)입니다.

네트워크 ACL(액세스 제어 목록)

각 AWS 계정에는 기본 네트워크 ACL이 포함됩니다. VPC를 구성할 때 계정의 기본 네트워크 ACL을 사용하거나 사용자 지정 네트워크 ACL을 생성할 수 있습니다. 

=> 서브넷 단에 진입할 때 네트워크 ACL을 거친다.

 

계정의 기본 네트워크 ACL은 기본적으로 모든 인바운드 및 아웃바운드 트래픽을 허용하지만 사용자가 자체 규칙을 추가하여 수정할 수 있습니다. 사용자 지정 네트워크 ACL은 사용자가 허용할 트래픽을 지정하는 규칙을 추가할 때까지 모든 인바운드 및 아웃바운드 트래픽을 거부합니다. 또한 모든 네트워크 ACL에는 명시적 거부 규칙이 있습니다. 이 규칙은 패킷이 목록의 다른 모든 규칙과 일치하지 않으면 해당 패킷이 거부되도록 합니다. 

상태 비저장 패킷 필터링

기본적으로 보안 그룹은 모든 인바운드 트래픽을 거부하고 모든 아웃바운드 트래픽을 허용합니다. 사용자 지정 규칙을 추가하여 허용 또는 거부할 트래픽을 구성할 수 있습니다.

=> 상태 저장, 인바운드로 인스턴스를 통과한 경우 나갈때 모든 아웃바운드 트래픽을 허용한다.

 

예를 들어 로비에서 방문객을 안내하는 경비원이 있는 아파트 건물을 생각해 보십시오. 방문객을 패킷으로 생각할 수 있으며 경비원을 보안 그룹으로 생각할 수 있습니다. 방문객이 도착하면 경비원은 방문객 목록을 보고 해당 방문객이 건물 안으로 들어갈 수 있는지 확인합니다. 그러나 방문객이 건물에서 나갈 때는 경비원이 목록을 다시 확인하지 않습니다.

서브넷 내에 여러 Amazon EC2 인스턴스가 있는 경우 동일한 보안 그룹에 연결하거나 각 인스턴스마다 서로 다른 보안 그룹을 사용할 수 있습니다. 

인터넷 게이트웨이 -> acl -> sg 순으로 점검

글로벌 네트워킹

사용자는 어떻게 aws 인프라와 상호 작요할까?

dns는 웹사이트 네임을 인터넷 프로토콜로 번역한다. 

cdn: 지리적 위치를 기반으로 사용자에게 엣지 콘텐츠를 제공하는 네트워크

Domain Name System(DNS)

1. 브라우저에 도메인 이름을 입력하면 이 요청이 DNS 서버로 전송됩니다. 

2. DNS 서버는 웹 서버에 AnyCompany 웹 사이트에 해당하는 IP 주소를 요청합니다.

3.웹 서버는 AnyCompany 웹 사이트의 IP 주소인 192.0.2.0을 제공하여 응답합니다.

1. 고객이 AnyCompany의 웹 사이트로 이동하여 애플리케이션에서 데이터를 요청합니다. 

2. Amazon Route 53는 DNS 확인을 사용하여 AnyCompany.com의 IP 주소인 192.0.2.0을 식별합니다. 이 정보는 고객에게 다시 전송됩니다.

3. 고객의 요청은 Amazon CloudFront를 통해 가장 가까운 엣지 로케이션으로 전송됩니다. 

4. Amazon CloudFront는 수신 패킷을 Amazon EC2 인스턴스로 전송하는 Application Load Balancer에 연결됩니다.

모듈 4 퀴즈

회사에 Amazon EC2 인스턴스를 사용하여 고객 대상 웹 사이트를 실행하고 Amazon RDS 데이터베이스 인스턴스를 사용하여 고객의 개인 정보를 저장하는 애플리케이션이 있습니다. 모범 사례에 따르면 개발자는 VPC를 어떻게 구성해야 합니까?

다음 중 회사의 데이터 센터와 AWS 간에 비공개 전용 연결을 설정하는 데 사용할 수 있는 구성 요소는 무엇입니까?

다음 중 보안 그룹을 가장 잘 설명한 것은 무엇입니까?

다음 중 VPC를 인터넷에 연결하는 데 사용되는 구성 요소는 무엇입니까?

다음 중 도메인 이름의 DNS 레코드를 관리하는 데 사용되는 서비스는 무엇입니까?

2022.12.26 - [DevOps/aws] - AWS Cloud Practitioner Essentials | 모듈1: AMAZON WEB SERVICES 소개

2022.12.26 - [DevOps/aws] - AWS Cloud Practitioner Essentials | 모듈 2: 클라우드 컴퓨팅

모듈3 소개

학습 목표

• AWS 글로벌 인프라의 이점을 요약할 수 있습니다.
• 가용 영역의 기본 개념을 설명할 수 있습니다.
• AWS CloudFront 및 엣지 로케이션의 이점을 설명할 수 있습니다.
• Amazon 서비스를 프로비저닝할 수 있는 다양한 방법을 비교할 수 있습니다.

AWS 글로벌 인프라

리전 선택

서비스, 데이터 및 애플리케이션에 적합한 리전을 결정할 때 다음 네 가지 비즈니스 요소를 고려해야 합니다. 

1. 데이터 거버넌스 및 법적 요구 사항 준수 

회사와 위치에 따라 특정 영역에서 데이터를 실행해야 할 수도 있습니다. 예를 들어 회사에 모든 데이터를 영국 내부에 유지해야 한다는 규정이 있는 경우 런던 리전을 선택합니다. 

=> 법적 요구 사항 만족하기

2. 고객과의 근접성

고객과 가까운 리전을 선택하면 고객에게 콘텐츠를 더 빠르게 제공하는 데 도움이 됩니다. 예를 들어 본사는 워싱턴 DC에 있고 고객 중 다수가 싱가포르에 거주하고 있다고 가정합니다. 인프라를 본사와 가까운 버지니아 북부 리전에서 실행할지, 고객과 가까운 싱가포르 리전에서 실행할지 고려해야 합니다.

=> 고객과 가까운 위치 선정

3. 리전 내에서 사용 가능한 서비스

4. 요금

가용 영역 

가용 영역은 리전 내의 단일 데이터 센터 또는 데이터 센터 그룹입니다. 가용 영역은 서로 수십 마일 떨어져 있습니다. 이 간격은 가용 영역 간의 지연 시간(콘텐츠가 요청된 시점과 수신된 시점 간의 차이)이 짧을 정도로 충분히 가깝습니다. 그러나 리전의 한 부분에서 재해가 발생할 경우 여러 가용 영역이 영향을 받을 가능성을 줄일 만큼 멀리 떨어져 있습니다.

=> 가용 영역이 모여서 리전을 구성한다. ( 리전은 가용 영역으로 이루어져 있다.)

여러 가용 영역으로 이루어져 있으면 장애 대응 잘 할 수 있다.

다음 중 가용 영역을 가장 잘 설명한 것은 무엇입니까?

엣지 로케이션

엣지 로케이션은 Amazon CloudFront가 더 빠른 콘텐츠 전송을 위해 고객과 가까운 위치에 콘텐츠 사본을 캐시하는 데 사용하는 사이트입니다.

엣지 로케이션과 리전은 다르다. 

cloudfront, route 53 도 엣지 로케이션을 사용할 수 있다. 

AWS 리소스를 프로비저닝하는 방법

AWS 서비스와 상호 작용하는 방법

AWS MANAGEMENT CONSOLE

AWS Management Console은 Amazon 서비스 액세스 및 관리를 위한 웹 기반 인터페이스입니다. 최근에 사용한 서비스에 빠르게 액세스하고 이름, 키워드 또는 약어로 다른 서비스를 검색할 수 있습니다. 콘솔에는 작업을 수행하는 프로세스를 단순화할 수 있는 마법사 및 자동화된 워크플로가 포함되어 있습니다.

AWS 명령줄 인터페이스

API 요청을 수행할 때 시간을 절약하기 위해 AWS 명령줄 인터페이스(AWS CLI)를 사용할 수 있습니다. AWS CLI를 사용하면 하나의 도구를 통해 명령줄에서 직접 여러 AWS 서비스를 제어할 수 있습니다. AWS CLI는 Windows, macOS 및 Linux 사용자가 사용할 수 있습니다.

AWS CLI를 사용하면 스크립트를 통해 서비스 및 애플리케이션이 수행하는 작업을 자동화할 수 있습니다. 예를 들어 Amazon EC2 인스턴스를 시작하고 Amazon EC2 인스턴스를 특정 Auto Scaling 그룹에 연결하는 등의 작업을 명령을 사용해 수행할 수 있습니다.

소프트웨어 개발 키트

AWS Elastic Beanstalk

AWS Elastic Beanstalk에서는 사용자가 코드 및 구성 설정을 제공하면 Elastic Beanstalk이 다음 작업을 수행하는 데 필요한 리소스를 배포합니다.

• 용량 조정
• 로드 밸런싱
• 자동 조정
• 애플리케이션 상태 모니터링

=> beanstalk 를 이용하면 환경 구성을 쉽게 할 수 있고 배포할 수 있다.

모든 구성 요소를 수동으로 관리할 필요없다.

AWS CloudFormation

다양한 AWS 리소스를 정의하는 데 사용되는 코드형 인프라 도구

AWS CloudFormation을 사용하여 인프라를 코드로 취급할 수 있습니다. 즉, AWS Management Console을 사용하여 개별적으로 리소스를 프로비저닝하는 대신 코드 줄을 작성하여 환경을 구축할 수 있습니다.

AWS CloudFormation은 리소스를 안전하고 반복 가능한 방식으로 프로비저닝하므로 수작업을 수행하거나 사용자 지정 스크립트를 작성할 필요 없이 인프라 및 애플리케이션을 빈번히 구축할 수 있습니다. 이 서비스는 스택을 관리할 때 수행해야 할 적절한 작업을 결정하고 오류를 감지하면 변경 사항을 자동으로 롤백합니다.

모듈3 퀴즈

다음 중 AWS 글로벌 인프라에 대한 올바른 설명은 무엇입니까?

리전을 선택할 때 고려해야 할 요소는 무엇입니까? (2개 선택)

다음 중 Amazon CloudFront를 가장 잘 설명한 것은 무엇입니까?

다음 중 Amazon CloudFront에서 사용자가 어느 위치에 있든 콘텐츠를 더 빠르게 전송하기 위해 콘텐츠 복사본을 캐싱하는 데 사용하는 사이트는 무엇입니까?

다음 중 AWS Outposts로 수행할 수 있는 작업은 무엇입니까?

AWS Outposts은(는) AWS 인프라, 서비스, API 및 도구를 고객 온프레미스로 확장하는 완전관리형 서비스입니다. AWS 관리형 인프라에 대한 로컬 액세스를 제공하는 AWS Outposts을(를) 통해 고객은 AWS 리전에서 사용하는 것과 동일한 프로그래밍 인터페이스를 사용해 온프레미스에서 애플리케이션을 구축하고 실행할 수 있으며, 짧은 지연 시간과 로컬 데이터 처리가 필요한 경우에 로컬 컴퓨팅 및 스토리지 리소스를 사용할 수 있습니다.

Outposts는 고객 사이트에 배포된 AWS 컴퓨팅 및 스토리지 용량 풀입니다. AWS는 이 용량을 AWS 리전의 일부로 운영, 모니터링 및 관리합니다. Outposts에 서브넷을 만들고 EC2 인스턴스, EBS 볼륨, ECS 클러스터 및 RDS 인스턴스와 같은 AWS 리소스를 생성할 때 해당 서브넷을 지정할 수 있습니다. Outposts 서브넷의 인스턴스는 프라이빗 IP 주소를 사용하여 AWS 리전의 다른 인스턴스와 통신합니다(모두 동일한 VPC에 있음).

=> AWS Outposts aws환경을 온프레미스에서 구현하게 도와줌. 랙과 서버를 제공한다.

2022.12.26 - [DevOps/aws] - AWS Cloud Practitioner Essentials | 모듈1: AMAZON WEB SERVICES 소개

모듈 2 소개

이번 모듈에서는 EC2, Auto Scaling, Elastic Load Balancing, Amazon Simple Notification Service, Amazon Simple Queue Service 등 간단하게 훑어볼 것이다. 

Amazon Elastic Compute Cloud(Amazon EC2)

멀티 테넌시: 가상 컴퓨터 간 기본 하드웨어 공유

Amazon Elastic Compute Cloud(Amazon EC2)는 안전하고 크기 조정이 가능한 컴퓨팅 용량을 Amazon EC2 인스턴스로 클라우드에서 제공합니다. 

빠른 프로비저닝, 인스턴스 확장,축소가능, 온디멘드 요금

Amazon EC2 작동 방식

Amazon EC2 인스턴스 유형

Amazon EC2 인스턴스 유형은 다양한 작업에 최적화되어 있습니다. 

범용 인스턴스

범용 인스턴스는 컴퓨팅, 메모리, 네트워킹 리소스를 균형 있게 제공합니다.

• 애플리케이션 서버
• 게임 서버
• 엔터프라이즈 애플리케이션용 백엔드 서버
• 중소 규모 데이터베이스

컴퓨팅 최적화 인스턴스

컴퓨팅 최적화 인스턴스는 고성능 프로세서를 활용하는 컴퓨팅 집약적인 애플리케이션에 적합합니다. 범용 인스턴스와 마찬가지로 컴퓨팅 최적화 인스턴스는 웹 서버, 애플리케이션 서버, 게임 서버와 같은 워크로드에 사용할 수 있습니다.

하지만 컴퓨팅 최적화 애플리케이션은 고성능 웹 서버, 컴퓨팅 집약적 애플리케이션 서버 및 게임 전용 서버에 적합하다는 점이 다릅니다. 

메모리 최적화 인스턴스

메모리 최적화 인스턴스는 메모리에서 대규모 데이터 세트를 처리하는 워크로드를 위한 빠른 성능을 제공하기 위해 설계되었습니다. 컴퓨팅에서 메모리는 임시 스토리지 영역입니다. 여기에는 중앙 처리 장치(CPU)가 작업을 완료하는 데 필요한 모든 데이터와 명령이 들어 있습니다.

메모리 최적화 인스턴스를 사용하면 많은 메모리가 필요한 워크로드를 실행하고 뛰어난 성능을 얻을 수 있습니다.

액셀러레이티드 컴퓨팅 인스턴스

액셀러레이티드 컴퓨팅 인스턴스는 하드웨어 액셀러레이터 또는 코프로세서를 사용하여 일부 기능을 CPU에서 실행되는 소프트웨어에서보다 더 효율적으로 수행합니다. 이러한 기능의 예로는 부동 소수점 수 계산, 그래픽 처리, 데이터 패턴 일치 등이 있습니다.

컴퓨팅에서 하드웨어 액셀러레이터는 데이터 처리를 가속화할 수 있는 구성 요소입니다. 액셀러레이티드 컴퓨팅 인스턴스는 그래픽 애플리케이션, 게임 스트리밍, 애플리케이션 스트리밍과 같은 워크로드에 적합합니다.

스토리지 최적화 인스턴스

스토리지 최적화 인스턴스는 로컬 스토리지의 대규모 데이터 세트에 대한 순차적 읽기 및 쓰기 액세스가 많이 필요한 워크로드를 위해 설계되었습니다. 스토리지 최적화 인스턴스에 적합한 워크로드의 예로는 분산 파일 시스템, 데이터 웨어하우징 애플리케이션, 고빈도 온라인 트랜잭션 처리(OLTP) 시스템 등이 있습니다.

컴퓨팅에서 IOPS(초당 입출력 작업 수)라는 용어는 스토리지 디바이스의 성능을 측정하는 지표입니다. IOPS는 디바이스가 1초 내에 수행할 수 있는 입력 또는 출력 작업의 수를 나타냅니다. 스토리지 최적화 인스턴스는 지연 시간이 짧은 임의 IOPS를 애플리케이션에 제공하도록 설계되었습니다.

입력 작업은 데이터베이스에 입력되는 레코드와 같이 시스템에 투입되는 데이터라고 생각할 수 있습니다. 출력 작업은 서버에서 생성된 데이터입니다. 출력의 예로는 데이터베이스의 레코드에 대해 수행되는 분석을 들 수 있습니다. IOPS 요구 사항이 높은 애플리케이션이 있는 경우 스토리지 최적화 인스턴스는 이러한 종류의 사용 사례에 최적화되지 않은 다른 인스턴스 유형보다 나은 성능을 제공할 수 있습니다.

Amazon EC2 요금

Amazon EC2에서는 사용한 컴퓨팅 시간에 대해서만 비용을 지불합니다. Amazon EC2는 사용 사례에 따라 다양한 요금 옵션을 제공합니다.

온디맨드

온디맨드 인스턴스는 중단할 수 없는 불규칙한 단기 워크로드가 있는 애플리케이션에 매우 적합합니다. 선결제 비용이나 최소 약정은 적용되지 않습니다. 인스턴스는 중지될 때까지 계속 실행되며, 사용한 컴퓨팅 시간에 대해서만 비용을 지불합니다.

온디맨드 인스턴스의 사용 사례에는 애플리케이션 개발 및 테스트와 예측할 수 없는 사용 패턴이 있는 애플리케이션 실행이 포함됩니다. 온디맨드 인스턴스는 1년 이상 지속되는 워크로드에는 권장하지 않습니다. 이러한 워크로드는 예약 인스턴스를 사용하면 비용 절감 효과가 더 크기 때문입니다.

=> 온디맨드로는 평균 사용량을 확인하는 용도

Amazon EC2 Savings Plans

AWS는 Amazon EC2를 비롯한 여러 컴퓨팅 서비스에 대한 Savings Plans를 제공합니다. Amazon EC2 Savings Plans를 사용하면 1년 또는 3년 기간 동안 일정한 컴퓨팅 사용량을 약정하여 컴퓨팅 비용을 절감할 수 있습니다. 이 기간 약정을 통해 온디맨드 요금에 비해 최대 72%까지 비용을 절감할 수 있습니다.

약정 사용량까지는 할인된 Savings Plan 요금이 청구됩니다(예: 시간당 10 USD). 약정을 초과한 사용량에 대해서는 일반 온디맨드 요금이 부과됩니다.

이 과정의 뒷부분에서 시간 경과에 따라 AWS 비용 및 사용량을 시각화, 이해 및 관리할 수 있는 도구인 AWS Cost Explorer를 살펴봅니다. Savings Plans 옵션을 고려하고 있는 경우, AWS Cost Explorer를 통해 지난 7일, 30일 또는 60일 동안의 Amazon EC2 사용량을 분석할 수 있습니다. AWS Cost Explorer는 Savings Plans를 위한 맞춤형 권장 사항도 제공합니다. 이러한 권장 사항은 이전 Amazon EC2 사용량과 1년 또는 3년 Savings Plan의 시간당 약정 금액을 기준으로 월별 Amazon EC2 비용을 얼마나 절감할 수 있는지 예상합니다.

=> 일정 사용량을 약정한 후 사용

예약 인스턴스 

예약 인스턴스는 계정에서 온디맨드 인스턴스를 사용할 때 적용되는 결제 할인 옵션입니다. 표준 예약 및 컨버터블 예약 인스턴스는 1년 또는 3년 약정으로, 정기 예약 인스턴스는 1년 약정으로 구입할 수 있습니다. 3년 약정 옵션을 통해 더 큰 비용 절감을 실현할 수 있습니다.

예약 인스턴스 약정 기간이 끝나면 중단 없이 Amazon EC2 인스턴스를 계속 사용할 수 있습니다. 하지만 다음 중 하나를 수행할 때까지는 온디맨드 요금이 부과됩니다.

• 인스턴스 종료
• 인스턴스 속성(인스턴스 유형, 리전, 테넌시, 플랫폼)과 일치하는 새 예약 인스턴스를 구입

=> 온디맨드 요금을 지불할때 결제 할인 옵션이다. 

스팟 인스턴스

스팟 인스턴스는 시작 및 종료 시간이 자유롭거나 중단을 견딜 수 있는 워크로드에 적합합니다. 스팟 인스턴스는 미사용 Amazon EC2 컴퓨팅 용량을 사용하며 온디맨드 요금의 최대 90%까지 비용을 절감할 수 있습니다.

필요에 따라 시작 및 중지할 수 있는 백그라운드 처리 작업(예: 고객 설문 조사 데이터 처리 작업)이 있다고 가정해 보겠습니다. 전반적인 비즈니스 운영에는 영향을 주지 않고 처리 작업을 시작하고 중지하려고 합니다. 스팟 요청을 하고 Amazon EC2 용량을 사용할 수 있는 경우 스팟 인스턴스가 시작됩니다. 하지만 스팟 요청을 했는데 Amazon EC2 용량을 사용할 수 없다면 용량을 사용할 수 있을 때까지 요청이 성공하지 못합니다. 용량을 사용할 수 없으므로 백그라운드 처리 작업의 시작이 지연될 수 있습니다.

스팟 인스턴스를 시작한 후 용량을 더 이상 사용할 수 없거나 스팟 인스턴스에 대한 수요가 늘면 인스턴스가 중단될 수 있습니다. 이 경우 백그라운드 처리 작업에는 문제가 없을 수 있습니다. 하지만 앞에서 예로 든 애플리케이션 개발 및 테스트에서는 예기치 않은 중단을 방지하는 것이 좋습니다. 따라서 해당 작업에 더 적합한 다른 EC2 인스턴스 유형을 선택합니다.

전용 호스트

전용 호스트는 사용자 전용의 Amazon EC2 인스턴스 용량을 갖춘 물리적 서버입니다.

기존 소켓당, 코어당 또는 VM당 소프트웨어 라이선스를 사용하여 라이선스 규정 준수를 유지할 수 있습니다. 온디맨드 전용 호스트와 전용 호스트 예약을 구매할 수 있습니다. 지금까지 다룬 모든 Amazon EC2 옵션 중에서 전용 호스트가 가장 비용이 많이 듭니다.

Amazon EC2 확장

확장성

확장성을 위해서는 필요한 리소스만으로 시작하고 확장 및 축소를 통해 수요 변화에 자동으로 대응하도록 아키텍처를 설계해야 합니다. 그 결과, 사용한 리소스에 대해서만 비용을 지불합니다. 컴퓨팅 용량 부족 때문에 고객의 요구 사항을 충족할 수 없을지 걱정할 필요가 없습니다.

이 조정 프로세스가 자동으로 수행되도록 하려면 어떤 AWS 서비스를 사용해야 할까요? Amazon EC2 인스턴스에 이 기능을 제공하는 AWS 서비스가 Amazon EC2 Auto Scaling입니다.

=> auto scaling 을 통해서 고가용성을 가져간다. 

Amazon EC2 Auto Scaling

Amazon EC2 Auto Scaling에서는 동적 조정과 예측 조정이라는 두 가지 접근 방식을 사용할 수 있습니다.

• 동적 조정은 수요 변화에 대응합니다. 
• 예측 조정은 예측된 수요에 따라 적절한 수의 Amazon EC2 인스턴스를 자동으로 예약합니다.

Auto Scaling 그룹을 생성할 때 최소 Amazon EC2 인스턴스 수를 설정할 수 있습니다. 최소 용량은 Auto Scaling 그룹을 생성한 직후 시작되는 Amazon EC2 인스턴스의 수입니다. 이 예에서 Auto Scaling 그룹의 최소 용량은 Amazon EC2 인스턴스 1개입니다.

그런 다음 애플리케이션을 실행하려면 최소 하나의 Amazon EC2 인스턴스가 필요하더라도 희망 용량을 Amazon EC2 인스턴스 두 개로 설정할 수 있습니다.

Auto Scaling 그룹에서 설정할 수 있는 세 번째 구성은 최대 용량입니다. 예를 들어 수요 증가에 대응하여 확장하도록 Auto Scaling 그룹을 구성하되 Amazon EC2 인스턴스 수를 최대 4개로 제한할 수 있습니다.

Elastic Load Balancing을 사용하여 트래픽 리디렉션

Elastic Load Balancing은 들어오는 애플리케이션 트래픽을 Amazon EC2 인스턴스와 같은 여러 리소스에 자동으로 분산하는 AWS 서비스입니다. 

로드 밸런서는 Auto Scaling 그룹으로 들어오는 모든 웹 트래픽의 단일 접점 역할을 합니다. 즉, 들어오는 트래픽의 양에 맞춰 Amazon EC2 인스턴스를 추가하거나 제거하므로 이러한 요청이 로드 밸런서로 먼저 라우팅됩니다. 그런 다음 요청을 처리할 여러 리소스로 분산됩니다. 예를 들어 Amazon EC2 인스턴스가 여러 개인 경우 Elastic Load Balancing은 워크로드를 여러 인스턴스에 분산하므로 어느 한 인스턴스가 대량으로 워크로드를 처리할 필요가 없습니다.\

Elastic Load Balancing과 Amazon EC2 Auto Scaling은 별도의 서비스이지만 서로 연동하여 Amazon EC2에서 실행되는 애플리케이션이 뛰어난 성능과 가용성을 제공하도록 돕습니다.

=> 로드 밸런서가 트래픽을 여러 리소스에 분산 시키는 작업을 한다.

예: Elastic Load Balancing

수요가 적은 기간

다음은 Elastic Load Balancing이 어떻게 작동하는지 보여주는 예입니다. 고객 몇 명이 커피숍에 들어왔고 주문할 준비가 되었다고 가정해 보겠습니다.

계산대가 몇 개만 열려 있다면 이는 서비스가 필요한 고객의 수요와 일치합니다. 커피숍에서 고객이 없는 계산대를 열어 둘 가능성은 적습니다. 이 예에서는 계산대를 Amazon EC2 인스턴스로 생각할 수 있습니다.

수요가 많은 기간

하루 종일 고객의 수가 증가함에 따라 커피숍은 고객을 수용하기 위해 더 많은 계산대를 엽니다. 다이어그램에서 Auto Scaling 그룹이 이를 나타냅니다.

또한 커피숍 직원이 고객을 가장 적합한 계산대로 안내하여 주문이 열려 있는 계산대에 균등하게 분배될 수 있도록 합니다. 이 커피숍 직원을 로드 밸런서로 생각할 수 있습니다.

메시징 및 대기열

모놀리식 애플리케이션 및 마이크로서비스

애플리케이션은 여러 구성 요소로 구성됩니다. 구성 요소는 서로 통신하여 데이터를 전송하고, 요청을 이행하고, 애플리케이션을 계속 실행합니다. 

구성 요소가 밀결합된 애플리케이션이 있다고 가정해 보겠습니다.

이러한 구성 요소에는 데이터베이스, 서버, 사용자 인터페이스, 비즈니스 로직 등이 포함될 수 있습니다. 이러한 유형의 아키텍처를 모놀리식 애플리케이션으로 볼 수 있습니다. 

애플리케이션 아키텍처에 대한 이 접근 방식에서는 한 구성 요소에서 장애가 발생하면 다른 구성 요소에서 장애가 발생하고, 심지어 전체 애플리케이션에서 장애가 발생할 수도 있습니다.

-> 긴밀하게 연결되어 하나가 오류가 나면 다른 구성 요소에서 장애가 발생한다. 

단일 구성 요소에 장애가 발생했을 때 애플리케이션 가용성을 유지할 수 있도록 마이크로서비스 접근 방식을 통해 애플리케이션을 설계할 수 있습니다.

마이크로서비스 접근 방식에서는 애플리케이션 구성 요소가 소결합됩니다. 이 경우 단일 구성 요소에 장애가 발생해도 다른 구성 요소들은 서로 통신하기 때문에 계속 작동합니다. 소결합 때문에 전체 애플리케이션에서 장애가 발생하는 것이 방지됩니다. 

=> 느슨한 결합으로 장애 발생을 줄인다 .

AWS에서 애플리케이션을 설계할 때 다양한 기능을 수행하는 서비스 및 구성 요소를 사용하여 마이크로서비스 접근 방식을 취할 수 있습니다. 다음 두 서비스는 애플리케이션 통합을 촉진합니다. Amazon Simple Notification Service(Amazon SNS) 및 Amazon Simple Queue Service(Amazon SQS).

=> SQS, SNS 로 느슨한 결합을 가능하게 할 수 있다.

Amazon Simple Notification Service(Amazon SNS)

Amazon Simple Notification Service(Amazon SNS)는 게시/구독 서비스입니다. 게시자는 Amazon SNS 주제를 사용하여 구독자에게 메시지를 게시합니다. 이는 커피숍에서 계산원이 음료를 만드는 바리스타에게 주문 사항을 전달하는 것과 비슷합니다.

=> 엔드 유저에게도 메시지를 줄 수 있다.

Amazon SNS에서 구독자는 웹 서버, 이메일 주소, AWS Lambda 함수 또는 그 밖의 여러 옵션이 될 수 있습니다. 

Amazon Simple Queue Service(Amazon SQS)

Amazon Simple Queue Service(Amazon SQS)는 메시지 대기열 서비스입니다. 

Amazon SQS를 사용하면 메시지 손실이나 다른 서비스 사용 없이 소프트웨어 구성 요소 간에 메시지를 전송, 저장, 수신할 수 있습니다. Amazon SQS에서는 애플리케이션이 메시지를 대기열로 전송합니다. 사용자 또는 서비스는 대기열에서 메시지를 검색하여 처리한 후 대기열에서 삭제합니다.

계산원이 주문을 대기열에 넣습니다. 이를 계산원과 바리스타 사이의 버퍼 역할을 하는 주문판이라고 생각할 수 있습니다. 바리스타가 쉬는 시간이거나 다른 주문으로 바쁘더라도 계산원은 계속해서 새 주문을 대기열에 넣을 수 있습니다. 

분리된 애플리케이션과 마이크로서비스의 경우, Amazon SQS를 사용하면 구성 요소 간에 메시지를 전송, 저장, 검색할 수 있습니다.

개별 구성 요소는 이러한 분리된 접근 방식을 통해 보다 효율적이고 독립적으로 작동할 수 있습니다.

추가 컴퓨팅 서비스

Amazon EC2에서 실행하려는 애플리케이션이 있는 경우 

‘서버리스’라는 용어는 코드가 서버에서 실행되지만 이러한 서버를 프로비저닝하거나 관리할 필요가 없다는 뜻입니다. 서버리스 컴퓨팅을 사용하면 서버를 유지 관리하는 대신 새로운 제품과 기능을 혁신하는 데 더 집중할 수 있습니다.

=> 프로비저닝거나 관리할 필요가 없다는 뜻

서버리스 컴퓨팅의 또 다른 이점은 서버리스 애플리케이션을 자동으로 확장할 수 있는 유연성입니다. 서버리스 컴퓨팅은 처리량 및 메모리와 같은 소비 단위를 수정하여 애플리케이션의 용량을 조정할 수 있습니다. 

AWS Lambda

AWS Lambda는 서버를 프로비저닝하거나 관리할 필요 없이 코드를 실행할 수 있는 서비스입니다. 

AWS Lambda를 사용하는 경우 사용한 컴퓨팅 시간에 대해서만 비용을 지불합니다. 코드를 실행하는 동안에만 요금이 부과됩니다. 사실상 모든 유형의 애플리케이션 또는 백엔드 서비스 코드를 실행할 수 있으며 이를 관리할 필요는 전혀 없습니다. 

예를 들어 간단한 Lambda 함수로 업로드되는 이미지의 크기를 AWS 클라우드에 맞춰 자동으로 조정하는 함수가 있을 수 있습니다. 이 경우 새 이미지를 업로드할 때 함수가 트리거됩니다. 

AWS Lambda 작동 방식

1. 코드를 Lambda에 업로드합니다.

2. AWS 서비스, 모바일 애플리케이션 또는 HTTP 엔드포인트와 같은 이벤트 소스에서 트리거되도록 코드를 설정합니다.

3. Lambda는 트리거된 경우에만 코드를 실행합니다.

4. 사용한 컴퓨팅 시간에 대한 요금만 지불합니다. 위의 이미지 크기 조정 예에서는 새 이미지를 업로드할 때 사용한 컴퓨팅 시간에 대해서만 비용을 지불하면 됩니다. 이미지를 업로드하면 Lambda가 트리거되어 이미지 크기 조정 기능을 위한 코드를 실행합니다.

AWS에서는 컨테이너식 애플리케이션을 빌드하고 실행할 수도 있습니다.

컨테이너

컨테이너는 애플리케이션의 코드와 종속성을 하나의 객체로 패키징하는 표준 방식을 제공합니다. 보안성, 안정성, 확장성 요구 사항이 매우 중요한 프로세스 및 워크플로에도 컨테이너를 사용합니다.

컨테이너 오케스트레이션 서비스는 컨테이너식 애플리케이션을 배포, 관리, 확장하는 데 도움을 줄 수 있습니다. 다음에는 컨테이너 오케스트레이션을 제공하는 두 가지 서비스인 Amazon Elastic Container Service와 Amazon Elastic Kubernetes Service에 대해 알아보겠습니다.

Amazon Elastic Container Service(Amazon ECS)

Amazon Elastic Container Service(ECS)는 AWS에서 컨테이너식 애플리케이션을 실행하고 확장할 수 있는 확장성이 뛰어난 고성능 컨테이너 관리 시스템입니다. 

Amazon ECS는 Docker 컨테이너를 지원합니다. Docker는 애플리케이션을 신속하게 구축, 테스트, 배포할 수 있는 소프트웨어 플랫폼입니다. AWS는 오픈 소스 Docker Community Edition 및 구독 기반 Docker Enterprise Edition의 사용을 지원합니다. Amazon ECS에서는 API 호출을 사용하여 Docker 지원 애플리케이션을 시작 및 중지할 수 있습니다.

Amazon Elastic Kubernetes Service(Amazon EKS)

Amazon Elastic Kubernetes Service(Amazon EKS)는 AWS에서 Kubernetes를 실행하는 데 사용할 수 있는 완전 관리형 서비스입니다. 

Kubernetes는 컨테이너식 애플리케이션을 대규모로 배포하고 관리하는 데 사용할 수 있는 오픈 소스 소프트웨어입니다. 자원자로 구성된 대규모 커뮤니티에서 Kubernetes를 유지 관리하며, AWS는 Kubernetes 커뮤니티와 적극적으로 협력합니다. Kubernetes 애플리케이션의 새로운 기능이 릴리스되면 Amazon EKS로 관리되는 애플리케이션에 이러한 업데이트를 손쉽게 적용할 수 있습니다.

AWS Fargate

AWS Fargate는 컨테이너용 서버리스 컴퓨팅 엔진으로, Amazon ECS와 Amazon EKS에서 작동합니다.

AWS Fargate를 사용하는 경우 서버를 프로비저닝하거나 관리할 필요가 없습니다. AWS Fargate는 자동으로 서버 인프라를 관리합니다. 애플리케이션 혁신과 개발에 더 집중할 수 있으며, 컨테이너를 실행하는 데 필요한 리소스에 대해서만 비용을 지불하면 됩니다.

=> 자동으로 서버 인프라 관리

모듈 2 퀴즈

배치 처리 워크로드에 Amazon EC2 인스턴스를 사용하려고 합니다. 가장 적합한 Amazon EC2 인스턴스 유형은 무엇입니까?

Amazon EC2 예약 인스턴스의 약정 기간 옵션은 무엇입니까? (2개 선택)

총 6개월 동안 실행되며 중단을 견딜 수 있는 워크로드가 있습니다. 가장 비용 효율적인 Amazon EC2 구매 옵션은 무엇입니까?

다음 프로세스 중 Elastic Load Balancing의 예는 무엇입니까?

컨테이너식 애플리케이션을 배포하고 관리하려고 합니다. 어떤 서비스를 사용해야 합니까?

aws cloud practitioner 자격증을 2주 안에 취득할 것이다.

빠르게 공부를 시작한다. 

AWS Cloud Practitioner Essentials (amazon.com)

모듈1 소개

먼저 기본 클라우드 컴퓨팅 모델을 배워볼 것이다. 

거의 모든 현대적 컴퓨팅은 기본적으로 클라이언트-서버 모델을 중심으로 한다. 

커피숍을 예로 들어보자면...

클라이언트가 바리스타에게 커피를 주문한다.

현실에서는 고객이 정보를 요청하면 권한을 가진 서버가 요청에 응답한다.

실제로 클라이언트와 서버는 더 복잡하다.(서버 하나만 쓰지 않는다.)

on-demand 

aws 핵심 개념 중 하나

사용한 만큼만 지불

자원이 필요할 때 추가하고 필요한 만큼만 지불한다.

클라우드 컴퓨팅

클라우드 컴퓨팅 배포 모델

클라우드의 정의

클라우드 컴퓨팅은 IT 리소스를 인터넷을 통해 온디맨드로 제공하며 사용한 만큼만 비용을 지불합니다. 

온디맨드 제공

온디맨드 제공이란 AWS가 사용자에게 필요한 리소스를 필요한 순간에 전달할 수 있다.

가상 서버 300개가 갑자기 필요하다면 클릭 한번으로 추가 가능하다. 

스토리지를 추가하거나  등등.

클라우드 기반 배포

• 애플리케이션의 모든 부분을 클라우드에서 실행합니다.
• 기존 애플리케이션을 클라우드로 마이그레이션합니다.
• 클라우드에서 새 애플리케이션을 설계 및 빌드합니다.

클라우드 기반 배포 모델에서는 기존 애플리케이션을 클라우드로 마이그레이션하거나 클라우드에서 새 애플리케이션을 설계 및 빌드할 수 있습니다. 이러한 애플리케이션은 IT 팀의 관리가 필요한 하위 수준 인프라에 빌드할 수도 있고 핵심 인프라의 관리, 아키텍처 설계, 확장 필요를 줄여주는 상위 수준 서비스를 사용하여 빌드할 수도 있습니다.

예를 들어 기업은 완전히 클라우드에 기반한 가상 서버, 데이터베이스, 네트워킹 구성 요소로 구성된 애플리케이션을 만들 수 있습니다.

온프레미스 배포

• 가상화 및 리소스 관리 도구를 사용하여 리소스를 배포합니다.
• 애플리케이션 관리 및 가상화 기술을 사용하여 리소스 활용도를 높입니다.

클라우드 컴퓨팅의 이점

1. 선행 비용을 가변 비용으로 대체

미리 투자를 해야 사용할 수 있는 리소스를 가변 비용으로 바꿔 사용하는 컴퓨팅 리소스에 대해서만 비용을 지불한다. 

2. 데이터 센터 운영 및 유지 관리에 비용 투자 불필요

마찬가지로 데이터 세터 운영 및 관리 비용도 절약할 수 있다. 

3. 용량 추정 불필요

수요에 따라 확장 , 축소할 수 있기 때문에 인프라 용량을 예측할 필요가 없다. 

4. 규모의 경제로 얻게 되는 이점

aws가 규모의 경제를 하니 싸게 이용할 수 있다.

5. 속도 및 민첩성 향상

클라우드 컴퓨팅의 유연성 덕분에 애플리케이션을 더욱 쉽게 개발하고 배포할 수 있다. 

6. 몇 분 만에 전 세계에 배포

전 세계 고객에게 신속하게 애플리케이션을 배포 가능

모듈 1 퀴즈

1. 클라우드 컴퓨팅이란 무엇입니까?

2. 온프레미스 배포의 또 다른 이름은 무엇입니까?

 

3. 클라우드 컴퓨팅의 규모는 어떻게 비용 절감에 도움이 됩니까?

118. Cluster Maintenance - Section Introduction

클러스터 유지 관리와 관련된 주제를 다룰 것이다. 

운영 체제 업그레이드 

백업과 복원 방법론을 배울 것이다. 

120. Operation System Upgrade

노드를 제거해야하는 상황에 대해 알아보자 (업그레이드할 때 등등)

2번 노드에 파랑, 초록 포드가 있었는데 꺼졌다. 

그럴땐 어떻게 해야할까? 

보통은 노드를 다시 복구시킨다. 하지만 5분 넘게 노드가 다운되면 노드에 있던 포드는 삭제된다. 

pod-eviction-timeout

node가 다시 복구할때까지 3,4번 노드가 대신 포드를 작동 시켜준다. 

kube-controller-manager --pod-eviction-timeout=5m0s

만약 노드가 계속 복구 안될 것 같은 경우에는 포드를 다른 노드로 옮기는 것이 안전하다.

drain 을 통해서 워크로드를 노드로 옮길 수 있다.

실제로 옮겨지는게 아니다. 파드가 삭제되고 새로이 생성되는 것이다. 

cordon을 통해서 해당 노드에 새 파드 배치를 막을 수 있다. 

uncordon을 통해서 금지를 풀 수 있다.

121. Practice Test - OS Upgrades

1.

Let us explore the environment first. How many nodes do you see in the cluster?

Including the controlplane and worker nodes.

2개 

2.

How many applications do you see hosted on the cluster?

Check the number of deployments in the default namespace.

1개

3.

Which nodes are the applications hosted on?

4.

We need to take node01 out for maintenance. Empty the node of all applications and mark it unschedulable.

cannot delete DaemonSet-managed Pods (use --ignore-daemonsets to ignore)

daemonset 옵션을 꺼야한다. 

5.

What nodes are the apps on now?

controlplane

6.

The maintenance tasks have been completed. Configure the node node01 to be schedulable again.

7.

How many pods are scheduled on node01 now?

0개

8.

Why are there no pods on node01?

9.

Why are the pods placed on the controlplane node?

Check the controlplane node details.

10.

Time travelling to the next maintenance window…

11.

We need to carry out a maintenance activity on node01 again. Try draining the node again using the same command as before:

kubectl drain node01 --ignore-daemonsets

Did that work?

12.

Why did the drain command fail on node01? It worked the first time!

node01 에 pod  hr-app 이 돌아가고 있기 때문

13.

What is the name of the POD hosted on node01 that is not part of a replicaset?

14.

What would happen to hr-app if node01 is drained forcefully?

Try it and see for yourself.

사라진다 .

15.

Oops! We did not want to do that! hr-app is a critical application that should not be destroyed. We have now reverted back to the previous state and re-deployed hr-app as a deployment.

16.

node01 에 다른 포드가 돌아가고 있다. 포드를 계속 운영하고 다른 포드가 node01 에 올라오지 않게 설정한다

cordon 

123. Kubernetes Software Vesrions

쿠버네티스 클러스터를 설치하면 특정 버전의 쿠버네티스를 설치하게 된다. 

major, minor, patch 로 바뀐다. 

124. References

https://kubernetes.io/docs/concepts/overview/kubernetes-api/

Here is a link to kubernetes documentation if you want to learn more about this topic (You don't need it for the exam though):

https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md

https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md

125. Cluster Upgrade Process

쿠버네티스 클러스터 업그레이드 프로세스에 대해 배워보자

쿠버네티스는 버전마다 다른 기능을 제공한다.

가장 기본이 되는 버전을 확인해보자 

kube-api server 모든 컴포넌트랑 통신하기 때문에 kube-api server 보다 버전이 같거나 낮아야한다. 

컨트롤 매니저, 스케쥴러는 kube api 보다 한단계 낮음 ok

kubelet, kube-proxy는 kube api 보다 두단계 까지 낮음 ok 

kubectl 도구는 kube api 보다 한 단계 높거나 낮아도 된다.  + - 1

Kubernetes supports only up to the recent three minor versions.

쿠버네티스는 최근 마이너 세개까지 버전을 지원한다.

업데이트할때 다이렉트로 업데이트 1.10 -> 1.13 업데이트 하는 것이 아니라 1.10 -> 1.11 -> 1.12 -> 1.13 이렇게 이동한다 

업그레이드 방법은 셋업에 따라 다르다. 

클라우드 서비스 (아마존, gcp) 같은 경우 손쉽게 업그레이드 할 수 있다. 

kubeadm 을 사용하면 위의 명령어로 업그레이드 할 수 있다. 

직접 쿠버네티스를 구현했으면 하드 코딩으로 업그레이드 해야한다.

당연히 kubeadm 을 사용한 업그레이드 방법을 배워볼 것이다.

( 마스터노드도 v1.10 이었다.)

마스터 노드를 먼저 업그레이드 시키고 워커 노드를 업그레이드 한다. 

마스터노드를 중지시키고 업데이트 시킨다. 이때 마스터 노드의 kube api, 스케줄러, 컨틀롤러등 다운된다.

워커 노드는 계속 작동 중 

워커 노드에 문제가 생겨도 컨트롤 매니저가 꺼져있기 때문에 그냥 나둬야함. 

워커노드를 업데이트 하는 첫번째 방법은 모두 한번에 변경하는 것이다.

대신 모든 서비스가 안되는 down time 을 갖게 된다 .

마스터 노드를 업그레이드 시킨 후 노드를 하나씩 업그레이드 한다 .

마지막에 업데이트 완료 

세번째 방법은 하나씩 새버전의 노드를 추가하는 방법이다 .

기존의 포드를 새로운 노드에 옮기고 삭제 -> 반복한다 

kubeadm upgrade plan 명령을 통해서 업그레이드 관련 정보를 확인할 수 있다. 

만약 업그레이드 하고 싶다면 kubeadm 도 마찬가지로 버전 업해야한다. 1.13.4

먼저 버전 1.12로 업그레이드

get 파드에서 1.11.3 버전이라고 뜬다? 

api 서버 자체의 버전이 아니라 api 서버로 등록된 각각의 노드에서 버전의 kublets 을 보여주고 있기 때문

다음 단계는 kublet을 업그레이드 하는 것이다. 

마스터 노드의 버전이 업데이트 되었다.

워커 노드는 drain 명령어로 포드를 이사보낸다. 

마지막엔 uncordon으로 노드를 푼다.

각 워커 노드를 drain 시키고 uncordon으로 푸는 중간에 

apt-get upgrade -y kubeadm=1.12.0-00

apt-get upgrade -y kubelet=1.12.0-00

kubeadm upgrade node config --kublet-version v1.12.0

systemctl restart kubelet

명령어들을 통해 워커 노드를 업데이트 시킨다.

126. Demo- Cluster upgrade 

https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/

클러스터 업데이트 시키는 방법 실습 내용이다

katakoda 에서 playground를 제공했으나 서비스가 중지되었다. 

cat /etc/#release* 명령어로 운영 체제 버전을 확인한다. 

Upgrade kubelet and kubectl 

# replace x in 1.25.x-00 with the latest patch version
apt-mark unhold kubelet kubectl && \
apt-get update && apt-get install -y kubelet=1.25.x-00 kubectl=1.25.x-00 && \
apt-mark hold kubelet kubectl

Upgrading control plane nodes

upgrade kubeadm:

 # replace x in 1.25.x-00 with the latest patch version
 apt-mark unhold kubeadm && \
 apt-get update && apt-get install -y kubeadm=1.25.x-00 && \
 apt-mark hold kubeadm

verify that the download works and has the expected version

kubeadm version

kubeadm 버전을 확인하고 

Verify the upgrade plan 

kubeadm upgrade plan

해당 버전에서 업그레이드 할 수 있는 요소들이 뜬다 .

+-1 버전들

Choose a version to upgrade to , and run the appropriate command. For example: 

sudo kubeadm upgrade apply v1.25.x

업그레이드가 진행된다. 

your cluster was upgraded to "xxx" 가 뜬다.

버전을 확인하면 여전히 전 버전으로 뜬다.

kubeadm은 업데이트 했지만 kubelet 이 업데이트 안되었음. 

Drain the node

kubelet 노드를 업그레이드 하기 전에 비운다. 

# replace <node-to-drain> with the name of your node you are draining
kubectl drain <node-to-drain> --ignore-daemonsets

Upgrade kubelet and kubectl

upgrade the kubelet and kubectl

# replace x in 1.25.x-00 with the latest patch version
apt-mark unhold kubelet kubectl && \
apt-get update && apt-get install -y kubelet=1.25.x-00 kubectl=1.25.x-00 && \
apt-mark hold kubelet kubectl

다시 업데이트 

Restart the kubelet

sudo systemctl daemon-reload
sudo systemctl restart kubelet

노드의 버전을 확인하면 이제 변경되었을 것 이다. 

Uncordon the node

# replace <node-to-uncordon> with the name of your node
kubectl uncordon <node-to-uncordon>

해당 노드를 다시 연다 .

Upgrade worker nodes 작업자 노드 업데이트 하기 

Upgrade kubeadm

upgrade kubeadm:

# replace x in 1.25.x-00 with the latest patch version
apt-mark unhold kubeadm && \
apt-get update && apt-get install -y kubeadm=1.25.x-00 && \
apt-mark hold kubeadm

작업자 노드로 접속한 후 업데이트 한다. 

Call "kubeadm upgrade"

sudo kubeadm upgrade node

kubeadm 을 업그레이드 한 후

Drain the node

# replace <node-to-drain> with the name of your node you are draining
kubectl drain <node-to-drain> --ignore-daemonsets

노드 비우기 

노드 비울때 controlplane 에서 실행해야한다. 

Upgrade kubelet and kubectl

# replace x in 1.25.x-00 with the latest patch version
apt-mark unhold kubelet kubectl && \
apt-get update && apt-get install -y kubelet=1.25.x-00 kubectl=1.25.x-00 && \
apt-mark hold kubelet kubectl

Restart the kubelet:

sudo systemctl daemon-reload
sudo systemctl restart kubelet

데몬과 kubelet을 재시작한다. 

Uncordon the node

# replace <node-to-uncordon> with the name of your node
kubectl uncordon <node-to-uncordon>

노드 풀기 

이것도 controlplane 에서 실행해야한다. 

127. Practice Test - Cluster Upgrade 

1.This lab tests your skills on upgrading a kubernetes cluster. We have a production cluster with applications running on it. Let us explore the setup first.

What is the current version of the cluster?

v1.25.0 

2. How many nodes are part of this cluster?

Including controlplane and worker nodes

2개

3. How many nodes can host workloads in this cluster?Inspect the applications and taints set on the nodes.

2개

4. How many applications are hosted on the cluster? Count the number of deployments in the default namespace.

1개

5. What nodes are the pods hosted on?

6. You are tasked to upgrade the cluster. Users accessing the applications must not be impacted, and you cannot provision new VMs. What strategy would you use to upgrade the cluster?

1번

7. What is the latest stable version of Kubernetes as of today? Look at the remote version in the output of the kubeadm upgrade plan command.

1.26.1 이 최신 버전이다. 

8. What is the latest version available for an upgrade with the current version of the kubeadm tool installed? Use the kubeadm tool

1.25.6 

9. We will be upgrading the controlplane node first. Drain the controlplane node of workloads and mark it UnSchedulable

10. Upgrade the controlplane components to exact version v1.26.0 Upgrade the kubeadm tool (if not already), then the controlplane components, and finally the kubelet. Practice referring to the Kubernetes documentation page.

apt update

apt-cache madison kubeadm

 apt-mark unhold kubeadm && \
 apt-get update && apt-get install -y kubeadm=1.26.0-00 && \
 apt-mark hold kubeadm

• kubeadm version
  

kubeadm upgrade plan

# replace x with the patch version you picked for this upgrade
sudo kubeadm upgrade apply v1.26.0

apt-mark unhold kubelet kubectl && \
apt-get update && apt-get install -y kubelet=1.26.0-00 kubectl=1.26.0-00 && \
apt-mark hold kubelet kubectl

sudo systemctl daemon-reload
sudo systemctl restart kubelet

11. Mark the controlplane node as "Schedulable" again

노드를 푼다 .

12. Next is the worker node. Drain the worker node of the workloads and mark it UnSchedulable

13. Upgrade the worker node to the exact version v1.26.0

ssh 로 노드에접속 

apt-mark unhold kubeadm && \
apt-get update && apt-get install -y kubeadm=1.26.0-00 && \
apt-mark hold kubeadm

sudo kubeadm upgrade node

# replace x in 1.25.x-00 with the latest patch version
apt-mark unhold kubelet kubectl && \
apt-get update && apt-get install -y kubelet=1.26.0-00 kubectl=1.26.0-00 && \
apt-mark hold kubelet kubectl

• sudo systemctl daemon-reload
  sudo systemctl restart kubelet

kubectl uncordon <node-to-uncordon>

14. Remove the restriction and mark the worker node as schedulable again.

129. Backup and Restore Methods 

| Backup Candidates

구성파일, ETCD, 백업 장소 키워드를 생각하면서 해보자 

| Imperative

명령적인 방법으로 개체를 구성하기 

| Declarative

선언적 방법으로는 구성파일을 생성한 후 apply 명령어로 실행 

소스 코드를 리포지토리에 저장하는 것이 좋다. 

| Backup - Resource Configs 구성 파일을 백업하는 또 다른 방법

kubectl get all --all-namespaces -o yaml > all-deploy-services.yaml

모든 네임 스페이스에서 모든 객체를 가져와서 all-deploy-services.yaml 파일에 담는다. 

벨레로라 라는 도구를 이용해 쿠버네티스 API를 이용해 쿠버네티스 클러스터 백업을 가져오는 데 도움이 된다 .

| Backup - ETCD

ETCD 에 클러스터 자체에 관한 정보와 노드 및 클러스터 내부에서 생성된 모든 리소스가 여기 저장된다. 

리소스를 백업하는 대신 기타 서버 자체를 백업할 수 있다? 

모든 마스터노드에 ETCD 가 숨어있다. 

ETCD 가 보관된 디렉토리를 이용한다

또는 ETCD는 built in 스냅샷을 지원한다. 

스냅샷 기능을 이용해 데이터베이스 스냅샷을 찍을 수 있다. 

명령어를 통해서 백업의 상태를 볼 수 있다.

스냅샷을 복원하기에 앞서 kube-apiserver를 중지해야한다. 

snapshot restore snapshot.db  

 스냅샷 복원을 실시한다. 

복원을 실시하면 새로운 클러스터에 새로운 구성 맴버를 초기화시킨다. 

(기존 작동 중인 클러스터에 초기화 되면 안되므로)

/var/lib/etcd-from-backup 경로에 새 데이터 디렉터리가 생성된다.

daemon을 다시 실행 시킨다 .

서비스도 마찬가지 

kube-apiserver 도 실행

인증서 파일을 지정하는 걸 기억하자! 

130. Working with ETCDCTL 

etcdctl etcd에 대한 명령줄 클라이언트입니다.

모든 쿠버네티스 핸즈온 랩에서 ETCD 키-값 데이터베이스는 마스터의 정적 파드로 배포된다. 사용 된 버전은 v3입니다.

백업 및 복원과 같은 작업에 etcdctl을 사용하려면 ETCDCTL_API 3으로 설정해야 합니다.

etcdctl 클라이언트를 사용하기 전에 변수 ETCDCTL_API 내보내면 됩니다. 이 작업은 다음과 같이 수행 할 수 있습니다.

export ETCDCTL_API=3

마스터 노드에서:

특정 부속 명령에 대한 모든 옵션을 보려면 -h 또는 --help 플래그를 사용하십시오.

예를 들어, etcd의 스냅샷을 찍으려면 다음을 사용합니다.

etcdctl snapshot save -h 그리고 필수 전역 옵션을 기록해 두십시오.

당사의 ETCD 데이터베이스는 TLS를 지원하므로 다음 옵션이 필수입니다.

--cacert 이 CA 번들을 사용하여 TLS 사용 보안 서버의 인증서 확인

--cert 이 TLS 인증서 파일을 사용하여 보안 클라이언트 식별

--endpoints=[127.0.0.1:2379] 이는 ETCD가 마스터 노드에서 실행 중이고 로컬 호스트 2379에 노출되므로 기본값입니다.

--key 이 TLS 키 파일을 사용하여 보안 클라이언트 식별

마찬가지로 스냅샷 복원에 대한 도움말 옵션을 사용하여 백업 복원에 사용할 수 있는 모든 옵션을 확인합니다.

etcdctl snapshot restore -h

etcdctl 명령행 도구를 사용하고 -h 플래그로 작업하는 방법에 대한 자세한 설명은 백업 및 복원 랩의 솔루션 비디오를 확인하십시오.

=> etcdctl 참고하자! 

131. Practice Test - Backup and Restore Methods

1. We have a working kubernetes cluster with a set of applications running. Let us first explore the setup. How many deployments exist in the cluster?

2개 

2. What is the version of ETCD running on the cluster? Check the ETCD Pod or Process

etcd-controlplane을 확인하고

버전 3.5.6 쯤 된다. 

3. At what address can you reach the ETCD cluster from the controlplane node? Check the ETCD Service configuration in the ETCD POD

커맨드 부분을 확인하면 listen-client-urls 에 127.0.0.1:2379 로 통신 가능

4. Where is the ETCD server certificate file located? Note this path down as you will need to use it later

커맨드 위쪽에 확인 가능

/etc/kubernetes/pki/etcd/server.crt

5. Where is the ETCD CA Certificate file located? Note this path down as you will need to use it later.

6. The master node in our cluster is planned for a regular maintenance reboot tonight. While we do not anticipate anything to go wrong, we are required to take the necessary backups. Take a snapshot of the ETCD database using the built-in snapshot functionality.

yaml 파일 확인

etcd-data 디렉토리 확인

--data-dir=/var/lib/etcd

해당 디렉토리에는 맴버라고 뜬다.

etcdctl 을 그냥 쓰고 싶으면 export api 를 먼저 해준다. 

cacert, cert, key 파일 위치를 다 받고 저장할 디렉토리를 지정한다. 

엔드포인트는 etcd가 통신하는 엔드포인트 

7. Great! Let us now wait for the maintenance window to finish. Go get some sleep. (Don't go for real)

Click Ok to Continue

8. Wake up! We have a conference call! After the reboot the master nodes came back online, but none of our applications are accessible. Check the status of the applications on the cluster. What's wrong?

all of the above 

9. Luckily we took a backup. Restore the original state of the cluster using the backup file.

yaml 파일을 수정하면 적용된다. 

kubectl delete pod etcd-controlplane -n kube-system 

133. Practice Test Backup and Restore Methods 2

1. In this lab environment, you will get to work with multiple kubernetes clusters where we will practice backing up and restoring the ETCD database.

2. You will notice that, you are logged in to the student-node (instead of the controlplane).

student-node 로 로그인 되어있음. 

3. How many clusters are defined in the kubeconfig on the student-node?

You can make use of the kubectl config command.

kubectl config get-clusters

또는 

kubectl config view 로 확인가능

2개 

4. How many nodes (both controlplane and worker) are part of cluster1?

kubectl config use-context cluster1

2개 

5. What is the name of the controlplane node in cluster2? Make sure to switch the context to cluster2:

kubectl config use-context cluster2

cluster2-controlplane 

6. You can SSH to all the nodes (of both clusters) from the student-node.

노드로 접속할 수 있다. 

ctrl + D 로 나가기 가능 

7. How is ETCD configured for cluster1? Remember, you can access the clusters from student-node using the kubectl tool. You can also ssh to the cluster nodes from the student-node.

stacked ETCD 로 구성된다. 

8.  How is ETCD configured for cluster2? Remember, you can access the clusters from student-node using the kubectl tool. You can also ssh to the cluster nodes from the student-node.

kubectl config use-context cluster2

여기에는 없다. 

cluster2-controlplane 로 접속

external etcd 존재

9. What is the IP address of the External ETCD datastore used in cluster2?

10.13.144.19

10.What is the default data directory used the for ETCD datastore used in cluster1?

kubectl config use-context cluster1