반응형


$kubectl edit

   기본 편집기에서 객체의 매니페스트 파일을 연다.

   변경한 후, 파일을 저장하고 편집기를 종료하면 오브젝트가 갱신된다.

    ex) kubectl edit deployment kubia


$kubectl patch

    객체의 개별 속성을 수정한다.

    ex) kubectl patch deployment kubia -p '{"spec": {"minReadySeconds": 10 }}'


$kubectl apply

     전체 yaml 또는 json 파일의 속성 값을 적용해 객체를 수정한다.

      yaml , json에 정의된 객체가 아직 존재하지 않으면 생성된다.

     이 파일에는 리소스의 전체 정의가 포함돼야 한다.

     ex) kubectl apply -f kubia-deployment-v2.yaml


$kubectl replace

    객체를 yaml, json 파일의 새 객체로 바꾼다. 

    apply 명령과 달리 해당 명령은 객체가 존재해야 한다. 그렇지 않으면 오류를 출력한다.

      ex) kubectl replace -f kubia-deployment-v2.yaml


$kubectl replace

     pod, replicationcontroller 의 템플릿, 디플로이먼트, 데몬셋, 잡 또는 레플리카셋에 정의된 컨테이너 이미지를 변경한다.

      ex) kubectl set image deployment kubia nodejs=iamreob/kubia:v4







반응형

'DevOps' 카테고리의 다른 글

Docker Error  (0) 2019.06.05
Docker 명령어 정리  (2) 2019.03.21
쿠버네티스 명령어 #6  (0) 2019.01.31
쿠버네티스 구조  (0) 2019.01.10
pod-레플리케이션컨트롤러-서비스  (0) 2019.01.10
반응형

출처 : kubernetes in action


Downward API

 - 해당 POD 의 내부에서 실행중인 프로세스에 POD 자체의 메타 데이터를 노출할 수 있다.

    . pod 명

    . pod ip 주소

    . pod 네임스페이스

    . pod 가 실행되고 있는 Node 명

      ...


1) 환경변수를 통한 메타데이터 노출

apiVersion: v1

kind: Pod

metadata:

  name: 포드명

spec:

  containers:

  - name: main

    image: ㅇㅇㅇ

    command: ㅇㅇㅇ

    resources:

      requests:

         ....

      limits:

         ....

    env:

    - name: POD_NAME

      valueFrom:

        fieldRef:

          fieldPath: metadata.name

    - name: POD_NAMESPACE

      valueFrom:

        fieldRef:

          fieldPath: metadata.namespace

    .....



   2) downward API 볼륨 내의 file을 통한 메타데이터 전달

       




Deployment

- 애플리케이션을 배포하고 이를 선언적으로 업데이트하는데 사용하는 상위 수준의 리소스

- deployment 를 만들면 레플리카셋 리소스가 아래에 만들어짐

   (레플리카셋은 pod를 복제하고 관리)

- deployment 가 필요한 이유는...

   : 애플리케이션을 업데이트할때 추가적인 ReplicationController 가 필요하고, 이전 ReplicationController와 잘 조화되게끔 컨트롤러를 조정해야 한다.

     즉, 전체적으로 통제할 무언가가 필요하고 그 역할을 deployment가 담당한다.

     (deployment 가 직접 수행하는 것은 아니고 쿠버네티스 컨트롤 플레인에서 실행하는 컨트롤러 프로세스가 이를 수행)


- deployment 상태 확인 명령어

   $kubectl rollout status deployment [deployment리소스명]



- Deployment 전략

  > Recreate 전략

     : 새 pod를 만들기 전에 기존 pod를 삭제

       애플리케이션이 여러 버젼을 동시에 실행할 수 없으며, 새 버젼을 시작하기 전에 이전버젼을 완전히 중지해야 하는경우 사용

       애플리케이션 down time 짧게 포함된다.


   > RollingUpdate 전략

      : 오래된 pod를 하나씩 제거하는 동시에 새로운 pod를 추가해 전체 업데이트 프로세스에 걸쳐 애플리케이션을 사용할 수 있도로한다.



Deployment의 롤아웃 히스토리 보여주기

   - deployment는 리비전 히스토리를 유지하므로 롤아웃, 롤백이 가능하다.

   - 히스토리는 레플리카셋 내부에 저장된다.

  $kubectl rollout history deployment [deployment명]


특정 Deployment 리비전으로 롤백하기

    $kubectl rollout undo deployment [deployment명] --to-revision=1

  - 비활성 레플리카셋을 삭제하면 롤백할 수 없으므로 삭제하면 안된다.

 

롤링 업데이트 전략의 maxSurge와 maxUnavailable 속성

    - maxSurge

       : 배포에 구성된 원하는 복제본 수 위에 존재하도록 허용하는 포드 인스턴스 수를 결정한다.

         즉, 이값이 25% 이면 원하는 수보다 25% 더 많은 포드 인스턴스까지만 있을 수 있다.

              25%이고, 원하는 수가 4면, 최대 5개까지만 존재할 수 잇다는 것


    - maxUnavailable

       : 업데이트 중에 원하는 복제본 수에 비례하여 사용할 수 없는 포드 인스턴스 수를 결정한다.


롤아웃 프로세스 일시 중지

    - deployment 는 롤아웃 프로세스 중에 일시 중지될 수 있다.

      이렇게 하면 나머지 롤아웃을 진행하기 전에 새 버전이 제대로 작동하는지 확인 할 수 있다.

      $kubectl rollout pause deployment [deployment명]

    - 카나리아 릴리즈

      : 잘못된 버전의 애플리케이션을 롤아웃 하고 모든 사용자에게 영향을 줄 위험을 최소화하기 위한 기술

    - 롤아웃 재개

      $kubectl rollout resume deployment [deployment명]      


 




반응형

'DevOps' 카테고리의 다른 글

Docker 명령어 정리  (2) 2019.03.21
쿠버네티스 기존 리소스 수정  (0) 2019.02.08
쿠버네티스 구조  (0) 2019.01.10
pod-레플리케이션컨트롤러-서비스  (0) 2019.01.10
쿠버네티스 명령어#5  (0) 2019.01.02
반응형

반응형

'DevOps' 카테고리의 다른 글

쿠버네티스 기존 리소스 수정  (0) 2019.02.08
쿠버네티스 명령어 #6  (0) 2019.01.31
pod-레플리케이션컨트롤러-서비스  (0) 2019.01.10
쿠버네티스 명령어#5  (0) 2019.01.02
쿠버네티스 명령어 #4  (0) 2018.12.31
반응형

pod 는 한시적

pod가 삭제되거나, 실행중인노드가 실패하게 되면 등등... 레플리케이션컨트롤러가 손실된 pod를 새로운 pod로 대체한다.

대체 pod는 기존의 pod와는 다른 ip를 할당받는다.


서비스는 정적 ip를 얻고, 클라이언트는 이 정적 ip를 통해 서비스에 연결해야 pod의 일시성에 대비해서 정상적인 서비스가 가능하다.

즉, 서비스는 동일한 서비스를 제공하는 하나 이상의 pod 그룹의 정적 위치를 나타냄

반응형

'DevOps' 카테고리의 다른 글

쿠버네티스 명령어 #6  (0) 2019.01.31
쿠버네티스 구조  (0) 2019.01.10
쿠버네티스 명령어#5  (0) 2019.01.02
쿠버네티스 명령어 #4  (0) 2018.12.31
Docker 명령어  (0) 2018.12.28
반응형


레디니스 프르브

  - pod를 위한

  - 라이브니스 프로브는 상태가 좋지 않은 컨테이너를 종료하고, 새로운 것으로 교체하여 pod의 상태를 좋게 유지한다.

    레디니스 프로브는 오직 pod가 요청을 수신할 수 있는 환경이 됐을때 수신한다.

  - pod의 레디니스 프로브가 실패하면, 해당 pod는 endpoint 오브젝트에서 제거된다.

  - 레디니스 프로브는 클라이언트가 정상 상태인 pod하고만 통신하게 하고, 시스템에 문제가 있다는 것을 알아차리지 못하게 한다. 


서비스를 통해 pod에 접속하지 못할때

  - 외부가 아닌 클러스터 안에서 클러스터IP를 대상으로 연결하고 있다는 것을 명심

  - 서비스가 액세스 가능한지 확인하기 위해 서비스 ip로 ping 보내는 것을 귀찮게 여기지 마라

  - readiness probe를 정의했다면 성공 여부를 확실히 확인하라

  - pod가 서비스의 일부분인지 확인하라(kubectl get endpoints)

  - 대상 port가 아닌 서비스에 의해 노출된 port에 연결하고 있는지를 확인하라

  - pod ip에 직접 연결을 시도해서 pod가 정확한 port의 연결을 수락하고 있는지 확인하라

  


Volume

- pod의 각 컨테이너에는 고유의 분리된 파일 시스템이 있다.

- 실제 데이터가 있는 디렉토리를 보존하기 위해서 저장소 volume을 정의한다.

- 볼륨은 pod의 컴포넌트이다.

- 독립적인 쿠버네티스 오브젝트가 아니며 스스로 생성하거나 삭제할 수 없다.

- volume의 라이프 사이클은 pod 와 같다



[뜬금 명령어]

 - 특정 리소스의 yaml 파일 확인을 위한 명령어 

   $kubectl get [리소스타입] [리소스명] -o yaml

    ex) kubectl get  pod podname -o yaml

          kubectl get configmap configmapname -o yaml


emptyDir 

- 동일한 pod에서 실행중인 컨테이너간에 파일을 공유할 때 유용



ConfigMap 

 - 설정 데이터를 저장하는 쿠버네티스 리소스

 

>ConfigMap을 구성하는 방법들

 1) pod들 중 하나로 ConfigMap을 사용

    $kubectl create configmap [configmap명] --from-literal=[key값]=[value값]


 2) 개별 파일(을 읽어와서) 내용으로 ConfigMap 엔트리 생성

    - 외부의 설정파일을 통해서 설정 데이터를 저장할 수 있다.

      $kubectl create configmap my-config --from-file = config-file.conf

        -> 위 명령어를 실행하면 kubectl 을 실행하는 디렉터리에서 config-file.conf를 찾는다.

        -> 파일이름이 맵의 키로 사용된다. 파일의 내용이 value 로...

        -> 수동으로 key명 지정도 가능하다.

             $kubectl create configmap my-config --from-file = customkey = config-file.conf


 3) 디렉토리에 있는 파일로 부터 ConfigMap 만들기
     - 파일 디렉토리에서 모든 파일을 가져올 수 있다.
       $kubectl create configmap my-config --from-file =/path/to/dir


 4) 위의 3가지 모두를 결합하여 구성할 수 있다.
     $kubectl create configmap my-config --from-file = config-file.conf --from-file =/path/to/dir --from-literal=xxx=yyy




>ConfigMap의 값을 pod의 컨테이너로 가져오는 방법

  1) 환경변수 설정 (valueFrom 필드사용)
apiVersion: v1

kind: Pod

metadata:

  name: fortune-env-from-configmap

spec:

  containers:

  - image: luksa/fortune:env

    env:

    - name: INTERVAL

      valueFrom: 

        configMapKeyRef:

          name: fortune-config

          key: sleep-interval

 

  2) configmap의 모든 항목을 한번에 환경변수로 전달하기

      - envFrom 속성을 사용

        spec:

            containers:

            - image: some-image

               envFrom:

               -  prefix: CONFIG_

                   configMapRef:

                        name: my-config-map


         ->결과는 configMap 의 key 값에 앞에 prefix 가 붙은 값으로의 환경변수가 컨테이너 내부에 존재하게 됨


    

    3) configmap 항목을 명령해 인자로 전달하기

         - 컨테이너에서 실행중인 메인 프로세서로 configMap의 값을 인자로 전달하는 방법임

           


     4) ConfigMap 엔트리를 파일로 노출하기 위해 ConfigMap Volume 사용

         - 설정파일들이 많을 경우에 사용

         - configMap 볼륨은 ConfigMap의 각 엔트리를 파일로 표시한다.

        


> ConfigMap을 사용해 볼륨을 통해 노출시키면 Pod를 다시 만들거나 Container를 다시 시작하지 않고도 설정을 업데이트 할 수 있음

    1)configmap 파일 수정

        $kubectl edit configmap [컨피그맵명]




Secret

- ConfigMap 과 유사 , key /value 쌍

- 일반설정 데이터를 저장할때는 ConfigMap 을 사용

- 중요한 , 민감한 데이터를 저장할때는 Secret을 사용


> secret 리소스 나열

  $kubectl get secret






반응형

'DevOps' 카테고리의 다른 글

쿠버네티스 구조  (0) 2019.01.10
pod-레플리케이션컨트롤러-서비스  (0) 2019.01.10
쿠버네티스 명령어 #4  (0) 2018.12.31
Docker 명령어  (0) 2018.12.28
쿠버네티스 명령어#3  (0) 2018.12.27
반응형


- pod는 일회성

- 여러 pod가 단일 서비스를 제공할 경우, (클라이언트 입장에서)모든 pod는 단일 ip 주소를 통해 액세스 할 수 있어야 한다.


Kubernetes Service

- 동일한 서비스를 제공하는 pod group 에 단일 진입 점을 만들기 위해 생성하는 리소스

- 각 서비스에는 서비스가 존재하는 동안 절대로 변경되지 않는 ip 주소와 port 가 있다.

   클라이언트는  해당 IP 및 포트에 연결할 수 있고, 이런 연결은 해당 서비스를 지원하는 pod 중 하나로 라우팅 된다.

- 서비스는 오직 단일 port 뿐만 아니라, 여러개의 port 도 지원할 수 있다.


[Service의 주 목적 ]

 포드들의 그룹을 클러스터상의 포드에게 노출하는것.



- 원격접속

  $kubectl exec [pod명] 


- Client 로 부터 받은 요청을 매번 같은  pod로 요청하고 싶으면,  sessionAffinity 속성을 ClientIP 로 하면 된다.

   spec: 

       sessionAffinity: ClientIP (None 으로 하는 경우는 랜덤하게 됨)



- 포드의 환경변수 확인

   $kubectl exec [포드명] env


- pod 안으로 들어가기

   $kubectl exec -it [pod명] bash



- 클러스터 외부 서비스에 연결

   . 서비스는 pod를 직접 링크하지 않음

   . 서비스와 pod 사이에 endpoint라는 리소스가 위치함

   . endpoint는 서비스에 의해 노출되는 IP주소와 PORT의 목록임


- 서비스에 대한 상세정보 확인

   $kubectl describe svc [서비스명]


- 서비스의 endpoint 확인

 $kubectl get endpoints [서비스명]


- pod Selector 는 들어오는 연결을 리다이렉트할때 직접 사용되진 않고, ip와 port의 목록을 만드는데 사용된다.

  그리고 이 만들어진 목록이 endpoint에 저장된다. 

- pod Selector 없이 서비스를 만들었다면, 쿠버네티스는 endpoint 리소스 조차 만들지 못한다.



- 서비스가 외부에서 Access 가능하게 하는 방법

1) NodePort 서비스 사용

   . 서비스를 생성하고  타입을 NodePort 로 지정


- jsonPath 를 이용해 모든 노드의 ip 얻기

   $kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}'



2) 외부 로드밸런서를 이용한 서비스 사용

   . 서비스 타입을 LoadBalancer 로 지정

   . 로드밸런서는  자신만의 고유하면서 외부에서 액세스가 가능한 ip 주소를 갖고 모든 연결을 서비스로 리다이렉트 한다.

   

   - externalTrafficPolicy

     : 외부 클라이언트가 서비스로 노드포트를 통해 연결할 때, 임의로 선택된 pod는 연결요청을 받았던 같은 node에서 실행될 수도 아닐수도 있다.

       이를 요청받은 노드에 있는 pod에서 실행되도록 하기 위해 서비스 spec 에 externalTrafficPolicy: Local   을 지정하면 , 로컬내에서  실행되고 있는 pod를 호출하게 된다.

      단, 로컬에 pod가 없으면 대기한다.

            그리고, 이렇게 연결할때 단점은, 일반적으로의 연결은 모든 pod에 걸쳐 전달되지만 이렇게 구성하면 모든 pod 가 되지 않는다.


3) Ingress 리소스를 이용한 방법

    . 필요한 이유 : 각 loadbalancer 서비스는 그 자신만의 외부 ip를 갖는 자체 로드밸런서를 요구하기 때문

    . Ingress 리소스를 작동시키려면, 클러스터에서 Ingress 컨트롤러를 실행해야 한다.

    

- 모든 네임스페이스의 pod 조회

  $kubectl get po --all-namespaces









   



반응형

'DevOps' 카테고리의 다른 글

pod-레플리케이션컨트롤러-서비스  (0) 2019.01.10
쿠버네티스 명령어#5  (0) 2019.01.02
Docker 명령어  (0) 2018.12.28
쿠버네티스 명령어#3  (0) 2018.12.27
쿠버네티스 명령어 #2  (0) 2018.12.27
반응형


- 도커 이미지 빌드

  Dockerfile을 만든 후 해당 디렉토리로 이동하여 다음 명령어를 입력하면 이미지 빌드 완료

1

docker build -t 이미지명 .


- 도커 파일(Dockerfile)

  . ENTRYPOINT 는 컨테이너가 시작되었을때 호출되어야 할 실행파일을 정의한다.

  . CMD는 ENTRYPOINT로 전달할 인자를 지정한다.

 

 

반응형

'DevOps' 카테고리의 다른 글

쿠버네티스 명령어#5  (0) 2019.01.02
쿠버네티스 명령어 #4  (0) 2018.12.31
쿠버네티스 명령어#3  (0) 2018.12.27
쿠버네티스 명령어 #2  (0) 2018.12.27
kubernetes 명령어#1  (0) 2018.12.27
반응형

레플리케이션 컨트롤러

: pod가 항상 실행되도록 하는 쿠버네티스 리소스

  - 실행중인 pod의 수를 모니터링하고, 실제 원하는 갯수와 실행수가 일치하는지를 확인한다.

  - 라벨셀렉터와 매치되는 pod를 찾음 -> 매치되는 수와 원하는 수를 비교 -> 많거나 적으면, 생성 삭제 한다.

  - 3가지 필수요소

     1) 레플리케이션컨트롤러의 범위에 있는 pod를 결정하는 label Selector

     2) 실행해야 하는 pod의 원하는 수를 지정하는 복제본 수

     3) 새로운 pod 복제본을 만들때 사용되는 pod Template




- 레플리케이션 컨트롤러 목록 정보 얻기

  $kubectl get rc


- 레플리케이션 컨트롤러 상세 정보 확인

  $kubectl describe rc [rc명]


- 레플리케이션 컨트롤러의 yaml 정의 열기

  $kubectl edit rc [rc명]


- 레플리케이션 컨트롤러 스케일업(pod수 증가)

  $kubectl scale rc [rc명] --replicas=10


- 레플리케이션 컨트롤러 삭제

  1) 레플리케이션 컨트롤러와 pod를 모두 삭제

    $kubectl delete rc [rc명]

  2) 레플리케이션 컨트롤러만 삭제하고 pod는 계속 실행

    $kubectl delete rc [rc명] --cascade=false



레플리카셋

: 차세대 레플리케이션 컨트롤러

  - 일반적으로 레플리카셋을 직접 만들지는 않음 / deployment 할때 생성됨

  - 레플리케이션컨트롤러와 똑같이 동작

     그러나, 더 풍부한 표현식 pod selector 를 갖음

      ex) env=p , env=k   이 조건에 대해서

            레플리케이션 컨트롤러는 포드를 위 2개 조건을 동시에 일치시킬 수 없다.

           그러나, 단일 레플리카셋 은 2개의 pod 세트와 일치시킬수 있으며,  단일 포드로 취급할 수 있다.

     ex ) env=*  ( 값과 상관없이 키 에 대한 일치)

          

- 레플리카셋 조회

  $kubectl get rs


- matchExpression 셀렉터

  spec:

  replicas: 3

  selector:

    matchExpressions:

      - key: app

        operator: In

        values:

         - k



4가지 연산자

 1) In : 라벨의 값이 지정된 값 중 하나와 일치해야 한다.

2) NotIn : 라벨의 값이 지정된 값과 일치해서는 안된다.

3) Exists : pod에는 지정된 key 가 있는 라벨이 포함되어야 한다. (값은 중요하지 않음)

4) DoesNotExist : pod에는 지정된 key가 있는 라벨을 포함하면 안된다.



- 레플리카셋 삭제

  $kubectl delete rs [rs명]

   레플리카셋 삭제하면 해당 pod도 삭제됨




데몬셋

- 각 노드에서 pod를 실행해야 하는 경우가 있음

   ex) 로그 수집기, 리소스 모니터 , kube-proxy

- 데몬셋은 각 노드에서 단일 pod 복제본만 실행하지만, 레플리카셋은 클러스터 전체에서 무작위로 분산시킨다.

- 데몬셋에 의해 만들어진 pod는 이미 대상 node가 지정되어 있고, 쿠버네티스 스케쥴러는 건너뛴다.

- 노드가 다운되더라도, 데몬셋은 어느 곳에서도 pod를 생성하지 않는다.

- 스케쥴을 불가능하게 만드는 속성은 스케쥴러에서만 유효하고, 데몬셋에서 만드는 pod는 스케쥴러와는 무관하다.



- 데몬셋 조회

  $kubectl get ds


- 노드에 라벨 적용하기

  $kubectl label node [노드명] aaa=bbb



잡(job)

 레플리케이션컨트롤러, 레플리카셋 , 데몬셋은 작업의 완료를 고려하지 않고, 계속적으로 타스크를 실행한다.

완료 가능한 타스크에서는 프로세스가 종료된 후 다시 시작하면 안된다. 이를 할 수 있게 해주는게 잡

 - job에서 관리하는 pod는 성공적으로 끝날때까지 재스케쥴 된다.

 - job 조회

   $kubectl get jobs


- job의 타스크가 완료되면 pod 는 더이상 running 하지 않고, Completed 상태로 된다.

  pod가 완료될때 삭제되지 않는 이유는 로그를 검사할 수 있기 위해서다

  (로그 확인 : kubectl logs [pod명] )


- job은 2개 이상의 pod인스턴스를 만들고, 병렬 또는 순차적으로 실행하도록 구성할 수 있다.

  이는 job spec의  completions 와 parallelism  속성으로 수행


spec:

  completions: 5

  parallelism: 2

  template:

    metadata:

      labels:

        app: batch-job


순차적으로 처리를 위해서 completions에 설정


-job이 실행되는 동안에도 scaling 이 가능하다.

 


- 쿠버네티스의 cron 처리는, CronJob 

apiVersion: batch/v1beta1

kind: CronJob

metadata:

  name: 배치잡명

spec:

  schedule: "0,10,20,30,40,50,60 * * * *"

  jobTemplate:

    spec:

      template:

        metadata:

          labels:

            app: ㅇㅇㅇㅇ

        spec:

          restartPolicy: OnFailure

          containers:

          - name: main

            image: 이미지명








반응형

'DevOps' 카테고리의 다른 글

쿠버네티스 명령어 #4  (0) 2018.12.31
Docker 명령어  (0) 2018.12.28
쿠버네티스 명령어 #2  (0) 2018.12.27
kubernetes 명령어#1  (0) 2018.12.27
미니큐브 설치 맥  (0) 2018.12.23
반응형


- namespace 생성

  $kubectl create namespace [네임스페이스명]

  

-특정 namespace 에 pod 생성

 $kubectl create -f xxxxx.yaml -n custom-namespace


- pod 삭제

  1)이름으로 삭제시

    $ kubectl delete po [pod명]


  2) 라벨셀렉터로 삭제시

   $kubectl delete po -l [라벨key=값]

  

   3) 현재 네임스페이스의 모든 pod 삭제시

    $kubectl delete po -all


-pod생성

 $kubectl create -f xxxxx.yaml


- pod의 에러로 restart 한 경우 로그 확인

  $kubectl logs [pod명] --previous


- pod 가 다시 시작해야 하는 이유를 알고자 할때 

  $kubectl describe po [pod명]



반응형

'DevOps' 카테고리의 다른 글

Docker 명령어  (0) 2018.12.28
쿠버네티스 명령어#3  (0) 2018.12.27
kubernetes 명령어#1  (0) 2018.12.27
미니큐브 설치 맥  (0) 2018.12.23
fluentd mac설치  (0) 2018.12.18
반응형

- cluser 작동중인지  확인
 $kubectl cluster-info

- pods 정보 확인
 $kubectl get pods

- 특정 pod 의 yaml 정의 확인
 $kubectl get po [pod명] -o yaml

- 리소스 생성
 $kubectl create -f xxxx.yaml

- pod 로그 확인
 $kubectl logs [pod명]

- 디버깅 또는 다른 이유로 서비스를 거치지 않고, 특정포드와 통신하고 싶을때 ....port fowarding
 $kubectl port-forward [pod명] 8888:8080

  Forwarding from [::1]:8888 -> 8080


- pod의 라벨확인
 $kubectl get po --show-labels

- pod에 라벨 붙이기
 $kubectl label po [pod명] creation_method=manual

- pod 의 라벨 변경
  $kubectl label po [pod명] env=debug --overwrite

- 특정 (라벨=값)에 해당되는 pod 조회
 $kubectl get po -l creation_method=manual

- 값에 상관없이 해당 라벨이 있는 pod 조회(env 라벨)
  $kubectl get po -l env

   env in (prod, dev) 
   env notin (prod, dev)

- pod 노드 정보 확인
  $kubectl get node

- pod 노드에 라벨 붙이기

iyeonghoui-MacBook-Pro:k8s ireo$ kubectl get node

NAME                                   STATUS   ROLES    AGE   VERSION

gke-kubia-default-pool-79ce8f08-5rxv   Ready    <none>   1d    v1.10.9-gke.5

gke-kubia-default-pool-79ce8f08-n6xd   Ready    <none>   2d    v1.10.9-gke.5

gke-kubia-default-pool-79ce8f08-tb2j   Ready    <none>   3d    v1.10.9-gke.5

iyeonghoui-MacBook-Pro:k8s ireo$ kubectl label node gke-kubia-default-pool-79ce8f08-5rxv gpu=true

node/gke-kubia-default-pool-79ce8f08-5rxv labeled

iyeonghoui-MacBook-Pro:k8s ireo$ 



- node 라벨=값 이 gpu=true 인  노드 조회

 $kubectl get nodes -l gpu=true



- pod에 주석 추가

 $kubectl annotate pod [pod명] mycompany.com/someannotation="foo bar"


- pod 주석 정보 확인

 $kubectl describe pod [pod명]



- 클러스터에 있는 모든 네임스페이스 나열

 $kubectl get ns



- 특정 네임스페이스에 속한 포드 조회

 $kubectl get po --namespace [namespace명]










반응형

'DevOps' 카테고리의 다른 글

쿠버네티스 명령어#3  (0) 2018.12.27
쿠버네티스 명령어 #2  (0) 2018.12.27
미니큐브 설치 맥  (0) 2018.12.23
fluentd mac설치  (0) 2018.12.18
macbook에 프로메테우스 설치  (0) 2018.11.30

+ Recent posts