Kubernetes 명령어
-command
▸ get : 지정한 객체 목록을 한 줄에 하나씩 출력한다.
▸ describe : get 보다 더 자세한 정보를 보인다.
▸ apply : 매니페스트에 기술된 객체가 존재하지 않으면 생성하고 존재하면 변경한다.
▸ create : 매니페스트에 기술된 객체를 생성. 이미 있으면 에러 반환.
▸ delete : 매니페스트에 기술된 객체 삭제.
▸ config : 접속 대상이 되는 콘텍스트(K8s 클러스터, 네임스페이스, 유저) 목록 출력이나 삭제
▸ exec : 실행중인 파드 컨테이너에 대화형으로 커맨드 실행, 파드 내에 컨테이너가 여러 개존재하면 –c 옵션으로 컨테이너_명을 지정, 컨테이너_명은 kubectl get describe <파드_명>으로 확인
▸ run : 최초로 파드 실행.
▸ logs : 컨테이너에 로그 표시.
-resource
▸ pod(po) : 컨테이너의 최소 실행단위로 실행 시 파드 네트워크상의 IP_주소를 할당받으며 한 개 이상의 컨테이너를 포함 할 수 있다.
▸ poddistruptionbudget(pdb) : 파드가 지정한 개수 이하가 되지 않도록 디플로이먼트, 스테이트풀셋, 리플리카셋, 리플리케이션 컨트롤러의 동작을 제어한다.
▸ services(svc) : 파드를 클라이언트들에게 공개해서 접속하게 함
▸ endpoints(ep) : 서비스를 제공하는 파드의 IP_주소와 포트 관리
▸ ingress(ing) : 서비스 공개, TLS 암호, 세션 유지, URL 매핑 기능 제공
▸ deployment(deploy) : 파드의 리플리카 수, 자기회복, 롤아웃, 롤백 등을 제어하는 컨트롤러
▸ replicaset(rs) : 파드의 리플리카(복제) 수를 제어하는 컨트롤로로 디플로이와 연계해서 동작
▸ statefulset(sts) : 퍼시스턴트 데이터를 보유하는 파드를 제어하는 컨트롤러, 퍼시스턴트 볼륨과 파드를 하나씩 쌍으로 묶어서 각 이름에 동일한 일련번호를 부여해서 관리
▸ job : 배치 처리를 수행하는 파드를 관리하는 컨트롤러
▸ cronjob : 정기적으로 실행되는 배치 처리를 관리하는 컨트롤러
▸ daemonset(ds) : 모든 노드에 파드를 배치하는 컨틀롤러
▸ relicationcontroller(rc) : 파드의 리플리카 수를 제어하는 컨틀로러, 리플리카셋의 이전 버전
▸ horizontalpodautoscaler(hpa) : 워크로드에 따라 파드 수를 자동 조정하는 컨트롤러
▸ persistentvolume(pv) : 로우레벨 스토리지 관리
▸ persistentvolumeclain(pvc) : 스토리지 클래스와 용량을 지정해서 논리 볼륨의 브로비저닝(provisioning)을 요구
▸ storageclass(sc) : 스토리지의 종류
▸ node(no) : 쿠버네티스 클러스터의 워크로드를 실행시키는 호스트머신
▸ apiservice : 마스터가 지원하는 API 서비스 관리
▸ componentstatuses(cs) : 스케쥴러, 컨트롤러 매니저, etcd-0에 헬쓰 체크 결과 보고
▸ controllerrevision : 컨트롤러 리비전 관리
▸ event : 쿠버네티스 클러스터에서 발생된 이벤트를 기록하고 표시하는 컨트롤러
▸ configmap(cm) : 환경 설정 파일 등 저장
▸ secret : 패스워드 등 비밀성이 요구되는 정보 저장
▸ namespace(ns) : 쿠버네티스 클러스터를 논리적으로 분할해서(VLAN 느낌) 사용
▸ serviceaccount(sa) : 파드에서 실행되는 프로세스를 위한 어카운트로 접근 권한 식별
▸ role : 일련의 권한을 기술하여 롤을 정의하고, 어느 롤의 유효범위는 해당 네임스페이스로 한정됨
▸ rolebinding : 서버의 어카운트와 롤을 바인딩
▸ clusterrole : 쿠버네티스 클러스터 전체에 유효한 롤
▸ clusterrolebinding : 쿠버네티스 클러스터 전체에 유효한 클러스터 롤과 서비스 어카운트를 매핑
▸ certificatesigningrequest(csr) : 인증기관(CA)에 인증서 요구서 작성
▸ networkingpolicies(netpol) : 네임스페이스 사이의 네트워크 접근 제어
▸ podsecruitypolicies(psp) : 파드 시큐리티 관련 항목의 기본값 설정
▸ limitrange(limits) : 네임스페이스 내 컨테이너의 CPU와 RAM 요구값과 상한값의 기본값 설정
▸ resourcequota(quota) : 네임스페이스별 CPU와 RAM 요구량의 상한값 설정
- 옵션
-n 네임스페이스_명 : 조직을 지정된 네임스페이스로 한정시킴
--all-namespaces –A : 모든 네임스페이스에 적용함
-o=yaml : YAML 포맷으로 API 객체 표시
-o=wide : 추가 정보 표시(파드의 IP, 배치된 노드_명 등)
-o=json : JSON 포맷으로 API 객체 표시
-o=custom-columns=<spec> : 항목을 지정해서 목록 표시
-o=custom-columns-file=<file> : 템플릿 파일로 출력할 컬럼 지정
-o=jsonpath=<template> : jsonpath에 일치하는 목록 표시
-o=jsonpath-file=<file_name> : jsonpath 형식의 템플릿 파일로 출력할 내용 지정
kubectl command
=>columns.txt 파일을 불러서 실행한다면
▸ kubectl get pods –o=custom-columns-file=columns.txt 해주면 된다.
=>json_temp.txt 파일을 불러서 실행한다면
▸ kubectl get pods –o=jsonpath-file=json_temp.txt 해주면 된다.
=>정밀하게 본다면
▸ kubectl get pods –o=jsonpath='{range.items[*]}{.metadata.name}{"\t"}{.status.start Time}{"\"}{end}' 해주면 된다.
▸ KUBECONFIG=~/.kube/config:~/.kube/kubeconfig2 kubectl config view
▸ kubectl config get-contexts와
▸ kubectl config use-context <my-cluster-name> : 콘텍스트 목록 표시, 콘텍스트 교체
▸ kubectl config current-context : 선택 중인 콘텍스트 보기
미리 —user=<유저_명>, --cluster=<쿠버네티스_클러스터_명>이 등록되어 있다면
▸ kubectl config set-context production-c3 —namespace=production —cluster=c3 —user=admin-c3 : 네임스페이스를 지정해서 콘텍스트 작성
▸ kubectl config use-context production-c3 : 네임스페이스 변경
객체 생성
YAML이나 JSON 형식의 매니페스트 파일로부터 객체를 생성할 수 있는데 이미 객체가 있으면 create를 apply로 바꿔줘야 오류가 안 뜬다. apply는 기존에 존재하는 객체에 적용했을 때 변화가 없으면 unchanged로 나오고, 변화가 있으면 configured라고 보이므로 크게 문제되지 않아서 대부분 객체를 만들 때에는 create 대신 apply를 사용하는 것이 좋다.
▸ kubectl create –f <my_manifest.yml> : 매니페스트 파일로부터 객체 생성
▸ kubectl create –f <my_manifest1.yml> -f <my_manifest2.yml> : 복수의 매니페스트 파일로부터 객체 생성
▸ kubectl create –f <manifest_directory> : yaml, yml, json 등의 확장자로 되어 있는 여러 매니페스트 파일이 들어있는 디렉터리 대상으로 객체 생성
▸ kubectl create –f https://raw.githubusercontent.com/Jpub/15_DankdK/master/ step08/deployment1.mal : 웹 URL로부터 객체 생성
- 객체 삭제
한번 만들어진 객체는 삭제 때까지 지속되므로 불필요한 객체는 삭제하는데 매니페스트나 매니페스트가 들어있는 디렉터리를 지정해서 삭제하는 것이 좋다.
▸ kubectl delete –f <my_manifest.yaml> : 매니페스트_파일로부터 삭제
▸ kubectl delete po nginx : 파드_명으로 삭제
▸ kubectl delete deploy web-deploy : 디플로이먼트_명으로 삭제
▸ kubectl delete service webservice : 서비스_명으로 삭제
▸ kubectl delete –f <directory> : 디렉터리 내 매니페스트로부터 삭제
▸ kubectl delete pods —all : 모든 파드를 일괄적으로 삭제
- 객체 표시
객체를 표시할 때 get와 describe를 사용하면 되는데 get는 하나의 객체를 한 줄에 표시하고, describe는 상세한 정보를 표시한다. 여러 리소스를 , 로 나열하면 여러 리소스를 표시할 수 있다.
▸ kubectl get service(OR kubectl get svc : 단축형) : 서버 리스트 표시
▸ kubectl get pods(OR kubectl get po)
▸ kubectl get po —all-namespaces : 모든 네임스페이스에서 파드 표시 네임스페이스_명을 별도로 지정하지 않으면 default가 사용된다. 여기서 kube-system은 설정해둔 네임스페이스_명이다.
▸ kubectl get po –n kube-system : 클러스터 내의 kube-system 네임스페이스 정보 표시
▸ kubectl get po –o wide : 파드의 IP_주소나 할당된 노드를 자세히 표시
쿠버네티스에서 네임스페이스는 단일 클러스터 내에서의 리소스 그룹을 격리하는 VLAN과 같은 메커니즘을 제공한다. 리소스의 이름은 네임스페이스 내에서 유일해야 하며, 네임스페이스 간에서는 유일할 필요가 없다. 네임스페이스는 여러 개의 팀이나 프로젝트에 많은 사용자가 있는 환경에서 사용하도록 만들어졌기 때문에 사용자가 거의 없거나 수십명 정도가 되는 경우에는 네임스페이스를 고려할 필요가 없다.
노드 보수작업
컨테이너를 실행시키고 있는 하나의 노드에 보수작업을 한다면 kubectl 명령어로 쿠버네티스 클러스터에서 해당 노드를 분리해서 정지시키고, 작업을 완료한 뒤 파드가 다시 실행되게 스케쥴링 할 수 있다.
문제 식별
파드상의 문제를 식별하기 위해서 파드 컨테이너에서 어떤 일이 있는지 확인할 필요가 있는데 –o yaml은 매니페스트 파일로 저장하면, 현재 파드의 내용을 보일 뿐만 아니라 현재의 상태를 취득해서 표시해주므로 실행중인 파드를 분석하기에 유용하다
Kubernetes 안에서 Docker를 실행할 수 있다.
Docker가 실행되는 과정을 보면
① 터미널에서 docker run hello-world를 실행하면 도커 데몬이 도커 허브에 접속한다. 도커 데몬을 엔진으로 부르고 있어서 도커 데몬을 도커 엔진이라고도 한다.
② library/hello-world는 도커 허브에 있는 리포지터리 이름이다. 도커 엔진은 도커 허브의 리포지터리 https://hub.docker.com/_/hello-world/에서 컨테이너를 위한 이미지를 로컬에 다운한다.
③ 이어서 도커 엔진이 이미지에서 컨테이너를 생성하고, 컨테이너상의 프로세스가 표준 출력으로 메시지를 쓰기 시작한다.
④ 마지막으로 도커 엔진은 컨테이너 표준 출력을 도커 커맨드에 보내고 터미널에 표시한다.
도커 이미지는 운영체제와 소프트웨어를 담고 있는 컨테이너 실행 이전의 상태로써 기본 이미지만 있으므로 여기서 각종 설정 등을 수행한 뒤, 다시 도커 서버로 올려서 배포할 수 있다. 각 이미지는 "리포지터리:태그"로 식별한다. 도커 리포지터리는 이미지 보관소인데, 리포지터리의 이름에 버전 등을 의미하는 태그를 붙여서 각 이미지를 구분해서 보관할 수 있다. 태그를 생략하면 latest가 자동으로 붙는다.
리포지터리 대신에 레지스트리라는 용어를 사용하기도 한다. 레지스트리는 Windows의 설정 정보 데이터베이스를 말하기도 하지만 도커에서는 리포지터리의 집합체로 리포지터리를 제공하는 서버를 말한다.
컨테이너는 이미지, 실행, 정지의 세 가지 상태를 가진다. 이미지는 컨테이너의 모형이 되는 것으로 실행되기 전의 상태이고, 실행은 컨테이너 위에서 프로세스가 실행중인 상태이며, 정지는 프로세스의 종료 코드, 로그가 보존된 채 정지된 상태이다.
*** Ubuntu node에서 실행중인 Nginx, MySQL, CentOS, Ubuntu 등의 Pod(Container)를
1) Ubuntu node에서
2) 이웃한 Pod에서
해킹해봄으로써 보안에 대한 실습을 해볼 수 있다.
centos : 172.17.0.3
ubuntu : 172.17.0.2
이미지 생성해서 도커 허브에 올리는 법
1) index.js 작성
var http = require('http');
var handleRequest = function(req, res){
res.end('hello');
});
var www = http.createServer(handleRequest);
www.listen(4000);
2) Dockerfile 작성
FROM node:6
EXPOSE 4000
COPY index.js .
CMD node index.js
3) Docker image 빌드
docker build --tag hopus627/hello:test .
4) Docker Hub에 올리기
a) 먼저 https://hub.docker.com에서 hopus627 레포지터리 아래에 Kali 레포지터리를 생성하고
b) 이제 docker login 해서 크레덴셜로 로그인하고
c) docker push hopus627/kali/hello.test
5) https://hub.docker.com에서 확인하기