흔적s

pod 는 한시적

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

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

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

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

레디니스 프르브

  - 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

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

- 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

- 도커 이미지 빌드

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

1
docker build -t 이미지명 .

- 도커 파일(Dockerfile)

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

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

레플리케이션 컨트롤러

: 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: 이미지명

- 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명]

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

출처 : https://github.com/kubernetes/minikube/releases

맥에서 미니큐브 설치시 필요한 명령어는 아래 한줄

OSX

curl -Lo minikube https://storage.googleapis.com/minikube/releases/v0.32.0/minikube-darwin-amd64 && chmod +x minikube && sudo cp minikube /usr/local/bin/ && rm minikube

이후에 미니큐브 가상머신 시작해 보면 확인 완료

$minikube start

위 실행시 아래 같은 에러 발생되면 거두절미하고, vm 이나 kvm을 설치해 줘야 하는 거임

VBoxManage not found. Make sure VirtualBox is installed and VBoxManage is in the path

나는 위 출처 주소에서 hyperkit 설치해 주고, 미니큐브 가상머신 시작하니 정상 기동됨

Hyperkit driver

The Hyperkit driver will eventually replace the existing xhyve driver. It is built from the minikube source tree, and uses moby/hyperkit as a Go library.

To install the hyperkit driver:

curl -LO https://storage.googleapis.com/minikube/releases/latest/docker-machine-driver-hyperkit \
&& sudo install -o root -g wheel -m 4755 docker-machine-driver-hyperkit /usr/local/bin/

기동은 아래 명령어

$minikube start --vm-driver=hyperkit

출처 : https://docs.fluentd.org/v0.12/articles/install-by-dmg#step2:-launch-td-agent

For MacOS X, we’re using the OS native .dmg Installer to distribute td-agent.

Step1: Install td-agent

Please download the .dmg file from here, and install the software.

• Download

Step2: Launch td-agent

You can launch td-agent with launchctl command. Please make sure the daemon started correctly from the log (/var/log/td-agent/td-agent.log).

$ sudo launchctl load /Library/LaunchDaemons/td-agent.plist
$ less /var/log/td-agent/td-agent.log
2013-04-19 16:55:03 -0700 [info]: starting fluentd-0.10.33
2013-04-19 16:55:03 -0700 [info]: reading config file path="/etc/td-agent/td-agent.conf"

Your configuration file is located at /etc/td-agent/td-agent.conf. Your plugin directory is at /etc/td-agent/plugin. In case you want to stop the agent, please execute the command below.

$ sudo launchctl unload /Library/LaunchDaemons/td-agent.plist

Step3: Post Sample Logs via HTTP

By default, /etc/td-agent/td-agent.conf is configured to take logs from HTTP and route them to stdout (/var/log/td-agent/td-agent.log). You can post sample log records using the curl command.

$ curl -X POST -d 'json={"json":"message"}' http://localhost:8888/debug.test
$ tail -n 1 /var/log/td-agent/td-agent.log
2013-04-19 16:51:47 -0700 debug.test: {"json":"message"}

Uninstall td-agent

td-agent for Mac doesn’t provide uninstallation app unlike rpm / deb. If you want to uninstall td-agent from your Mac, remove these files / directories.

• /Library/LaunchDaemons/td-agent.plist
• /etc/td-agent
• /opt/td-agent
• /var/log/td-agent

Next Steps

You’re now ready to collect your real logs using Fluentd. Please see the following tutorials to learn how to collect your data from various data sources.

• Basic Configuration
  • Config File
• Application Logs
  • Ruby, Java, Python, PHP, Perl, Node.js, Scala
• Examples
  • Store Apache Log into Amazon S3
  • Store Apache Log into MongoDB
  • Data Collection into HDFS

Please refer to the resources below for further steps.

• ChangeLog of td-agent
• Chef Cookbook