Golang 으로 개발된 애플리케이션을 Docker image 로 만드는 Dockerfile 이다.

이미지 사이즈를 줄이기 위해서 빌드 이미지와 실행 이미지를 구분하여 작성하였다.

 

실행 이미지를 더 작게 만들고 싶으면 base를 golang 이미지 대신 alphine 이미지로 만들면 된다.

 

한가지 tip 이라 하면 RUN go mod vendor 를 먼저 하고 나중에 COPY . . 를 하여 소스를 복사한 부분이다.

만약 소스 복사를 먼저하면 변경되 소스로 인해서 (하위 layer 의 변경) go mod vendor 로 다운로드 하는 부분을 수행하게 된다. 하지만 go mod vendor 를 먼저한 후 소스를 복사하면 go mod vendor 에서 수정된 부분이 없으면 해당 layer 를 재사용하기 때문에 매번 다운로드를 하지 않는다.  

 

# vi Dockerfile

FROM golang:1.16.3-stretch AS builder
LABEL AUTHOR Seungkyu Ahn (seungkyua@gmail.com)

RUN mkdir -p /build
WORKDIR /build

COPY go.mod .
COPY go.sum .
RUN go mod vendor
COPY . .
RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o bin/tksinfo ./cmd/server.go

RUN mkdir -p /dist
WORKDIR /dist
RUN cp /build/bin/tksinfo ./tksinfo




FROM golang:alpine3.13

RUN mkdir -p /app
WORKDIR /app

COPY --chown=0:0 --from=builder /dist /app/
EXPOSE 9111

ENTRYPOINT ["/app/tksinfo"]
CMD ["--port", "9111"]
Posted by Kubernetes Korea co-leader seungkyua@gmail.com

댓글을 달아 주세요

2021년 4월 Golang 의 최신 버전은 1.16.x 입니다.

 

go 프로그램을 실행파일로 컴파일 하면 default 는 dynamic library 로 만들어 집니다.

 

아무리 OS 와 architecture 에 맞춰서 cross compile 을 했다고 해도 링크된 모듈이 존재하지 않으면 에러가 납니다.

특히 docker 로 실행할 경우 이런 문제를 자주 겪게 됩니다.

 

1.15 버전 이상에서는 CGO_ENABLED=0 환경 변수로 static library 로 만들 수 있습니다. 참고로 1.14 버전 이하에서는 -tags 옵션을 사용할 수 있습니다.

 

아래 Makefile 은 이 부분을 고려해서 만들었습니다.

GOOS는 OS 의 종류를 GOARCH 는 Architecture 에 맞춰 실행파일을 만듭니다.

 

$ vi Makefile

.PHONY: build clean docker

default: build

all: build docker

build: build-darwin build-linux

build-darwin:
	CGO_ENABLED=0 GOOS=darwin GOARCH=amd64 go build -o bin/tksinfo-darwin-amd64 ./cmd/server.go
	CGO_ENABLED=0 GOOS=darwin GOARCH=amd64 go build -o bin/tksinfo-appclient-darwin-amd64 ./examples/application/client.go

build-linux:
	CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o bin/tksinfo-linux-amd64 ./cmd/server.go
	CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o bin/tksinfo-appclient-linux-amd64 ./examples/application/client.go

clean:
	rm -rf ./bin

docker:
	docker build --no-cache -t seungkyua/tksinfo -f Dockerfile .
Posted by Kubernetes Korea co-leader seungkyua@gmail.com

댓글을 달아 주세요

Istio 의 설치 순서는 다음과 같다.

사전에 Prometheus 와 EasticSearch 는 설치되어 있다고 가정한다.

  1. istio operator 설치
  2. istio control plane 을 위한 istio custom resource 생성
  3. 서비스별 gateway 설치
  4. Jaeger 설치
  5. Kiali 설치

 

1. istio operator 설치

istio operator 를 설치하기 전에 istioctl 명령을 사용할 수 있게 파일을 다운로드 한다.

$ mkdir -p ~/ahnsk/istio && cd ~/ahnsk/istio

$ curl -L https://git.io/getLatestIstio | ISTIO_VERSION=1.9.1 sh -

$ cd ~/ahnsk/istio/istio-1.9.1

 

$ cp bin/istioctl /usr/local/bin/istioctl

 

istio operator 는 helm chart 로 설치하며, 따로 helm repo 를 등록하지 않고 istio source 를 다운받아 설치한다.

먼저, istio 소스를 다운 받는다.

$ cd ~/ahnsk/istio

$ git clone https://github.com/istio/istio.git istio-operator

$ cd istio-operator

$ git checkout -b tag_1.9.1 tags/1.9.1

 

istio operator 를 helm 으로 설치한다.

istio 는 control plane 을 canary upgrade  가 가능하도록 revision tag 로 구분할 수 있게 권장하고 있다. 그리고 istio-operator 네임스페이스에 operator 를 설치하고, istio-system 네임스페이스에 istio control plane 을 설치한다.

operator 를 생성할 때 istio-operator 네임스페이스는 자동으로 생성되나 istio-system 네임스페이스는 operator 를 설치하기 전에 수동으로 생성해 놓아야 한다.

$ cd ~/ahnsk/istio

$ vi istio-operator-values.yaml

---

revision: "1-9-1"

operatorNamespace: istio-operator

watchedNamespaces: istio-system

operator:

  resources:

    limits:

      cpu: 4

      memory: 4Gi

    requests:

      cpu: 2

      memory: 2Gi

 

$ kubectl create ns istio-system

$ helm upgrade -i istio-operator ./istio-operator/manifests/charts/istio-operator -f istio-operator-values.yaml -n istio-system

 

2. istio control plane 설치

istio control plane 은 istiod 라는 pod 로 설치된다. operator 가 있으므로 아래와 같이 custom resource 를 생성하면 자동으로 istio control plane 이 설치되는 구조이다.

custom resource 를 아래와 같이 생성한다.

$ vi istio-cr-1-9-1.yaml

---

apiVersion: install.istio.io/v1alpha1

kind: IstioOperator

metadata:

  namespace: istio-system

  name: istio-controlplane

spec:

  revision: "1-9-1"

  profile: default

  meshConfig:

    accessLogFile: /dev/stdout

    enableTracing: true

    enablePrometheusMerge: true

    defaultConfig:

      discoveryAddress: istiod-1-9-1.istio-system.svc:15012

      proxyMetadata: {}

      tracing:

        zipkin:

          address: jaeger-operator-jaeger-collector.istio-system:9411

        sampling: 100.0

  values:

    global:

      logging:

        level: "default:info"

      istioNamespace: istio-system

  components:

    pilot:

      k8s:

        env:

        - name: PILOT_TRACE_SAMPLING

          value: "100"

        resources:

          requests:

            cpu: 1000m

            memory: 1024Mi

        hpaSpec:

          maxReplicas: 10

          minReplicas: 2

        nodeSelector:

          taco-istio: enabled

    egressGateways:

    - name: istio-egressgateway

      namespace: istio-system

      enabled: true

      k8s:

        resources:

          requests:

            cpu: 1000m

            memory: 1024Mi

        hpaSpec:

          maxReplicas: 10

          minReplicas: 2

        nodeSelector:

          taco-istio: enabled

    ingressGateways:

    - name: istio-ingressgateway

      namespace: istio-system

      enabled: true

      k8s:

        resources:

          requests:

            cpu: 1000m

            memory: 1024Mi

        hpaSpec:

          maxReplicas: 10

          minReplicas: 2

        nodeSelector:

          taco-istio: enabled

        service:

          type: NodePort

          ports:

          - name: status-port

            port: 15021

            targetPort: 15021

          - name: http2

            port: 80

            targetPort: 8080

            nodePort: 31080

          - name: https

            port: 443

            targetPort: 8443

            nodePort: 30443

          - name: tcp

            port: 31400

            targetPort: 31400

          - name: tls

            port: 15443

            targetPort: 15443

  • revision 은 control plane 을 구별하기 위해서 사용한다.
  • meshConfig 는 istiod 와 envoy proxy 가 서로 연결되는 정보를 나타내며 discoveryAddress 는 control plane 인 istiod 의 service url 을 tracing 은 Jaeger 정보를 저장할 데이터소스 url 이다. 여기서는 jaeger tracing backend 로 elastic search 를 사용하고 있다. meshConfig 의 값은 istiod 가 설치되는 istio-system 네임스페이스에 istiod-1-9-1 이라는 이름의 ConfigMap 으로 저장된다.
  • components 는 pilot(istiod), ingressGateway, egressGateway 에 대한 설치 정보이다. hpa 로 auto scaling 을 활용하기 위해서는 kubernetes cluster 에 metric-server 가 설치되어 있어야 한다.

 

아래와 같이 custom resource 를 생성한다.

사전에 node-selector 로 어느 서버에 istiod 와 gateway 를 설치할 수 있는지 지정할 수 있다.

$ kubectl label node k1-node03 taco-istio=enabled

$ kubectl label node k1-node04 taco-istio=enabled

$ kubectl label node k1-node05 taco-istio=enabled

 

$ kubectl apply -f istio-cr-1-9-1.yaml

 

설치 현황은 아래 명령으로 확인할 수 있다.

$ kubectl get iop -n istio-system

-----------------------------------------------

NAME                   REVISION   STATUS    AGE

istio-controlplane     1-9-1      HEALTHY   44h

 

3. 서비스별 gateway 추가 설치

gateway 는 서비스별로 추가할 수 있다. 이 또한 custom resource 만 생성하면 되며 custom resource 는 아래와 같다.

$ vi istio-gateway-cr.yaml

---

apiVersion: install.istio.io/v1alpha1

kind: IstioOperator

metadata:

  namespace: istio-system

  name: istio-gateway-sample

spec:

  revision: "1-9-1"

  profile: empty

  values:

    global:

      logging:

        level: "default:info"

      istioNamespace: istio-system

  components:

    ingressGateways:

    - name: istio-ingressgateway-istio-gateway-sample

      namespace: istio-gateway-sample

      label:

        app: istio-ingressgateway-istio-gateway-sample

        istio: ingressgateway-istio-gateway-sample

      enabled: true

      k8s:

        resources:

          requests:

            cpu: 1000m

            memory: 1024Mi

        hpaSpec:

          maxReplicas: 10

          minReplicas: 2

        nodeSelector:

          taco-istio: enabled

        service:

          type: NodePort

          ports:

          - name: status-port

            port: 15021

            targetPort: 15021

          - name: http2

            port: 80

            targetPort: 8080

            nodePort: 31081

          - name: https

            port: 443

            targetPort: 8443

            nodePort: 31443

          - name: tcp

            port: 31400

            targetPort: 31400

          - name: tls

            port: 15443

            targetPort: 15443

  • profile 값은 empty 로 지정한다. empty 는 istiod 를 설치하지 않겠다는 뜻이다.
  • Gateway  에 label 은 중요하다. default label 값은 app=istio-ingressgateway 와 istio=ingressgateway 이다. Gateway 를 여러개 설치하면 서비스별로 VirtualService 와 연결해야 하는데 이 때 활용되는 것이 label 이다. 그러니 Gateway 별로 구별할 수 있게 label 을 서로 다르게 주는 것이 중요하다.
  • 새로운 네임스페이스에 생성된 Gateway 에 istiod 와 연결할 url 정보를 주는 것이 중요하다. 그런데 그 정보를 갖고 있는 meshConfig 에 넣어도 새로운 네임스페이스에 istio-1-9-1 ConfigMap 이 생성되지 않는다. 그래서 istio-1-9-1 ConfigMap 은 수동으로 설치해 주어야 한다.

 

Gateway 를 설치할 네임스페이스 생성과 그 네임스페이스에 istio-system 에 있는 istio-1-9-1 ConfigMap 을 복사하여 생성한다.

$ kubectl create ns istio-gateway-sample

 

$ kubectl get cm istio-1-9-1 -n istio-system -o yaml \

| grep -v '^\s*namespace:\s' \

| kubectl apply -f -n istio-gateway-sample -

 

custom resource 를 생성하여 Gateway 를 추가로 설치한다.

$ kubectl apply -f istio-gateway-cr.yaml

 

설치된 정보를 확인한다.

$ kubectl get iop -A

----------------------------------------------------------------

NAMESPACE      NAME                   REVISION   STATUS    AGE

istio-system   istio-controlplane     1-9-1      HEALTHY   45h

istio-system   istio-gateway-sample   1-9-1      HEALTHY   42h

 

 

 

# istioctl proxy-status

-----------------------------------------------------------------

NAME                                                                                CDS        LDS        EDS        RDS          ISTIOD                            VERSION

api-gateway-6f87d9477f-xg5dq.default                                                SYNCED     SYNCED     SYNCED     SYNCED       istiod-1-9-1-58ff56d6f8-dftbh     1.10-alpha.ba8228cc703fa11542c3e97c1702688d072152a1

details-v1-6f769b44-hzj8v.default                                                   SYNCED     SYNCED     SYNCED     SYNCED       istiod-1-9-1-58ff56d6f8-25z28     1.10-alpha.ba8228cc703fa11542c3e97c1702688d072152a1

istio-egressgateway-66cb5c46c7-c9q4b.istio-system                                   SYNCED     SYNCED     SYNCED     NOT SENT     istiod-1-9-1-58ff56d6f8-dftbh     1.10-alpha.f88f93ff2b8172b37c83d6066363d76b4477bd2d

istio-egressgateway-66cb5c46c7-qjrwj.istio-system                                   SYNCED     SYNCED     SYNCED     NOT SENT     istiod-1-9-1-58ff56d6f8-25z28     1.10-alpha.f88f93ff2b8172b37c83d6066363d76b4477bd2d

istio-ingressgateway-684d9c7755-brtsv.istio-system                                  SYNCED     SYNCED     SYNCED     SYNCED       istiod-1-9-1-58ff56d6f8-25z28     1.10-alpha.f88f93ff2b8172b37c83d6066363d76b4477bd2d

istio-ingressgateway-684d9c7755-dvtrd.istio-system                                  SYNCED     SYNCED     SYNCED     SYNCED       istiod-1-9-1-58ff56d6f8-dftbh     1.10-alpha.f88f93ff2b8172b37c83d6066363d76b4477bd2d

istio-ingressgateway-istio-gateway-sample-6d6998fc44-rnfnr.istio-gateway-sample     SYNCED     SYNCED     SYNCED     SYNCED       istiod-1-9-1-58ff56d6f8-dftbh     1.10-alpha.f88f93ff2b8172b37c83d6066363d76b4477bd2d

istio-ingressgateway-istio-gateway-sample-6d6998fc44-twcqp.istio-gateway-sample     SYNCED     SYNCED     SYNCED     SYNCED       istiod-1-9-1-58ff56d

 

4. sidecar auto injection 을 위한 레이블 설정

Istio 를 Operator 를 사용해서 revision 값을 주면 sidecar 를 자동으로 injection 하기 위해서 더이상 istio-injection=enabled 와 같은 Label을 쓰지 않는다. 위에 처럼 label 을 변경줘야 한다. istio-injection=enabled 으로 설명하는 문서들이 있으면 demo 와 같은 simple 한 설치이거나 이전 설치 방법이다.

 

$ kubectl label ns default istio-injection=enabled # 소용없음
$ kubectl label ns default istio.io/rev=1-9-1

 

 

 

Jager 와 kiali 는 다음에...

 

 

 

 

Posted by Kubernetes Korea co-leader seungkyua@gmail.com

댓글을 달아 주세요

  1. BlogIcon 뉴비뉴 2021.03.23 18:22 신고  댓글주소  수정/삭제  댓글쓰기

    $ kubectl get cm istio-1-9-1 -n istio-system -o yaml \
    | grep -v '^\s*namespace:\s' \
    | kubectl apply -f -n istio-gateway-sample -

    마지막 줄 저는 이렇게 해야 동작하네요! kubectl apply -f - -n istio-gateway-sample
    좋은 글 잘 읽었습니다!

마이크로서비스 아키텍처를 공부하다 보면 Circuit Breaker 에 대해서 알게 된다.

여태까지 나는 Circuit Breaker 는 단순히 서비스를 차단해주는 역할을 주라고 생각했는데 그게 아니었음.. ㅠㅠ

 

Circuit Breaker 의 진정한 목적은 Backpressure 를 downstream 에 적용하는 것이라고 할 수 있다. (apply backpressure downstream)

Backpressure 의 의미는 아래 글을 참조..

medium.com/@jayphelps/backpressure-explained-the-flow-of-data-through-software-2350b3e77ce7

 

Backpressure explained — the flow of data through software

Backpressure is something nearly every software engineer will have to deal with at some point, and for some it’s a frequent problem. But…

medium.com

간단히 설명하면 A, B, C 라는 서비스가 각각 D 라는 하나의 서비스를 호출한다고 가정하자. 이 때 D 서비스의 처리량 이상을 A 서비스가 호출한다면, B, C 서비스도 더이상 D 서비스를 호출하여 응답을 받을 수 없다. 그래서 A 서비스가 D를 호출하는 것을 buffer 에 저장하여 잠시 늦추는 효과를 준다면 D 서비스는 이상없이 동작하게 되고 B, C 서비스도 정상적인 응답을 받을 수 있다.

여기서 A서비스에 적용한 것이 Backpressure 이다.

 

Backpressure 를 적용하기 위한 전략은 다음과 같다.

  • Control the producer (slow down/speed up is decided by consumer)
  • Buffer (accumulate incoming data spikes temporarily)
  • Drop (sample a percentage of the incoming data)

오늘 하나 더 배움에 감사하며~~

 

 

 

Posted by Kubernetes Korea co-leader seungkyua@gmail.com

댓글을 달아 주세요

CNCF Project 에 대한 내용을 간략한 아이콘 및 다이어 그램으로 설명한 자료입니다.

웬만한 프로젝트는 모두 보여준 듯 하네요. ^^

 

drive.google.com/file/d/1-uS_jEKakOUxjYKYV1CH3z7CYqOuqrPx/view?usp=sharing

Posted by Kubernetes Korea co-leader seungkyua@gmail.com

댓글을 달아 주세요

KubeCon 2일째 주요 Keynote 내용은 OpenTelemetry, Scalable Kubernetes Cluster, CNCF Tools 입니다.

 

먼저 OpenTelemetry 에서는 아래의 내용들을 이야기 했죠.

 

OpenTelemetry 는 2019년에 발표했는데 OpenCensus 와 OpenTracing 을 합쳤습니다.

OpenTelemetry 가 나온 이유 중 하나는 Vendor lock in 을 피하기 위해서입니다.

 

개념은 아주 간단합니다. Collector 간의 연결입니다.

 

데이터 수집 -> 변경 -> 보내기 형태의 pipeline 구조로 구성됩니다.

 

Collector 가 multiple flow 를 받을 수 있습니다.

 

아래 OpenTelemetry 를 방문하면 더 많은 정보를 얻을 수 있습니다.

 

Scalable Kubernetes Cluster 는 여러 가지 고려 사항을 이야기 했습니다.

15,000 노드 클러스터인 경우에 고려할 사항은 etcd 입니다.

모든 정보가 etcd 에 저장될 텐데 그것을 처리할 수 있는 용량을 항상 고려해야 합니다.

 

apimachinery 도 고려해야 합니다.

많은 리소스들이 저장되어 있는데 이 중에서 리소스를 select 를 할 때 적절하게 조회하고 이를 관리할 수 있는 API 용량이 필요합니다.

 

Networking 부분에서는 돌아다니는 데이터 양을 고려해야 합니다.

Kube-proxy 가 노드마다 떠 있고 endpoint 가 수정될 때 마다 이를 api 서버로 보냅니다. 예를 들어 5000개의 서비스 pod 가 떠 있다면 1M 정도의 데이터 양을 보내는데 노드가 5000개 있다면 보내는 데이터 양은 5G 나 됩니다.

이를 해결하기 위해서 endpoint slicing 을 사용합니다.

 

Secret 과 ConfigMap 이 pod 가 생성되는 로컬에 저장되는 스토리지도 고려해야 합니다.

 

 

 

 

 

Posted by Kubernetes Korea co-leader seungkyua@gmail.com

댓글을 달아 주세요

Contour, A High Performance Multitenant Ingress Controller for Kubernetes - MICHAEL MICHAEL, Steve Sloka, Nick Young, & James Peach, VMware

Kubernetes 에서 north-south 네트워크로 Ingress Controller 는 필수 입니다.

대부분은 Nginx Ingress Controller 를 사용할 텐데 CNCF Incubating Project 로 Contour 를 사용할 수 있습니다.

Contour 는 Envoy 를 중심으로 개발되었네요.

 

Craig 가 구글에서 나와서 만든 Heptio 에서 시작한 프로젝트인데 지금은 bitnami 가 지원하고 있는 것 같습니다.

 

 

아키텍처는 다음과 같습니다.

 

 

세부적인 내용은 https://projectcontour.io/ 를 확인하세요.

소스 Contributing 은 https://github.com/bitnami/charts/tree/master/bitnami/contour  이곳입니다. ^^

 

20201119_0500 Contour, A High Performance Multitenant Ingress Controller for Kubernetes - MICHAEL MICHAEL, Steve Sloka, Nick Young, & James Peach, VMware.pptx
4.24MB



Posted by Kubernetes Korea co-leader seungkyua@gmail.com

댓글을 달아 주세요

1. Diversity-Powered Reilience - Priyanka Sharma

Cloud Native Network Functions (CNF) Working Group Kick off

 

2. Keynote: Are Certifications Worth It? - Cheryl Hung

Certified Kubernetes Security Specialist 신규

 

3. The Cloud Native Journey @Apple - Alena Prokharchyk, Software Engineer, Apple

Apple  에서 Mesos -> Kubernetes 로 옮겨온 이유

애플에서 사용한 CNCF 프로젝트

현재 개발 우선순위

조직 변화

배운 내용

 

 

 

 

 

 

 

Posted by Kubernetes Korea co-leader seungkyua@gmail.com

댓글을 달아 주세요

AWS 기반으로 CodeCommit 과 연동하여 개발을 하다보면 Windows 기반의 Eclipse 연동을 주로 사용합니다.

AWS 에서 IntelliJ 가 아닌 Eclipse plugin 을 사용하라고 가이드 하는 것은 아마도 Eclipse 가 오픈소스 IDE 툴 이기 때문에 aws plugin 을 만들어서 배포하기데 적절하기 때문이 아닌가 하고 생각이 드네요.

저는 Mac 기반의 Eclipse 를 사용하는데 AWS CodeCommit 과 연동시키는데 몇시간을 고생해서 해결한 내용을 설명하고자 합니다.

Eclipse 를 설치하기 전에 먼저 JDK 가 설치되어야 하는데, 이전 글에서 Mac 에 JDK 를 설치하는 것은 설명을 드렸습니다.

다음으로 Eclipse 설치는 그냥 Applications 아이콘에 복사만 하면 되므로 Eclipse 설치는 생략...

 

Eclipse 에서 AWS toolkt 설치는 "메뉴 >> Help >> Install New Software..." 창을 띄우고 "Work with" 레이블이 있는 Text 상자에  "https://aws.amazon.com/eclipse/site.xml" 를 입력해서 software 를 설치하면 됩니다.

 

 

AWS CodeCommit 을 사용하기 위해서는 "IAM >> Users" 의 Security Credentials 탭에서 "HTTPS Git credentials for AWS CodeCommit" 항목에 사용자를 등록하면 사용할 수 있습니다.

 

 

그리고 AWS CodeStar 에서 Project 를 하나 만들면, CodeCommit Repository 가 생성이 되고,  이 Project 의 Team 메뉴에 위의 IAM User 를 할당해 주면 해당 User 가 CodeCommit 을 사용할 수 있습니다. 

 

이제 Eclipse 의 주황색 아이콘을 클릭해서 CodeCommit 의 repository 로 부터 소스를 받아오겠습니다.

 

AWS Access Key ID, Secret Access Key 를 넣고 region 을 선택합니다. 그리고 CodeCommit 의 git id 와 패스워드를 입력하면 소스를 다운받을 수 있습니다.

 

하지만 다운을 받다가 에러가 발생하면서 실패하게 됩니다.

이 부분에서 고생을 많이 했었는데..

 

1. 처음에는 Oracle Java 에서 나는 문제로 오해해서 Mac 에 OpenJDK 를 설치했습니다. 그리고 Eclipse 를 띄울 때 OpenJDK 를 사용할 수 있게 수정했습니다.

그래도 똑같은 에러가 발생했습니다.

2. 그래서 JGit 의 버그로 생각하고 5.9 버전에서 낮은 버전으로 다시 설치했습니다.

그래도 에러가 발생.

3. IAM User 에서 https git credential 을 지우고 다시 생성하면 된다고 구글리에 나와 있어서 다시 했지만 또 에러.

마지막으로 아래 부분을 적용했더니 해결.

4. Eclipse "Preferences > General > Security > Secure Storage" 에서 OS X keystore 연동 체크박스를 해제

 

결국은 Mac 에서 keychain 연동할 때 eclipse 의 security storage 와의 이슈 때문이었습니다.

별거 아니지만 계속 고생할 수 있는 분들이 있을 거 같아 기록으로 남겨 봅니다. ^^

 

 

 

 

 

Posted by Kubernetes Korea co-leader seungkyua@gmail.com

댓글을 달아 주세요

어제 AWS VPC 네트워크의 개념에 대해서 배워서 정리해 봤습니다.

저는 OpenStack 을 오랫동안 해왔기 때문에 OpenStack 의 Neutron 로 비교하면 이해가 더 쉽게 되더라고요.

 

 

먼저 네트워크 대역을 만들기 위해서는 VPC 가 필요합니다. virtual 하게 만드는 것이기 때문에 10.0.0.0/16 과 같이 사설망 대역을 사용합니다.

그리고 외부와의 통신을 위해서는 Internet gateway (IGW)를 생성합니다. 이것은 software gateway 라고 생각이 들고 여기까지는 VPC 와 상관이 없습니다. 그래서 이해하기 쉽게 IGW 를 VPC 바깥에 그렸습니다.

IGW 를 VPC 와 연결 (associate) 하는 순간에 port 가 생성되어 연결될 것으로 보입니다.

 

VPC 내에는 subnet 을 만들어 Network 대역을 다시 나눌 수 있는데 subent 은 10.0.0.0/24 처럼 VPC 대역 내여야 하고, 하나의 subent 은 AZ 의 하나에만 할당될 수 있습니다. AZ 내에 하나만 할 당 할 수 있는 이유는 EC2 VM 을 만들면 VPC 내의 Subnet 을 선택하고, VM에 ip 를 할당하면서 해당 IP 에 대해서 s/w 적으로 연결이 될텐데 여러 AZ 에 대역이 펼쳐져 있으면 통신이 꼬일 수 밖에 없습니다.

그러므로 실제로 중요한 것은 VPC 라기 보다는 Subnet 입니다. Subnet 의 정보를 가지고 다 처리를 하는데 다만 통합적으로 관리할려고 VPC 라는 개념을 가져온 것 뿐입니다. 

 

Subnet 은 라우팅을 잡아야 하는데, 내부적으로는 VM 을 관리하는 Baremetal Host 서버에 라우팅을 세팅하기 위한 방법이 필요합니다. (혹은 Baremetal 에 떠 있는 software network switch 에서 라우팅을 세팅)

그래서 라우팅 테이블을 만들고 Subnet 에 연결(assocation) 해주면 그 라우팅 정보를 가지고 있다가 VM 이 생성될 때 세팅을 해줄 수 있습니다.

 

정리해보면 다음과 같습니다.

1. IGW 는 VPC 에 attach 하는 부분이 필요하다. (router 에서 인터넷으로 가는 GW port 를 연결하는 작업)

2. Route table 을 Subnet 에 association 하는 부분이 필요하다 ( VM 이 생성될 때 통신될 수 있도록 라우팅을 세팅해야 하므로 해당 정보를 이용)

 

AWS 가 내부적으로 어떻게 구성되어 있는 지는 모르겠습니다. 하지만 OpenStack Neutron 을 보면 저런 방법을 사용하고 있기 때문에 아마도 동작 방식은 비슷하지 않을까 생각합니다.

 

  

Posted by Kubernetes Korea co-leader seungkyua@gmail.com

댓글을 달아 주세요