sejong.jeonjo@gmail.com

IT 개발자, 운영자는 처음부터 Kubernetes, Helm, Istio 등 Cloud와 관련된 어휘를 IT 용어로 받아들였기 때문에 이 어휘의 어원이 무엇인지 잘 모를 것이다.

대부분 그리스어(Greek)에서 온 어휘이고, 바다 또는 배와 관련된 것이 많다.

Kubernetes

뜻은 키잡이, 조타수(Steerman, Helmsman)이고, 그리스어에서 온 어휘이다.

(내가 그리스어를 몰라서, 정확히 이것인지는 모르겠지만 "πηδαλιούχος"가 그나마 어감이 비슷하다)

Helm

뜻은 조타 장치.

Istio (ιστιο)

원래 그리스어이고, 그리스어 식 표기는 "ιστιο"이다.

Istio 뜻은 '항해, 돛'이다.

ιστιο에 대한 발음은 아래 링크를 클릭하면 들을 수 있다.

Quay

배를 정박시킬 수 있는 부두, 선착장.

Docker

부두(Dock)에서 일하는 사람. 항만(Dock) 노동자.

Istio를 사용해서 Pod간 Traffic을 제어하다보면, 특정 Pod의 특정 TCP Port는 Proxy 처리에서 제외(Exclude)시키고 싶을 때가 있다.

(즉, Istio Enovy Proxy Container를 경유하지 않고, 바로 다른 연동할 Pod로 TCP Traffic을 보낸다는 뜻)

아마, 대부분 HTTP가 아닌 회사 내부에서 자체적으로 Protocol을 정해놓고 연동하는 Traffic 들이 대부분일 듯.

또는 NATS, Kafka 같은 Message Broker와 연동하는 경우에도 굳이 Service Mesh를 사용할 일이 없다.

왜냐하면 NATS, Kafka는 원래 메시지 분산 처리를 할 수 있도록 설계되어 있으니까 굳이 Istio의 제어를 받지 않아도 된다.

만약, TCP Port 50001를 사용하는 TCP Traffic을 Istio Envoy Proxy를 경유하지 않고, Main App Container (A)에서 바로 다른  Main App Container(B)에게 보내려면 아래와 같이 Pod에 Exclude Annotation을 설정한다.

apiVersion: apps/v1
kind: StatefulSet   ## or Deployment
metadata:
  name: myapp

... 중간 생략 ...

spec:
  template:
    metadata:
      annotations:
        sidecar.istio.io/inject: "true"
        traffic.sidecar.istio.io/excludeInboundPorts: "34432,50001,50002,50003,50100,50102,50103,50200,50201,50203,50300,50301,50302"
        traffic.sidecar.istio.io/excludeOutboundPorts: "34432,50001,50002,50003,50100,50102,50103,50200,50201,50203,50300,50301,50302"

Multiple Control Plane Diagram / In Place Upgrade from v1 to v2

Istio traffic management

Sidecar Injection and iptables,  traffic hijacking process in Istio

Envoy xDS Protocol

Simple Control Plane 구현 Example 

https://github.com/alicek106/envoy-eds-flask-demo

가끔 kubernetes에서 istio를 사용하다보면, Pod 내부의 iptables 구성 상태가 어떠한지 궁금할 때가 있다.

매번 여기저기 명령 찾아서 짜집기하고 있었는데, 이렇게 하니까 찾는 시간도 오래 걸리고, 나의 기억도 오래가지 않아서 여기에 메모를 하고 필요할 때마다 아래 명령을 copy & paste 해야겠다.

(이 명령은 Istio README.md에도 있으니까, 좀더 깊게 볼려면 Istio README.md에서 찾아보길~)

##
## pod의 container id 확인하기
##

$ ns=ns-a

$ podnm=ratings-v1-587d5cfb9-mxhxc

$ container_id=$(kubectl get pod -n ${ns} ${podnm} -o jsonpath="{.status.containerStatuses[?(@.name=='istio-proxy')].containerID}" | sed -n 's/docker:\/\/\(.*\)/\1/p')

$ echo $container_id
6dbeeb047da9149f0735943cd95885a156dbdc766b48145c40e7346ea7f6bcfb


##
## 어떤 worker node에서 ratings-v1 pod가 구동되어 있는지 확인하기
##

$ kubectl get -n ns-a pod -l app=ratings -o wide
NAME                         READY   STATUS    RESTARTS   AGE     IP               NODE      NOMINATED NODE   READINESS GATES
ratings-v1-587d5cfb9-mxhxc   2/2     Running   0          2d17h   10.244.91.198    node-73   <none>           <none>
ratings-v1-587d5cfb9-s6g6r   2/2     Running   0          2d17h   10.244.142.131   node-75   <none>           <none>


##
## ratings-v1 pod가 구동된 worker node에 ssh 접속하기
##

$ ssh root@node-73

##
## NOTE: worker node에 접속했으면, 위에서 알아냈던 container_id를 아래와 같이 설정하고
##       아래 명령 순서대로 실행한다.
##

[root@node-73 ~]$ container_id=6dbeeb047da9149f0735943cd95885a156dbdc766b48145c40e7346ea7f6bcfb

[root@node-73 ~]$ cpid=$(docker inspect --format '{{ .State.Pid }}' $container_id)


##
## Worker Node의 nsenter 명령을 이용하여 Container 내부의 iptables 정보를 조회한다.
##
[root@node-73 ~]$ nsenter -t $cpid -n iptables -L -t nat -n -v --line-numbers -x

Chain PREROUTING (policy ACCEPT 118222 packets, 7093320 bytes)
num      pkts      bytes target     prot opt in     out     source               destination
1      118224  7093440 ISTIO_INBOUND  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain INPUT (policy ACCEPT 118224 packets, 7093440 bytes)
num      pkts      bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 10650 packets, 924376 bytes)
num      pkts      bytes target     prot opt in     out     source               destination
1         400    24000 ISTIO_OUTPUT  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain POSTROUTING (policy ACCEPT 10650 packets, 924376 bytes)
num      pkts      bytes target     prot opt in     out     source               destination

Chain ISTIO_INBOUND (1 references)
num      pkts      bytes target     prot opt in     out     source               destination
1           0        0 RETURN     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:15008
2           0        0 RETURN     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22
3           0        0 RETURN     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:15090
4      118222  7093320 RETURN     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:15021
5           0        0 RETURN     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:15020
6           2      120 ISTIO_IN_REDIRECT  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain ISTIO_IN_REDIRECT (3 references)
num      pkts      bytes target     prot opt in     out     source               destination
1           2      120 REDIRECT   tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            redir ports 15006

Chain ISTIO_OUTPUT (1 references)
num      pkts      bytes target     prot opt in     out     source               destination
1           3      180 RETURN     all  --  *      lo      127.0.0.6            0.0.0.0/0
2           0        0 ISTIO_IN_REDIRECT  all  --  *      lo      0.0.0.0/0           !127.0.0.1            owner UID match 1337
3           0        0 RETURN     all  --  *      lo      0.0.0.0/0            0.0.0.0/0            ! owner UID match 1337
4         397    23820 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0            owner UID match 1337
5           0        0 ISTIO_IN_REDIRECT  all  --  *      lo      0.0.0.0/0           !127.0.0.1            owner GID match 1337
6           0        0 RETURN     all  --  *      lo      0.0.0.0/0            0.0.0.0/0            ! owner GID match 1337
7           0        0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0            owner GID match 1337
8           0        0 RETURN     all  --  *      *       0.0.0.0/0            127.0.0.1
9           0        0 ISTIO_REDIRECT  all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain ISTIO_REDIRECT (1 references)
num      pkts      bytes target     prot opt in     out     source               destination
1           0        0 REDIRECT   tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            redir ports 15001

[root@node-73 ~]$

위 iptables 구성에 관한 이론 및 개념 설명은 아래 blog를 참고하길~

아래의 글이 쉽게 설명되어 있다. 시간될 때, 다시 꼼꼼하게 읽어봐야겠다.

참고: istio v1.2  kubernetes v1.14로 테스트한 과정이 설명되어 있다.

http://itnp.kr/post/istio-circuit-break

들어가는 글

Istio를 설치할 때, 다양한 설치 방법이 있다. 그래서 Istio를 처음 접할 때, 다양할 설치 방법 때문에 무엇부터 시작해야 할지 망설이게 된다. 이런 고민을 조금이라도 덜기 위해 각 설치 방법의 장점과 단점을 알아보고자 한다.

우선, 가장 흔하게 사용하는 Istio 설치 방법은 아래의 4가지가 있다.

• istioctl install     <-- 내가 생각하는 Best Choice
• istio operator
• istioctl manifest generate
• helm chart

각 설치 방법의 특징과 장점 및 단점은 아래와 같다.

istioctl install

`istioctl` 명령 도구를 사용하여 istio를 설치하는 것이 가장 보편적인 설치 방법이다. 그리고 'istio dev community`에서 이 설치 방법을 권장하고 있다.

Pros:

• `istioctl` 명령 도구가 설정 오류에 대한 확인을 해준다.
• `istioctl` 명령 도구가 'IstioOperator' API를 사용한다.
• 'In-cluster privileged pods'가 필요하지 않다. `istioctl` 명령 도구를 이용해서 설정 변경이 필요할 때마다 설정을 적용해준다.

Cons:

• 다른 설치 방식에 비해서 `istioctl` 명령 도구 프로그램의 버전을 실제 istio의 버전과 맞추어줘야 하는 일이 필요하다. 

istio operator

Pros:

• `istioctl` 같은 별도의 명령 도구 프로그램이 없이, kubernetes의 Operator 패턴을 이용하면 된다.

Cons:

• 'Istio Operator'가 istio가 설치되는 kubernetes cluster 내부에 있어야 하고, 상당히 높은 cluster management 권한을 가지게 되므로, 자칫하면 보안(security)가 허술해지는 실수를 범할 수 있다.

istioctl manifest generate

나처럼 Istio 자체를 분석하려는 사람이 쓰는 방법이지 않을까 싶다. Kubernetes와 Istio를 많이 아는 사람이 아니라면, 이 방법은 복잡하게 느껴질 수 있을 것이다. Kubernetes와 Istio를 파헤치고 배우는 학생이라면 한번쯤 시도해볼만한 설치 방법이다. (나의 개인적인 느낌으로 하는 말이다 ^^)

어짜피 istioctl이나 istio operator도 원본 Application의 Pod manifest를 hooking하여 istio에 필요한 설정 항목을 Patch하는 것이기 때문에, Istio 및 app이 구동하는 과정을 동일한 흐름일 것이다.

Pros:

• `istioctl`이 생성한 chart를 사람이 직접 열람할 수 있다.

Cons:

• chart, manifest를 직접 이용하는 방식이기 때문에 `istioctl`의 설정 검증 같은 절차가 없다.
• 초보자가 사용하기에 절차가 복잡하다.
• Error reporting이 허술하다.

Helm chart

개인적인 생각에 helm chart에 익숙한 사용자라면 써볼만한 설치 방식이지만, 설정 validation이 허술해서 권장할 만한 설치 방법은 아닌 듯 하다.

결론

개발자가 Istio를 스터디하고, 분석해야 하는 상황이 아니라면 `istioctl` 명령 도구를 이용하여 istio를 설치하고 관리하는 것이 좋다.
아래 Web Docs를 따라하는 것이 Best Choice 라고 생각한다.

https://istio.io/latest/docs/setup/install/istioctl/

위 Web Docs가 너무 길어서 다 읽고, 따라하기 귀찮다면, 아래 2개의 명령만 수행해보길~~~

## Istio Controller 설치 및 Ingress, Egress Gateway까지 한번에 설치하려면, 아래 명령을 수행
$ istioctl install --set profile=demo

## Test가 끝나고,  Istio 관련 모든 Kubernetes Resource를 삭제하려면, 아래 명령을 수행
$ istioctl x uninstall --purge

만약, Istio를 포함해서 Example App이 실제로 돌아가는 것까지 테스트하고 싶다면 아래 Web Docs를 따라하는 것이 좋다.

https://istio.io/latest/docs/setup/getting-started/