• 해외주식으로 돈을 벌었으면 직접 세금 신고를 해야한다.
  • 양도차익 : 주식을 팔았을때 생긴 이익
    • 국내에서는 따로 양도차익 금액을 내지 않음
    • 만약 하나의 종목으로 300만원을 벌고 다른 종목으로 200만원을 잃으면 100만원 차익이니 안내도 됨
    • 세금을 줄이려면 손실이 있는것을 그냥 팔아버리고 다시 산다.
    • 만약 장기투자를 하면 팔고 다시 산다.
  • 배당수익 : 배당을 통해 받은 이익
    • 국내에서는 배당수익에 대해 15% 정도를 내는데, 따로 세금신고를 안해도 됨

• 3D를 2D로 만드는 기술 중 하나
• 가장 대중방법중 하나로, 다른 방법으로는 ray tracing 방식이 있다.
• rasterization은 존재하는 모든 오브젝트에 좌표를 할당한다
• 픽셀, 또는 비트맵으로 만든다고도 볼 수 있다.
• 특정 픽셀이 해당되냐 아니냐를 외적등의 계산으로 구한다.

• 참고 : 3D 가 만들어지는 방법
  • 3D는 (x,y,z) 로 이루어진 점 3개로 이루어짐
    • 실제로는 vertex(좌표) 와 index(좌표 인덱스 3개 모음)으로 이루어짐
    • 점 3개, 즉 삼각형의 모임이 3D 모형이 됨

쿠버네티스 서비스란

• 쿠버네티스 네트워크이다.
• api 서비스이다.
• service는 쿠버네티스에 동일한 레이블을 가진 파드들을 하나의 ip로 묶어서 관리를 요청한다.
  • 쿠버네티스는 동일한 레이블을 갖고 있는 pod를 하나의 virtual ip로 묶는다.
  • virtual ip는 로드밸런스 ip가 된다.
  • 즉 이러한것이 만들어지도록 요청하는것이 쿠버네티스 서비스이다.

서바스 타입

• cluster ip

  • 기본 cluspte의 역할로 로드밸런서 ip를 만듦

  • 예제

    kind: Service
    metadata:
    name: ${name}
    spec:
    type: ClusterIP
    clusterIP: ${ip}
    selector:
    app: ${app}
    ports:
    - protocol: TCP
    port: ${virtual ip port}
    targetPort: ${pod port}

• node port

  • cluster ip 기능에 추가로 포트까지 지원함

  • 즉 로드밸런서 ip에 포트까지 붙일 수 있도록 지원

  • 외부에서 들어올수 있는 노드의 포트가 열림

  • 워커 노드가 1,2,3이 있고 각각에 pod가 하나씩 있을때

    • 2번 워커노드의 열린 포트로 클라이언트가 요청을 하면

    • 해당 워커노드가 로드밸런싱을 하여 1,2,3번의 내부 pod 중 하나로 요청을 보내준다.

      kind: Service
      metadata:
      name: ${name}
      spec:
      type: NodePort
      clusterIP: ${ip}
      selector:
      app: ${app}
      ports:
      - protocol: TCP
      port: ${virtual ip port}
      targetPort: ${pod port}
      nodePort : ${node port}

• loadbalaner

  • 클러스터 Ip 에 추가로 실제 로드밸런서 장비의 포트와 virtual 로드밸런서 포트를 연결
  • 물리 로드밸런서가 node port 로 요청을 전달

• external Name

  • 네이밍 서비스를 만든다.
  • dns 서비스를 클러스터 내부안에서 지원해준다.
  • 보통 외부 서버로 요청을 연결하는 경우에 사용한다.

• 확인해보기

  • ip : lb ip
  • endpoints : 실제 연결되는 ip

• kubectl describe svc clusterip-service

• 서바스 중단

• kubectl delete service -all

헤드리스 서비스

• clusterip가 없는 서비스로 단일 진입점이 따로 필요 없을때 사용됨
• 하지만 endpoint로는 묶어줌
• pod들의 endpoint를 dns resolving service 쓸 수 있도록 함
• 즉 pod하나하나에 대한 dns를 core dns에 등록하여 각각 쓸 수 있음

  apiVersion: v1
  kind: Service
  metadata:
  name: ${name}
  spec:
  type: ClusterIP
  clusterIP: None #이부분으로 사실상 헤드리스 서비스 명시!

  ###kube-procy
• 쿠버네티스의 백엔드를 구현
• 즉 clusert ip를 쓰면, 실제로는 실제 각 노드별로 iptables가 있어서, 이게 요청을 받으면 각 내부 pod중 한개로 전달하는 방식이다.
• 그래서 실제 노드에서 iptables확인해보면 iptables가 찍힌다.
• node port를 쓰는 경우 해당 포트를 리슨함

• 여러대의 control plane으로 구성
• 세대중에 한대가 다운되더라도 운영 가능(고 가용성)
• 보통 홀수로 이용
• 로드밸런서가 control plane을 선택하여 요청을 보냄(즉 worker노드가 마스터로 무언갈 보낼때 로드밸런서를 통해 감)
• 여러대의 conrol plane 간에는 동기회를 진행
• nginx로 로드밸런싱을 하는경우 upstream stream_backend를 이용

job

• job controller
  • 보통 다른 컨트롤러들은 pod를 죽이면 계속 수행됨
  • 하지만 pod가 기능 수행을 완료하면 굳이 계속 수행될 필요가 없을 수 있음
  • 기능이 수행되면 상태가 completed가 된다. 따로 지우지는 않는다.
  • pod가 삭제되면 내부 로그를 알 수 없기 때문에 따로 지우지는 않는다.
  • restartPolicy 설정을 통해 실패시 사용할 정책을 지정할 수있다.
  • backoffLimit으로 restartPolicy 보조
  • replicas대신 completions을 사용, 다만 컨테이너 수가 아니라 실행 횟수임
  • 유지갯수는 parallelism으로 설정

cronjob

• job을 제어하여 작업예약을 지원한다
• crontab이랑 비슷함
• 사실상 job definition에 schedule만 추가한다

• pod의 상태를 유지해주는 컨트롤러

  • pod의 이름 보장
    • 기존에 다른 컨트롤러를 쓰면 ${pod_name}-${hash} 로 생성됨
    • StatefulSet은 이와 다르게 이름을 보장함
    • ${pod_name}-1,${pod_name}-2,${pod_name}-3 이렇게 만들 수 있음
    • 만약 2가 삭제되면 2를 생성함, 즉 이름의 형태는 전체적으로 보장이 된다.

• scale statefulset 으로 replicas를 조정할 수 있다.

  kubectl scale statefulset ${} --replicas=${}

• scale out을 하는경우 0,1,2,3 이면 3,2,1,0 순으로 삭제된다.

• rollingupdate 가능

  kubectl edit statefulsets.apps ${}

• roolout 가능

  kubectl rollout undo statefulset ${}

• 노드에서 pod가 한개씩 실행되도록 보장

• 노드에서 pod가 하나씩 실행되는 경우는 각 노드의 물리장비를 모니터링하는 경우등에 사용됨

• daemonset은 replicas를 따로 지정하지 않아도 자동으로 node당 하나씩 수행된다.

• daemonset은 rolling update 가능하다.

• daemonset 로그 확인

  kubectl get daemonsets.apps

• daemonset 수정

  • 하나를 완료하고 완료되면 다른 pod를 완료하고 ... 이런식으로 롤링 업데이트

    kubectl edit daemonsets.apps ${pod-name}

• 롤백

  kubectl rollout undo daemonset ${pod}

• Replicaset의 부모로 Replicaset 을 제어, Replicaset은 pod를 제어
• 롤링 업데이트를 위해 만들어줌
  • 서비스 중단없이 업데이트를 이룸
• 사용할때 kind를 Replicaset,Deployment 둘중 하나를 사용한것 외에는 크게 달라지는 점은 없다.
• 롤링업데이트 방법

kubectl set image deployment <deploy_name> <container_name>=<new_versiong_image>
kubectl set image deployment <deploy_name> <container_name>=<new_versiong_image> -- record

• 롤백

kubectl rollout undo deploy  
kubectl rollout history deployment

• 만약 3개짜리 pod를 쓰고 있는데 update를 하면 1개의 pod를 업데이트(그동안 2개가 서비스), 그다음 2개의 pod를 업데이트,,,전부 업데이트,,, 이런식으로 된다
• 업데이트 기록 로그 확인(yaml파일의 spec의 revisionHistoryLimit 갯수로 기록 로그 저장 갯수 제한 가능)
  • rollout의 resume , pause등을 통해 업데이트를 중단하고 재개할 수 있다.
  • undo 명령어를 통해 이전 버전으로 돌아갈 수 있다.
  • to-revision 명령어로 특정 버전을 찍고 돌아갈 수 있다.
• kubectl rollout history deploymen ${name} deployment.apps/${name} REVISION CHANGE-CAUSE 1
• 업데이트 기록이 나오게 하려면 생성할때 --record를 쓴다

kubectl create -f ${name} --record

deployment.apps/${name} created

kubectl rollout history deployment ${name}

deployment.apps/${name}  
REVISION CHANGE-CAUSE  
1 kubectl create --filename= ${name} --record=true

• spec의 rolling update

spec:  
progressDeadlineSeconds: 100  
revisionHistoryLimit: 10  
strategy:  
rollingUpdate:  
maxSurge: 25%  
maxUnavailable: 25%  
type: RollingUpdate  
replicas: 3

• 이렇게 된 경우 3(레플리카 갯수)*0.25 = 0.75, 반올림하여 1인데,
• 그러면 3개중에 1개의 여유를 업데이트 할 때 갖을 수 있다.
• 그러면 3개(업데이트 안됨)+1(업데이트 됨)=>2개+2개=>1개+3개=>3개 이런식으로 업뎃이 진행된다
• kubectl apply -f 명령어를 이용해 업데이트를 진행할 수 있다.