반응형

Tasks

Check that there is a tagged image in gcr.io for echo-app:v2
Echo-app:v2 is running on the Kubernetes cluster
The Kubernetes cluster deployment reports 2 replicas.
The application must respond to web requests with V2.0.0

 

1. 파일 압축 풀기 및 Docker Build

 

- 압축 풀기

tar -xvzf resources-ehco-web-v2.tar.gz

- PROJECT_ID 환경변수 등록

export PROJECT_ID=$(gcloud info --format='value(config.project)')

- Image 를 Google Container Registry 에 push

 

2. Version 수정

- echo-web-deployment.yml 파일 수정

아래에 있는 1.0 을  v2 로 변경한다.

- Image push

docker push gcr.io/${PROJECT_ID}/echo-web:v2

그리고 나서 화면에서 Action 에 있는 Rolling update 를 클릭한다.

Rolling Update 에서 image 는 조금전에 push 한 v2 이미지를 사용한다. 그리고 Update 클릭

 

- Scale 변경

Action  메뉴에서 Scale 을 클릭한후 Replicas 값을 2 로 입력한다.

완료가 되면 위에 보이는 Replicas 정보가 아래와 같이 변경된다.

 

Deployment Details 화면에 있는 yaml 탭에 가서 파일 내용을 살펴보면 spec.replicas 가 2 로 변경 되어 있는것을 볼 수 있다.

 

728x90
반응형
반응형

Tasks

An application image with a v1 tag has been pushed to the gcr.io repository
A new Kubernetes cluster exists (zone: us-central1-a)
Check that an application has been deployed to the cluster
Test that a service exists that responds to requests like Echo-app

 

1. 클러스터 생성


gcloud beta container --project "qwiklabs-gcp-00-337f72711928" clusters create "echo-cluster" --zone "us-central1-a" --no-enable-basic-auth --cluster-version "1.14.10-gke.17" --machine-type "n1-standard-2" --image-type "COS" --disk-type "pd-standard" --disk-size "100" --metadata disable-legacy-endpoints=true --scopes "
https://www.googleapis.com/auth/devstorage.read_only","https://www.googleapis.com/auth/logging.write","https://www.googleapis.com/auth/monitoring","https://www.googleapis.com/auth/servicecontrol","https://www.googleapis.com/auth/service.management.readonly","https://www.googleapis.com/auth/trace.append" --num-nodes "3" --enable-stackdriver-kubernetes --enable-ip-alias --network "projects/qwiklabs-gcp-00-337f72711928/global/networks/default" --subnetwork "projects/qwiklabs-gcp-00-337f72711928/regions/us-central1/subnetworks/default" --default-max-pods-per-node "110" --addons HorizontalPodAutoscaling,HttpLoadBalancing --enable-autoupgrade --enable-autorepair

 

클러스터 생성은 Cloud Console 에서 직접 하면 된다.

name 은 "echo-cluster" , machine-type 은 "n1-standard-2" 로 만들어 준다.

 

2. tar file 을 Google Cloud Storage 에서 복사한 후 압축을 푼다.

 

- Google Cloud Strage 에서 복사

gsutil cp gs://qwiklabs-gcp-00-337f72711928/echo-web.tar.gz .

- 압축 풀기
tar -xvfz echo-web.tar

 

 

3. Docker Build 및 Image Push

- Docker Build

- Image 확인

echo-app 이 생성된 것을 확인할 수 있다.

 

- GCR(Google Cloud Registry) 에 push 하기 위해서 Tag 를 변경해준다. 

export PROJECT_ID=$(gcloud info --format='value(config.project)')

docker tag echo-app:v1 gcr.io/${PROJECT_ID}/echo-app:v1

- Image 를 Cloud Registry 에 push

중간에 나는 project id 를 그대로 써줬는데 위에서 export 를 했기 때문에 ${PROEJCT_ID} 로 써줘도 된다.

 

4. GKE 에 Deploy 하기

Cloud Console  의 Container Registry 를 확인해 보면 위와 같이 push한 이미지를 확인 할 수 있다.

오른쪽에 ... 메뉴를 눌러보면 Deploy to GKE 버튼을 볼수 있다. 그걸 클릭한다. 

 

Image 는 "Exsiting conatiner images" 를 선택하고 좀전에 생성한 이미지를 선택해준다.

 

Application name 은 "echo-web" 이라고 해준다.

라벨에도 key에 app, value 에 echo-web 이라고 넣어준다.

Cluster 는 위에서 생성한 "echo-cluster" 를 선택한다.

그리고 "Deploy" 클릭.

 

5. 외부에서 접속 할수 있도록 expose 하기

 

Cloud Console 에서 Kubernetes Engine > Workloads 메뉴로 가면 echo-web 의 detail 정보로 들어가면 위와 같이 화면이 나온다.

화면 상단에 있는 Expose 버튼을 누른다.

 

port 를 80 으로 넣어주고 Target port 를 8080 으로 넣고 Expose 버튼을 누른다.

 

Expose 가 완료되면 위와같이 External endpoint 가 나타난다.

 

주소로 접속을 하게 되면 위와 같이 결과를 볼 수 잇다.

Cloud console 메뉴를 이용해서 만들었는데 직접 kubectl 명령어를 활용해서 만들어 보는것도 좋은 공부가 될것 같다.

 

 

 

 

728x90
반응형
반응형

 

이 책이 최근에 나온 것을 알고 읽어봐야겠다라는 생각을 하고 있었는데 이렇게 리뷰어로 선정되어 읽게 되었다. 

 

우선 이 책의 목차를 보면 총 13개의 Chapter 로 구성되어있다.

 

1. 쿠버네티스란

2. 쿠버네티스 살펴보기

3. 아키텍처

4. 쿠버네티스 API 서버

5. 스케줄러

6. 쿠버네티스 설치

7. 인증과 사용자 관리

8. 인가

9. 승인제어

10. 네트워킹

11. 모니터링

12. 재해복구

13. 쿠버네티스 확장하기

 

Chapter 1 에서부터 6 까지는 쿠버네티스의 이론 적인 내용이 주로 설명되어있다. 단, 이 책은 운영에 대해서 초점을 맞춘 책이기 때문에 오브젝트 단위까지의 자세한 설명은 언급하지 않았다. 그리고 그 이후 Chapter 에서는 운영 환경에서 설정을 해줄수 있는 또는 해줘야 하는 인증, 승인에 대해서 알려주고 있다. 

 

이 책의 장점은 쿠버네티스 API 서버와 연관해서 인증, 인가, 승인제어 부분을 자세히 다뤄주고 있다. 쿠버네티스에가 가장 중요하다고 할 수 있는 API 에 대해서 어떻게 호출하는지, 또는 누가 어떤 API 를 호출 할수 있고 또는 없는지, 그런 설정들은 어떻게 해나갈수 있는지 차례대로 설명을 해준다. 

 

그런데 단점 부분이 좀 아쉽다. 읽다가 문뜩 드는 생각은 과연 이렇게 하면 잘 운영할 수 있는건가 라는 의문이 들게 된다. 생각보다 내용이 많지 않다는 것을 느꼈다. 내가 일부분 잘 이해를 못해서 그럴수는 있지만 사례에 대한 설명이나 예제가 좀 부족하지 않나라는 생각이 계속 들었다. 

 

 

728x90
반응형
반응형

최근에 Kubernetes에 어플리케이션을 올리다가 몇일간 맨붕 상태가 온 내용을 남겨두고자 한다. 

 

Kubernetes 클러스터에 my-test1 이라는 네임스페이스로 ingress, servcie, deployment 를 생성하였다. 

 

여기 까지는 문제가 없었는데 도메인을 설정하고 tls 를 설정하면서 문제가 발생했다.

 

1. test.com 이라는 도메인으로 사설 인증서 생성.

2. crt 파일과 key 파일을 이용해서 secret 생성

3. ingress 에 tls 설정에 host와 tls 를 설정.

 

위와같이 진행을 하고 접속을 해봤다. 

그런데 이상하게 브라우저에서 "주의요함" 부분을 클릭해보면 내가 만든 사설인증서의 도메인이 나오는게 아니라 Kubernetes의 Fake 인증서가 나왔다. 분명히 나는 인증서를 설정했는데..

 

이것때문에 원인을 찾느라 한참 고생했다.

 

결국 원인을 찾았는데 문제는 동일한 도메인을 사용하는 다른 ingress 들 때문이었다. 

 

내가 사용중인 네임스페이스의 ingress 를 생성하면 kube-system 에 있는 ingress-constroller 에 등록이 된다. 이때에 내가 설정한 어플리케이션 뿐만 아니라 다른 네임스페이스의 어플리케이션의 ingress 도 생성하면 동일하게 등록이 된다. 

 

이때에 중요한 점은 같은 도메인일 경우이다.

 

만약 내가 ingress 의 tls 설정을 아래와 같이 했다고 가정해보자

 

tls:
- hosts:
- test.com
secretName: my-test-secret

 

그런데 다른 어플리케이션에서 ingress 를 아래와 같이 설정을 했다.

 

tls:
- hosts:
- test.com

 

이럴 경우 아래쪽에 ingress 의 설정에 secret 이 없기때문에 Fake 인증서를 사용하게 된다. 아마도 순서에 영향을 받지 않나 싶다. 결과적으로 ingress 를 반영을 하게되면 kube-system의 ingress-controller 에 반영이 되고 결국 내부의 nginx.conf 파일에 반영이 되기 때문에 아마도 순서에 영향을 받을 것 같긴 하다. 

 

따라서 같은 도메인일 경우에는 namespace 별로 secret을 다 만들어서 같이 설정을 해두던지 아니면 하나의 ingress 에서만 secret 설정을 하고 나머지는 tls 설정을 삭제 해줘야 한다.

 

이것때문에 너무 시간도 많이 낭비했는데.. 역시 모르면 몸이 고생이다. ㅠㅠ

 

728x90
반응형
반응형

이제 곧 2018년이 저물고 2019년이 시작된다.

올 한해동안 내가 무엇을 했는지 한번 돌이켜 보고 정리를 하려고 한다. 막연하게 정리하기는 힘드니 생각나는 키워드대로 한번 적어본다.


1. Google Cloud Study Jam


2018/05/15 - [Development/Tech&Seminar] - Google Cloud Study Jams 후기

2018/10/08 - [Development/Tech&Seminar] - Google Cloud Hackathon 간단한 후기

2018/10/26 - [Development/Tech&Seminar] - Google Cloud Summit 2018 후기


나름 새롭게 뭔가를 해보기 위해 다짐하면서 시작했던 Google Study Jam. 막연하게 AWS 도 써봤으니 GCP 도 써봐야겠다는 생각을 실천으로 옮겨준 계기가 되었다. 지금도 공부를 하고 있고 많은 기능들을 사용해보지는 못했지만 조금씩 활용 범위를 넓혀 가보려고 한다. 이제 겨우 GKE 만 조금 사용해본 상태여서 갈길이 멀다. 


2. Kubernetes


Container 에 대한 관심도 있었고 회사에서 하는 업무와도 조금 연관성이 있어서 관심있게 봤다. 실제 어플리케이션을 이미지화 해서 돌려보기도 했다. 아쉽게도 내가 계획했었던 배포 관련 테스트는 해보지 못했다. 카나리나, 블루그린 배포 를 직접 해보려고 했었는데 게으른 탓에 해보지는 못했다. 아직 내가 메모해놓은 액션아이템에는 남아있으니 꼭 빠른 시간내에 해봐야겠다. 내가 사용해본 Kubernetes 의 기능들은 극히 일부에 불과 하니 앞으로도 계속해서 공부해야겠다.


3. React


이건 좀 아쉬움이 남는 부분이다. 올 초에 공부를 하려고 동기들하고 시작을 했는데 처음에는 제법 잘 해나가다가 중간에 바쁜 일정과 이런 저런 일들이 겹쳐서 좀 흐지부지 됐다. 그리고 하면서 느꼈는데 내가 프론트엔드 쪽에는 좀처럼 흥미를 못붙이는것 같다. 그러다 보니 더 어렵게 느껴지고 쉽게 지친다. 그래서 이런 점은 좀 심각하게 고민을 해봐야겠다. 아예 좀 포기 할것인지..-_-;;;


4. 도서 리뷰 & 베타리딩


2018/02/05 - [Enjoy Life/책을 읽자!!] - [나는 리뷰어다]Hello Coding 파이썬

2018/04/07 - [Enjoy Life/책을 읽자!!] - [나는 리뷰어다] 아주 큰 스케치북 그림그리기 & 색칠하기!!

2018/04/19 - [Enjoy Life/책을 읽자!!] - [길벗 개발자 리뷰어] Node.js 마이크로 서비스 코딩 공작소

2018/05/24 - [Enjoy Life/책을 읽자!!] - [나는 리뷰어다] 으로 Vue.js 의 첫걸음을 시작하자.

2018/07/15 - [Enjoy Life/책을 읽자!!] - [나는 리뷰어다] 자바 개발자라면 한번 쯤 읽어보자.!Think Data Structures (자바로 배우는 핵심 자료구조와 알고리즘)

2018/08/29 - [Enjoy Life/책을 읽자!!] - [길벗 개발자 리뷰어] 수학과 알고리즘의 조화!!! 알고리즘산책: 수학에서 제네릭 프로그래밍까지

2018/08/29 - [Enjoy Life/책을 읽자!!] - [나는 리뷰어다] <처음 배우는 암호화> 로 암호화 이론을 공부해보자~

2018/10/14 - [Enjoy Life/책을 읽자!!] - [나는 리뷰어다] 스프링 5 레시피를 살펴보자!



올 한해 출판사에서 진행하는 리뷰어에 선정되어 8권의 책에 대해서 리뷰를 썼다. 


상세보기


상세보기


그리고 블로그에는 남기지 않았지만 2권에 책의 베타리딩에 참여했다. 책들을 보면 기술서적, 알고리즘 또는 수학 관련 서적, 아이들 서적으로 나눠진다. 아무래도 리뷰어 신청할때 책 선택의 비중은 기술서적이 많다. 하지만 가끔은 지후와 함께 볼수 있는 책을 선택하거나 컴퓨터와 관련이 없는 책들도 선택을 하기도 했다. (물론 책은 랜덤으로 오지만..) 저 책들에 대해서 모든 내용을 다 소화하지는 못했다. 책 한권에 대해서 보통 2주정도 시간이 주어지는데 일반 소설과는 달리 기술서적은 직접 해보면서 읽어봐야 이해가 되기 때문에 시간이 좀 부족했다. 그런 점들이 좀 아쉬움으로 남는다. 


5. 세미나 참석

2018/10/26 - [Development/Tech&Seminar] - Google Cloud Summit 2018 후기

2018/11/08 - [Development/Tech&Seminar] - SpringOne Tour 참석 후기

2018/11/25 - [Development/Tech&Seminar] - Agile Korea Conference 2018 참석 후기


전에는 세미나를 참석하고 나서 뭔가 기록으로 남기질 않았다. 그렇게 하다보니 세미나를 참석하긴 했는데 뭘 보고 왔는지 기억이 나질 않았다. 이러면 안되겠다 싶어서 올해에는 참석한 세미나에서 세션을 들으면서 중간중간 메모를 하고 돌아와서는 글로 남겼다. 이렇게 하니 세미나에 대한 내용들도 다시 기억이 나고 뭘 해봐야 하는지 구체적으로 계획을 세울수 있었다. 그리고 내가 보고 듣고 한 내용들을 회사에서 같은 유닛원들에게 짧게 나마 공유를 했다. 공유를 해서 좋았던 점은 내가 보고 들은 내용을 다른 사람들에게 전달 하기 위해서 한번 더 찾아보고 정리를 할수 있었고 그래서 더 오랫동안 기억에남을 수 있었다. 


6. Authorization, Authentication, Oauth, OIDC, 그리고 오픈소스.


한해동안 회사 업무의 대부분을 차지한 키워드이다. 오픈소스는 정말 대단하지만 사용하기도 만만치 않다는 것을 깨달았다. 오픈소스를 컨설팅 하는 회사가 왜 생겨나는지 깨닫게 된 계기가 되었다. 빠른 버전업, 그리고 생각보다 부실한 메뉴얼, Usecase는 정말 한해동안 골치거리였다. 다 되어있을것 같이 말하지만 뜯어보면 버그와 난해한 코드들의 집합. 이게 내가 마주했던 오픈소스의 모습이었다. 내가 모르는 부분이 있고 잘 알지 못해서, 이해를 못해서 어렵게 느껴지는 부분들도 물론 있지만 그래도 이정도까지 어려울줄은 몰랐다. 내가 적용한 코드들이 과연 신뢰할수 있는지 끊임없이 의심을 하게 만들었던 오픈소스. 그런데 이게 내년에도 계속 될것 같아서 더 걱정된다. 

그리고 다양한 인증 방법들. Oauth를 기본으로 해서 OIDC까지. SAML 도 있긴 했지만 여의치 않아서 Oauth 와 OIDC를 주로 사용했다. 봐도봐도 헷갈렸던 Flow들. 알고 있다고 생각했는데 어??? 라는 의문을 던지게 했던 순간들. 이게 아니네?? 라는 허탈함을 느꼈던 순간들. 이런 순간들이 한해동안 되풀이 되었던것 같다.


7. 방화벽 지옥


이건 뭐...... 정말 할말을 잃게 만든다. 로컬 PC 와 VDI IP 에 대한 접근 방화벽을 대체 얼마나 뚫은건지 이제는 셀수도 없다. 생각하면 생각할수록 골치아프고 시간을 빼앗아가는 방화벽. 정말 싫다.


8. 건강


나이를 먹어서인지는 몰라도 이번에는 목때문에 꽤나 고생을 했다. 그리고 지금도 고생중이다. 자세가 안좋아서 목디스크 증상은 있었는데 이렇게 팔이 아팠던 적은 없었다. 꽤나 통증이 심해서 병원도 자주 가고 물리치료도 많이 받았다. 목부분에 따끔한 주사도 몇방 맞고. 어찌나 무섭던지. 그래도 이제는 좀 괜찮아져서 다행이다. 계속해서 오래 모니터를 보다보면 나도 모르게 자세가 개판이 된다. 그래서 요즘은 계속해서 자세를 바로 잡으려고 노력중이다. 건강을 잃으면 할수 있는게 없으니 좀더 신경쓰도록 해야겠다.


9. 고민, 그리고 또 고민


올 한해는 특히나 머리가 많이 복잡했다. 그중 가장 큰 고민거리는 "나는 과연 잘 하고 있는가? " 에 대한 의문이다. 항상 잘 하고 싶고 항상 발전하고 싶다. 어제보다는 좀더 나아진 내가 되고싶고 앞으로 더 많은 것을 알고 싶다. 그렇게 생각을 하다보니 나는 과연 좀더 발전하고 있는지 항상 물어보게 된다. 내가 하고 있는게 잘하고 있는건가? 맞게 진행을 하고 있는건가? 나는 정말로 발전을 했나? 회사 내에서 연차가 쌓이다 보니 이런 고민들을 정말 자주한다. 그리고 한없이 부족한 내 모습을 찾게 된다. 그리고 거기에서 오는 조급함이 나를 예민하게 만들고 여유가 없게 만들었던것 같다. 혼자 고민하지 말고 좀더 도움을 받자. 주변의 많은 선후배들이 있다. 혼자 끙끙거리면서 해결될 일도 아니고. 좀더 주위를 살펴보고 돌아보면서 내 위치를 바라볼수 있는 내가 되어야 겠다.



마무리 

순서도 없이 그냥 생각나는 키워드 대로 글을 적어봤다. 2019년을 마무리 할때 쯔음에 이 글을 다시 읽는 다면 어떤 생각을 하게 될까? 

다만 그때에는 후회하는 일보다는 잘 한일들이 더 많아서 내 스스로에게 칭찬의 박수를 해줄수 있었으면 좋겠다.


728x90
반응형
반응형

Kubernetes를 사용하면서 자주 사용하는게 kubectl 명령어 이다. 그리고 그중에서 컨테이너를 생성할때 항상 kubectl create 명령어를 사용했다. 그런데 사용하다보니 어떤 글에는 create 를 사용하고 어디에서는 apply 를 사용하는 것을 보게 되었다. 그래서 이 차이점이 궁금해서 이렇게 정리하게 되었다. 


아래 내용들은 kubernetes document 에서 요약한 내용들이다. 

https://kubernetes.io/docs/concepts/overview/object-management-kubectl/overview/



Kubernetes 에서 Object Management 에는 3가지가 있다. 


Management technique

Operates on

Recommended environment 

Supported writers 

 Imperative commands

 Live objects 

 Development 

 1+ 

 Imperative object configuration

 Individual files  

 Production 

 1 

 Declarative object configuration

 Directories of files 

 Production 

 1+ 



Imperative Commands


장점

- 클러스터에 특정 오브젝트를 한번에 실행하거나 시작할수 있는 가장 쉬운 방법이다. (실제 이미지 바로 실행 시킨다. )


단점

- 기존 설정에 대한 히스토리를 제공하지 않는다. (그래서 위에 권장 환경이 Development 인것 같다.)

- 변경사항이나 audit 내역, 템플릿등을 제공하지 않는다. 


ex)

kubectl run nginx --image nginx



Imperative object configuration


- 최소한 1개 이상의 YAML 이나 JSON 포맷의 파일을 이용해서 Object 를 생성한다. 


ex)

kubectl create -f nginx.yaml

Imperative object configuration vs Imperative Commands

장점

- 설정파일 내용을 Git 같은 곳에 저장이 가능하기 때문에 설정에 대한 변경 히스토리가 확인 가능하다. 

- 새로운 Object를 생성하기 위한 템플릿을 제공한다. 

단점

- YAML 파일 작성이 필요하며 템플릿 사용을 위해 Object schema 에 대해서 이해가 필요하다.


Imperative object configuration vs Declarative object configuration 

장점
- 더 간단하고 이해하기 쉽다.

단점

- 파일로 적용할때에만 동작한다. 디렉토리는 불가능.

- 실행중인 object 를 update 하기 위해서는 설정파일에 반영을 해야 한다. 



Declarative object configuration

- 모든 설정 파일들은 디렉토리 안에 들어있고 오브젝트를 생성하거나 패치 한다.


ex)

kubectl apply -f configs/


Declarative object configuration vs Imperative object configuration

장점

- 실행중인 오브젝트 직접 적용한 변경사항을 설정파일에 merge 하지 않더라도 유지된다.(???)


단점

- 디버깅 하기 어렵고 예상한 결과가 아닐 경우 이해하기 어렵다.

- diffs 를 사용한 부분 업데이트는 복잡한 병합과 패치를 만들게 된다.


Imperative commands 나  Imperative object configuration 는 이해가 되는데  Declarative object configuration 은 약간 이해가 안된다. 


https://kubernetes.io/docs/concepts/overview/object-management-kubectl/declarative-config/


여기 있는 샘플을 가지고 확인해보자.


sample_deployment.yaml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  minReadySeconds: 5
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80
cs



Create : kubectl apply -f sample_deployment.yaml 

Live configuration : kubectl get -f sample_deployment.yaml -o yaml


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
kind: Deployment
metadata:
  annotations:
    # ...
    # This is the json representation of simple_deployment.yaml
    # It was written by kubectl apply when the object was created
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"apps/v1","kind":"Deployment",
      "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
      "spec":{"minReadySeconds":5,"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
      "spec":{"containers":[{"image":"nginx:1.7.9","name":"nginx",
      "ports":[{"containerPort":80}]}]}}}}
  # ...
spec:
  # ...
  minReadySeconds: 5
cs


kubectl.kubernetes.io/last-applied-configuration 어노테이션에 보면 sample_deployment.yaml  에 적용한 내용들이 나와있다. 


다시 아래와 같이 명령어를 실행해보고 확인해보자.


kubectl scale deployment/nginx-deployment --replicas=2

Live configuration : kubectl get -f sample_deployment.yaml -o yaml


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    # ...
    # note that the annotation does not contain replicas
    # because it was not updated through apply
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"apps/v1","kind":"Deployment",
      "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
      "spec":{"minReadySeconds":5,"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
      "spec":{"containers":[{"image":"nginx:1.7.9","name":"nginx",
      "ports":[{"containerPort":80}]}]}}}}
  # ...
spec:
  replicas: 2 # written by scale
  # ...
  minReadySeconds: 5
cs


이 경우에는 apply를 하지 않았기 때문에 kubectl.kubernetes.io/last-applied-configuration 어노테이션에 포함되지 않았다.


sample_deployment.yaml 파일을 수정해보자. 


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.11.9 # update the image
        ports:
        - containerPort: 80
cs


nginx image 버전이 1.7.9 에서 1.11.9 로 변경 되었다.


Create : kubectl apply -f sample_deployment.yaml 

Live configuration : kubectl get -f sample_deployment.yaml -o yaml


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    # ...
    # The annotation contains the updated image to nginx 1.11.9,
    # but does not contain the updated replicas to 2
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"apps/v1","kind":"Deployment",
      "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
      "spec":{"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
      "spec":{"containers":[{"image":"nginx:1.11.9","name":"nginx",
      "ports":[{"containerPort":80}]}]}}}}
    # ...
spec:
  replicas: 2 # Set by `kubectl scale`.  Ignored by `kubectl apply`.
  # minReadySeconds cleared by `kubectl apply`
  # ...
  selector:
    matchLabels:
      # ...
      app: nginx
  template:
    metadata:
      # ...
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.11.9 # Set by `kubectl apply`
cs


확인을 해보면 apply 로 적용한 nginx 버전은 kubectl.kubernetes.io/last-applied-configuration 어노테이션에 포함 되어있다. 하지만 replicas 는 포함되지 않았다.


Warning: Mixing kubectl apply with the imperative object configuration commands create and replace is not supported. This is because create and replace do not retain the kubectl.kubernetes.io/last-applied-configuration that kubectl apply uses to compute updates


그리고 위와 같은 주의 사항도 있다. apply 는 create 나 replace 를 지원하지 않는다는 거다. 이유는 create 나 replace 는 kubectl.kubernetes.io/last-applied-configuration 어노테이션을 유지 하지 않기 때문이라고 한다. 



apply 와 create 의 차이점을 찾아보다가 여기까지 오게 되었다. 결과적으로 가장 큰 차이점은 apply 를 할 경우에는 기존 설정에 대한 정보를 가지고 있다는 점인것 같다. 


apply 이외에도 다른 명령어들이 있지만 우선은 이것만 이해하는걸로 하자.





728x90
반응형
반응형

Cluster

- Master, Node 2가지 타입의 리소스가 존재한다.

- Master : cluster를 관리한다. 

- Node : Worker Machine 으로 제공되는 VM 또는 물리적 컴퓨터이다. 

            각각의 Node 는 Node 를 관리하고 Kubernetes master와 커뮤니케이션을 할수 있는 Kubelet 이라는 agent 를 가지고 있다. 

            Node 는 master 가 노출시켜놓은 Kubernetes API 를 사용해서 통신을 한다. 





https://kubernetes.io/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro/

Pod

- Deployment 를 생성하게 되면 Deployment는 Pod 를 생성하고 그 안에 Container 를 넣는다. 

- Pod 는 1개 이상의 어플리케이션 컨테이너와 그 컨테이너들이 공유하는 리소스의 그룹이다. 

- 공유 리소스는 volume, clusterIP 가 있다. 

- Pod 안에 있는 Container 들은 IP 와 port 를 공유한다. 

- Pod 는 Unique IP address 를 가지고 있다.


https://kubernetes.io/docs/tutorials/kubernetes-basics/explore/explore-intro/



Service

- Pod 의 논리적 집합과  그것을 접근 할수 있는 정책을 정의 해준다. 

- Service 가 설정하는 Pod 의 논리적 집합은 LabelSelector 로 정의 한다. 

- 다음과 같은 type 이 존재한다. 


 type

 내용 

 ClusterIP 

 default 이다. cluster 의 internal IP 만 노출 시키기 때문에 cluster 내부에서만 접근 가능하다. 

 NodePort 

 각각의 NodeIP 에 서비스를 노출시킨다. NodePort 서비스가 라우팅 할 ClusterIP 서비스가 자동으로 생성된다. 클러스터 외부에서 <NodeIP>:<NodePort> 로 접근 가능하다. 

 LoadBalancer 

 external IP 를 생성하여 클러스터 외부에서 접근 가능하게 해준다. ClusterIP 와 NodePort는 자동으로 생성된다.




https://kubernetes.io/docs/tutorials/kubernetes-basics/expose/expose-intro/

728x90
반응형
반응형

현재 AWS  EC2 에 올라가 있는 ubuntu 에 kubernetes를 설치해 보았다. 

그런데 설치를 하다보니 프리티어로 받은 t2.micro 가지고는 너무 성능이 느렸다. 거의 접속도 못할 지경에 이르렀다. 그래서 어차피 설치하고 지울거니깐 t2.large로 올렸다.


설치 전에 Docker 가 먼저 설치 되어 있어야 한다.

(Docker 가 설치 안되어 있다면 https://docs.docker.com/install/linux/docker-ce/ubuntu/#set-up-the-repository 여기 참고하거나 아래 링크 에도 내용은 나와있다.)


https://kubernetes.io/docs/setup/independent/install-kubeadm/


여기에 들어가보면 친절하게 설치 하는 방법을 찾을 수 있다.

내용을 살펴보면 Docker 설치도 포함하고 있어서 Docker 가 설치되어 있지 않다면 그대로 따라 하면 된다.


그리고 나는 Ubuntu 에 설치를 하니 아래와 같이 명령어를 실행 했다. 혹시 명령어 실행중 permission 에러가 나면 sudo 붙이고 실행 하면 된다.

apt-get update && apt-get install -y apt-transport-https curl
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -
cat <<EOF >/etc/apt/sources.list.d/kubernetes.list
deb http://apt.kubernetes.io/ kubernetes-xenial main
EOF
apt-get update
apt-get install -y kubelet kubeadm kubectl
apt-mark hold kubelet kubeadm kubectl

이렇게 하면 kubelet, kubeadm, kubectl 이 설치가 된다.


https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/


그 다음 스텝으로 위 링크로 들어가서 클러스터를 생성 하면 된다.


여기 나와 있는 내용중에 보면 사양이 나와있다. 

  • One or more machines running a deb/rpm-compatible OS, for example Ubuntu or CentOS
  • 2 GB or more of RAM per machine. Any less leaves little room for your apps.
  • 2 CPUs or more on the master
  • Full network connectivity among all machines in the cluster. A public or private network is fine.

최소 사양이다. 이러니 t2.micro 로는 역부족이었다.

kubeadm init <args> 

이렇게 명령어를 날리면 뭔가 내용이 올라오면서 설치가 된다. args는 다양하게 있으나 나는 우선 필요가 없어서 안 넣었다. 설치가 완료되면 아래와 같은 내용들이 나온다. (ip랑 port, 토큰 부분은 ㅌㅌㅌ로 처리했다.)


Your Kubernetes master has initialized successfully!


To start using your cluster, you need to run the following as a regular user:


  mkdir -p $HOME/.kube

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

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


You should now deploy a pod network to the cluster.

Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:

  https://kubernetes.io/docs/concepts/cluster-administration/addons/


You can now join any number of machines by running the following on each node

as root:


  kubeadm join <ip>:<port> --token ㅌㅌㅌㅌㅌㅌㅌㅌ --discovery-token-ca-cert-hash sha256:ㅌㅌㅌㅌㅌㅌㅌㅌㅌㅌㅌㅌㅌㅌㅌㅌㅌㅌㅌㅌㅌㅌㅌㅌㅌㅌ


잘 읽어보면 cluster 시작하려면 .kube에 config 파일을 만들라는 내용이 있다. 아주 편리하게 저 내용을 그대로 복사해서 붙여넣으면 된다. 그리고 아래 join에 나오는 내용은 잘 복사해서 저장해두자.


이렇게 하고 "kubectl get pods --all-namespaces" 라고 치면 아래와 비슷하게 나온다. 


NAMESPACE     NAME                                       READY     STATUS    RESTARTS   AGE

kube-system   coredns-78fcdf6894-86s7n                   0/1       Pending   0          7m

kube-system   coredns-78fcdf6894-ngk7x                   0/1       Pending   0          7m

kube-system   etcd-ip-172-31-22-134                      1/1       Running   0          7m

kube-system   kube-apiserver-ip-172-31-22-134            1/1       Running   0          7m

kube-system   kube-controller-manager-ip-172-31-22-134   1/1       Running   0          6m

kube-system   kube-proxy-46x54                           1/1       Running   0          7m

kube-system   kube-scheduler-ip-172-31-22-134            1/1       Running   0          6m


그리고 위에도 써있듯이 cluster에 network를 배포해야 한다. 

위 링크(https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/#pod-network 또는 https://kubernetes.io/docs/concepts/cluster-administration/addons/) 따라가보면 종류별로 방법이 있다. 설치하고 나서 다음과 같이 확인 해보면 된다.


 kubectl get nodes

NAME               STATUS    ROLES     AGE       VERSION

ip-111-11-11-111   Ready     master    32m       v1.11.2


아직 node 를 추가 못해봤는데 다음에는 node 도 따로 추가해봐야겠다.


728x90
반응형

+ Recent posts