Terraform은 backend에 대한 추가적인 설정이 없다면 기본적으로 실행 디렉토리 내에 terraform.tfstate 파일을 생성한다. 그러나, Terragrunt는 backend를 따로 설정해주지 않으면 local에 tfstate파일을 생성해주지 않는다.

If Terraform has no explicit backend configuration, it creates terraform.tfstate in live directory by default. However, Terragrunt doesn't.

tfstate 파일이 없으면 생기는 일

사실 tfstate 파일이 없어도 terragrunt apply로 리소스 생성이 가능하고, terragrunt destroy로 리소스 삭제가 가능하다.

그럼 무엇이 문제냐, apply 명령으로 리소스를 생성하다 중간에 실패하였을 때, 문제 수정 후 다시 apply 명령으로 리소스를 생성하면 중간에 생성 실패한 리소스부터 다시 생성을 시도하는 것이 아닌, 처음부터 이미 생성한 리소스부터 다시 생성하게 된다.

이는, terraform으로 만든 리소스에 대한 상태를 저장한 파일이 없기 때문에, terraform 입장에선 리소스가 존재하지 않는 것처럼 여겨지기 때문이다. (이것이 tfstate 파일의 존재의 이유이다.)

보통 production 환경에선 remote state 설정을 통해 tfstate 파일을 원격의 안전한 저장소(ex.s3 bucket)에 저장하도록 설정하는 것이 일반적이다. 그러나 이는 terragrunt docs에도 잘 나와있고, 여기선 해당 파일을 local에 저장시킬 수 있는 방법을 소개하겠다.

The thing is even though tfstate file does not exist, we can create/destroy resources using apply/destroy command.

But let's say we failed to run apply command in the middle of creating resources. For example, terraform succeed to create ec2 instance, but failed in security group. After fixing it and run apply command again, we expect it to create resource from where it failed to create. This case, from security group. But, terraform will create resource from the first again, from ec2 instance. Why? Because tfstate file stores the 'state' of resources created by terraform, without it, resources does not exist in the stance of terrform. This is why state file is so important to terraform.

Terragrunt local backend 설정

terragrunt 실행 디렉토리 내에 tfstate 파일을 생성해보겠다. 실습 terragrunt 디렉토리 구조는 다음과 같다.

# config
dev
  │  common.yaml
  │  terragrunt.hcl
  │
  └─ec2
      ├─bastion
      │      terragrunt.hcl
      │
      └─tomcat
              terragrunt.hcl

# template
aws
  └─ec2
         ec2.tf
         iam.tf
         main.tf
         output.tf
         security_group.tf
         variables.tf

root terragrunt.hcl인 dev/terragrunt.hcl 에 아래 내용을 추가한다.

remote_state {
  backend = "local"
  config = {
    path = "${get_terragrunt_dir()}/terraform.tfstate"
  }
}

참고: https://terragrunt.gruntwork.io/docs/reference/built-in-functions/#get_terragrunt_dir

그리고 실제로 리소스를 만드는 template의 모듈별 main.tf에 아래 내용을 추가하면 끝이다.

terraform {
  backend "local" {}
}

terragrunt plan - terragrunt apply 후에 다음과 같이 tfstate 파일이 생성되는 것을 확인할 수 있다. 각자의 상황에 맞춰 path를 바꿔주면 된다.

끝!

ELk의 Index Pattern을 수정 후 기존 visualize에서 다음과 같은 에러가 발생했다.

The index pattern associated with this object no longer exists.

당연히 새로운 Index를 생성했기 때문에 기존 Index id만을 바라보고 있던 시각화에서 에러가 발생한 것이다.

해결

해결 방법은 새로운 Index id로 수정해주면 된다.

1. Stack Management > Kibana > Index Pattern 에서 해당 index 패턴 클릭 링크의 주소에 맨 뒤에 붙어있는 id를 확인
2. 시각화 에러 페이지 맨 아레 references 부분에서 type이 index-pattern인 id의 값을 바꿔주면 된다.

방법은 아래 링크를 참조할 것!

https://discuss.elastic.co/t/visualizations-broken-after-deleting-index-pattern-resolved-the-index-pattern-associated-with-this-object-no-longer-exists/181452

iam role과 assume role에 대한 이해를 의식의 흐름대로 정리했음...🧐🥺 틀릴 수 있음 주의!

IAM Role이란

• 여러 policy와 연결함으로써 권한을 가질 수 있다.
• 여러 객체에게 부여할 수 있다.
• 한 사람만이 user을 사용할 수 있는것과 달리
• role은 필요로 하는 이는 누구나 사용 가능
• 단, 신뢰할 수 있는 사람만!

Assume Role

예제 1

예를 들면, EC2에 S3를 조회하는 Role을 부여한다고 해보자. role 정의 부분을 terraform 코드로 보면 다음과 같다.

resource "aws_iam_instance_profile" "bastion" {
  name = "iam-${local.name}-instance-profile"
  role = aws_iam_role.bastion.name
}

resource "aws_iam_role" "bastion" {
  name               = "iam-${local.name}-role"
  path               = "/ec2/"
  assume_role_policy = <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": "sts:AssumeRole",
      "Principal": {
        "Service": ["ec2.amazonaws.com"]
      },
      "Effect": "Allow"
    }
  ]
}
EOF
}

data "aws_iam_policy_document" "bastion" {
  statement {
    sid = "ReadBucket"

    actions = [
      "s3:Get*",
      "s3:List*",
    ]

    resources = [
      "arn:aws:s3:::jisun-*",
    ]
  }
}

resource "aws_iam_policy" "bastion" {
  name   = "iam-${local.name}-s3"
  path   = "/ec2/"
  policy = data.aws_iam_policy_document.bastion.json
}

resource "aws_iam_role_policy_attachment" "bastion" {
  role       = aws_iam_role.bastion.id
  policy_arn = aws_iam_policy.bastion.arn
}

policy를 정의하고 이를 role에 붙이는 부분은 딱 알 수 있을 것이다. 그렇다면, assume_role_policy 부분의 정의는 무엇일까?

이 부분이 바로 해당 role을 사용할 수 있는 대상을 지정하는 부분이다. aws console상에선 trusted entities에서 확인할 수 있다.

Principal이 assume role이 allow 된다. 즉, EC2 리소스가 이 role을 사용할 수 있게 된 것이다.

그러면 EC2는 이 role에 대한 권한을 위임받아서 role과 연결된 policy에 대한 권한, 즉 s3를 list하고 get할 수 있는 권한을 얻게 된다.

예제2

A user에 assume role 정의 B role에 s3 list 권한 부여

A는 B의 권한을 위임받아서 s3 list를 할 수 있음

너무 좋은 사이트..!: https://jonnung.dev/posts/2021-01-28-aws-iam-role/

Pod가 특정 Node에만 schedule될 수 있게 하는 것 ** 그러나 multi label이라던지 복잡한 selector은 불가능

pod-definition.yml

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
spec:
  containers:
  - name: data-processor
    image: data-processor
  nodeSelector:
    size: Large

kubectl label nodes <node-name> <label-key>=<label-value>

Node Affinity

ensure pods are hosted on particular node

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: size
            operator: In
            values:
            - large            
  containers:
  - name: nginx
    image: nginx

• 만약 large node 뿐만 아니라 small node에도 배포될 수 있게 하려면, values 밑에 small 을 추가하기만 하면 된다.

Node Affinity Types

Available

• requiredDuringSchedulingIgnoredDuringExecution
  • if matching node does not exist, the pod will not be scheduled
  • preferredDuringSchedulingIgnoredDuringExecution ** 위와 같은 상황에서, affinity rule을 무시하고 아무 available node에 schedule함
  • 둘다 이미 pod가 node에서 실행되고 있는 와중에 node label이 변한다거나 해도 그대로 현 node에서 schedule된다.

Planned

• requiredDuringSchedulingRequiredDuringExecution

Taints/Tolerations vs Node Affinity

Taints/Tolerations는 node에 특정 pod만 배포될 수 있도록 할 수 있고,
Node Affinity로 pod가 특정 node에만 배포될 수 있도록 할 수 있다.

즉, 두개 모두 사용시 특정 pod가 특정 node에만 배포되고 다른 pod는 해당 node에 배포되지 못하게 할 수 있다.

DaemonSets

ReplicaSet과 비슷하지만 pod가 각 node에 하나씩 스케줄링되도록 한다. 항상 모든 node에 pod가 배포되는 것을 보장한다. 만약 node가 삭제되면, 해당 노드에 배포된 pod도 삭제된다.

• UseCase
  • Monitoring Solution
  • Logs Viewer
  • kube-proxy
  • networking

Static Pods

kubernetes control plane에 독립적으로, kubelet을 통해서만 관리되는 pod

만약 pod에 문제가 생기면 kubelet이 자동으로 restart시킴

master node에 control plane component(api server, controller, etc.) 를 pod로 구성시키는데 사용됨

AWS WAF도 생소한데 allow, block도 아닌 count는 뭐지..

terraform을 사용하여 cloudfront+s3로 웹호스팅을 구성하고, 그 앞단에 waf를 둠으로써 특정 ip만 접속 가능하게 구성하는 과정에서 정리한 글이다.

분명히 잘 구성했다 생각했는데 cloudfront domain name으로 접속시 웹페이지가 제대로 뜨지 않았다. 그러나 waf를 걷어내면 정상적으로 동작하였는데,

원인은 바로 web acl에서 rule group을 지정하는 부분에서 overide_action을 count로 지정했기 때문이었다.

AWS WAF(Web Application Firewall)

말 그대로 웹 애플리케이션 방화벽으로 웹 프로토콜(HTTP) 정보를 바탕으로 차단/허용 룰을 설정한다.

rule action

rule에 일치하는 트래픽이 들어왔을 때 어떤 액션을 취할것인지 정의하는 것이다.

• allow: 해당 요청을 허용한다.
• block: 해당 요청을 거부한다.

그렇다면, count란 대체 무엇일까?

count

count는 해당 요청을 허용할 것인지, 막을 것인지 결정하지 않는다. rule에 매칭되는 요청이 들어오면, 해당 요청이 들어왔다는 것만 인지한 후 다음 순위의 rule로 해당 요청을 보내버린다.

만약 jisun-web-acl에 A rule group과 B rule group이 있다고 해보자.

• jisun-web-acl의 default action: block
• A rule group의 action: count
• B rule group의 action: allow

만약 A rule group에 매칭되는 요청이 들어왔다고 가정해보자. 그럼 A rule group의 action에 따라 요청을 처리할텐데, count action이므로 같은 web acl에 있는 다른 rule group에 그 결정을 맡기게 될 것이다.

그렇게 되면 2가지 경우의 수로 나눠서 볼 수 있다.

1. 해당 요청이 B rule group에 해당되는 경우
2. 해당 요청이 B rule group에 해당되지 않는 경우

1번의 경우에는 B rule group의 action이 allow이므로 해당 요청은 최종적으로 allow될 것이다.

그러나 2번의 경우에는 요청이 B rule group에 해당되지 않으니 결국 web acl의 default action에 따라 처리됨으로 block될 것이다.

count를 왜 쓰는 것일까?

만약 새로운 rule group을 등록했을 때 바로 allow/block action을 지정해버리면, 테스트 환경에선 상관없겠지만 실제 운영중인 환경에 적용할 시 바로 장애로 이어질 수 있다.

그렇기에 count action으로 지정해두고 새로 만든 rule group에 어떤 요청이 매칭되는지 테스트 후 다른 action을 지정하면 좀더 안정적으로 waf를 사용할 수 있게 된다.

끝!

Problem

Error: Failed getting S3 bucket (버킷명): BadRequest: Bad Request status code: 400, ... with data.aws_s3_bucket.hosting, on main.tf line 30, in data "aws_s3_bucket" "hosting": 30: data "aws_s3_bucket" "hosting" {

# aws provider
provider "aws" {
  version = "~> 3.0"
  region  = "us-east-1"
}

# S3 bucket
data "aws_s3_bucket" "hosting" {
  bucket = "<버킷명>"
}

Why

region 문제였다. cloudfront는 항상 N. Virginia에서만 사용가능하기 때문에 aws provider의 기본 region을 us-east-1으로 설정을 해두었다. 그러나 s3 bucket은 Singapore(ap-southeast-1) region에 있었고, 그렇기에 'aws_s3_bucket' data source에서 'bucket' argument만으로는 원하는 s3 bucket을 찾아가지 못한 것이었다.

Solution

provider의 alias를 사용함으로써 다중 region을 구현할 수 있다.

# default aws provider
provider "aws" {
  version = "~> 3.0"
  region  = "us-east-1"
}

# s3 alias aws provider
provider "aws" {
  alias = "s3"

  version = "~> 3.0"
  region = "ap-southeast-1"
}

# S3 bucket
data "aws_s3_bucket" "hosting" {
  provider = aws.s3  # set provider

  bucket = "<버킷명>"
}

tomcat의 jvm heap 메모리 사이즈를 조정하려고 실행중인 tomcat의 PID를 확인하곤 불현듯 깨달은 것이 있다.

$ ps -aux | grep tomcat
root      2946  0.2 12.0 2321400 121440 ?      Sl   01:33   0:21 /usr/bin/java -Djava.util.logging.config.file=/data/was/tomcat/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djdk.tls.ephemeralDHKeySize=2048 -Djava.protocol.handler.pkgs=org.apache.catalina.webresources -Dorg.apache.catalina.security.SecurityListener.UMASK=0027 -Dignore.endorsed.dirs= -classpath /data/was/tomcat/bin/bootstrap.jar:/data/was/tomcat/bin/tomcat-juli.jar -Dcatalina.base=/data/was/tomcat -Dcatalina.home=/data/was/tomcat -Djava.io.tmpdir=/data/was/tomcat/temp org.apache.catalina.startup.Bootstrap start
ec2-user  4000  0.0  0.2 123584  2260 pts/0    S+   04:19   0:00 grep --color=auto tomcat

서비스를 실행하는 계정이 root인 것을 발견했기 때문이다.

그 이유는 내가 tomcat을 컴파일 설치한 후 직접 서비스 파일을 만들어서 실행시켰기 때문이다. -> [Amazon Linux 2] Tomcat 8.5.64 컴파일 설치 & 서비스 등록

따라서, 따로 tomcat을 위한 서비스 계정과 그룹을 만들어서 등록시키는 과정을 기록하게 되었다.

Tomcat 서비스 계정 변경

서비스 계정과 그룹 생성

sudo groupadd was
sudo useradd tomcat -G was

• was 그룹을 생성하고,
• tomcat 계정을 생성함과 동시에 was 그룹에 소속시킴

서비스 파일 수정

서비스 파일에서 User와 Group을 수정해주자

/usr/lib/systemd/system/tomcat.service

[Unit] Description=tomcat8.5.64 After=network.target syslog.target

[Service] Type=forking

Environment=CATALINA_HOME=/usr/local/tomcat8/apache-tomcat-8.5.64 User=tomcat Group=was

ExecStart=/usr/local/tomcat8/apache-tomcat-8.5.64/bin/startup.sh ExecStop=/usr/local/tomcat8/apache-tomcat-8.5.64/bin/shutdown.sh

UMask=0007 RestartSec=10 Restart=always

SuccessExitStatus=143

[Install] WantedBy=multi-user.target

😂 Failed to start tomcat 에러

서비스 파일만 수정하고 데몬을 리로드했더니 Failed to start tomcat8.5.65. 에러가 났었다.

$ sudo systemctl daemon-reload
$ sudo systemctl status tomcat

● tomcat.service - tomcat8.5.65
   Loaded: loaded (/usr/lib/systemd/system/tomcat.service; enabled; vendor preset: disabled)
   Active: activating (auto-restart) (Result: exit-code) since 금 2021-04-23 04:25:58 UTC; 3s ago
  Process: 4145 ExecStop=/data/was/tomcat/bin/shutdown.sh (code=exited, status=203/EXEC)
  Process: 4153 ExecStart=/data/was/tomcat/bin/startup.sh (code=exited, status=203/EXEC)
 Main PID: 2946 (code=exited, status=143)

 4월 23 04:25:58 ip-10-100-3-226.ap-northeast-2.compute.internal systemd[1]: tomcat.service: control process exited, code=exited status=203
 4월 23 04:25:58 ip-10-100-3-226.ap-northeast-2.compute.internal systemd[1]: Failed to start tomcat8.5.65.
 4월 23 04:25:58 ip-10-100-3-226.ap-northeast-2.compute.internal systemd[1]: Unit tomcat.service entered failed state.
 4월 23 04:25:58 ip-10-100-3-226.ap-northeast-2.compute.internal systemd[1]: tomcat.service failed.

이것저것 검색해보고 고민해보다가 tomcat이 설치된 경로의 소유자와 소유 그룹을 설정하지 않았다는 것을 알았다.

tomcat 설치 경로 소유자:소유그룹 변경

sudo chown -R tomcat:was /data

• /data/was : Tomcat 설치 경로
• /data/was-app : Tomcat Root Directory 경로

$ ls -ld /data
drwxr-xr-x 5 tomcat was 124  4월 21 08:23 /data

$ ls -l /data
drwxr-xr-x 3 tomcat was     55  4월 21 08:23 was
drwxr-xr-x 2 tomcat was    110  4월 21 08:23 was-app

daemon-reload

마지막으로, 변경한 서비스 설정을 반영하기 위해 데몬을 리로드 시켜주자

sudo systemctl daemon-reload

😎 최종 확인

$ sudo systemctl status tomcat
● tomcat.service - tomcat8.5.65
   Loaded: loaded (/usr/lib/systemd/system/tomcat.service; enabled; vendor preset: disabled)
   Active: active (running) since 금 2021-04-23 04:31:16 UTC; 25s ago
 Main PID: 4302 (java)
   CGroup: /system.slice/tomcat.service
           └─4302 /usr/bin/java -Djava.util.logging.config.file=/data/was/tomcat/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djd...

 4월 23 04:31:16 ip-10-100-3-226.ap-northeast-2.compute.internal systemd[1]: tomcat.service holdoff time over, scheduling restart.
 4월 23 04:31:16 ip-10-100-3-226.ap-northeast-2.compute.internal systemd[1]: Starting tomcat8.5.65...
 4월 23 04:31:16 ip-10-100-3-226.ap-northeast-2.compute.internal systemd[1]: Started tomcat8.5.65.

$ ps -aux | grep tomcat
tomcat    4302 20.3 12.3 2319352 124264 ?      Sl   04:31   0:06 /usr/bin/java -Djava.util.logging.config.file=/data/was/tomcat/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djdk.tls.ephemeralDHKeySize=2048 -Djava.protocol.handler.pkgs=org.apache.catalina.webresources -Dorg.apache.catalina.security.SecurityListener.UMASK=0027 -Dignore.endorsed.dirs= -classpath /data/was/tomcat/bin/bootstrap.jar:/data/was/tomcat/bin/tomcat-juli.jar -Dcatalina.base=/data/was/tomcat -Dcatalina.home=/data/was/tomcat -Djava.io.tmpdir=/data/was/tomcat/temp org.apache.catalina.startup.Bootstrap start
ec2-user  4364  0.0  0.2 123584  2288 pts/0    S+   04:31   0:00 grep --color=auto tomcat

끝!!!~!!!

🧐 Root Directory(=Document Base, Context Root)란

web application의 기본 디렉토리를 말한다.

즉, 접속자가 <ip-addr>:8080/ 와 같은 루트 도메인을 땅하고 쳤을 때, 서버에서 호스팅해줄 파일들이 위치하는 기본 폴더를 얘기한다.

기본적으로 tomcat의 디폴트 루트 디렉토리는 ${CATALINA_HOME}/webapps/ROOT 이다.

Root Directory를 원하는 경로로 바꿔보자

${CATALINA_HOME}/conf/server.xml 에 루트 디렉토리 경로가 지정되어있다.

방법은 간단하다. Host 태그 안에 Context 태그 한줄 추가하면 된다.

server.xml (기본)

...
<Host name="localhost"  appBase="webapps"
            unpackWARs="true" autoDeploy="true">
</Host>
...

server.xml (바꾼 후)

• /data/was-app 으로 root directory 변경

...
<Host name="localhost"  appBase="webapps"
            unpackWARs="true" autoDeploy="true">
  <Context path="" docBase="/data/was-app" reloadable="false"></Context>
</Host>
...

• reloadable을 false로 만든 이유는 context 변화를 tomcat이 자동으로 감지해서 적용시킬 수 있으나, 그렇게되면 컴퓨팅 리소스를 소모하기 때문에 false로 두었음

서비스 재시작

sudo systemctl restart tomcat

끝~~

배포 최소 단위 Pod > container -> 하나의 pod는 여러 containers를 가질 수 있다. 그러나 보통 pod당 하나의 container(같은 종류의)을 담는다.

POD with YAML

• apiVersion
• kind
• metadata
• spec

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
    type: front-end
spec:
  containers:
    - name: nginx-container
      image: nginx

ReplicaSets

ReplicaSet은 selector에 있는 label과 같은 pods를 모두 관리한다. 즉, replicaSet을 만들기 전에 있던 pod도 selector의 label만 같으면 replica 개수에 포함시켜 모니터링한다.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: myapp-replicaset
  labels:
    apps: myapp
    type: front-end
spec:
  template:
    metadata:
      name: myapp-pod
      labels:
        app: myapp
        type: front-end
    spec:
      containers:
        - name: nginx-container
          image: nginx
  replicas: 3
  selector:
    matchLabels:
      type: front-end

replicas 개수를 늘리기 위해선 2가지 방법이 있다.

1. kubectl replace -f <file-name>
2. kubectl scale --replicas=<replica-num> -f <file-name>
3. kubectl scale --replicas=<replica-num> replicaset <replicaset-name>

주의할 점은, kubectl scale 명령과 파일 이름을 input으로 넣어도 자동적으로 파일 안에 replicas 개수가 업데이트되지 않는다는 점이다.

Deployments

Covers the replicasets roles and plus, have capability to upgrade the underlying instances seamlessly using rolling updates, undo changes, pause, and resume changes as required

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
  labels:
    apps: myapp
    type: front-end
spec:
  template:
    metadata:
      name: myapp-pod
      labels:
        app: myapp
        type: front-end
    spec:
      containers:
        - name: nginx-container
          image: nginx
  replicas: 3
  selector:
    matchLabels:
      type: front-end

Services

application들을 이어주는 역할을 한다.

Service Types

1. NodePort 내부의 pod가 node의 port를 통해 접근될 수 있게 하는 것

   • targetPort: 타겟 pod의 port
   • port: service의 port (필수로 지정)
   • nodePort: node의 port (300000 ~ 32767)

apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  type: NodePort
  ports:
    - targetPort: 80
      port: 80
      nodePort: 30008
  selector:
    app: myapp
    type: front-end

* selector 필드를 통해 매칭되는 파드를 연결시켜준다.

그래서, 매칭되는 여러개의 파드를 랜덤하게 load balancing하는 역할도 수행할 수 있다. * 만약 여러 노드에 각각 pod가 하나씩 배치되어있고, 하나의 NodePort 서비스를 만든다면, kubernetes가 자동으로 node 전체에 확장된 서비스를 만든다. 그러면 각 node의 IP와 같은 port 번호를 통해 각각의 pod에 접근이 가능하다.

2. ClusterIP cluster안에 가상의 IP를 만들어서 통신할 수 있게 하는 것 여러 pod에 연결할 수 있게 single access point를 제공해주는 역할을 한다.

   apiVersion: v1
   kind: Service
   metadata:
   name: back-end
   spec:
   type: ClusterIP
   ports:
    - targetPort: 80
      port: 80
   selector:
    app: myapp
    type: front-end

   • type을 지정하지 않으면 default service로 ClusterIP로 만들어짐

3. LoadBalancer CSP에서 제공하는 로드밸런서를 사용하는 방법

   • NodePort를 사용하면 여러 node가 존재하는 환경에서 각각의 node의 IP주소를 입력해야 접근이 가능하다. 그러나, 이런 여러 node의 IP주소를 하나로 묶어서 유저에게 접근 포인트를 제공하기 위해서는 CSP에서 제공하는 LB를 사용할 수 있는 LoadBalancer 서비스가 필요하다.

apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  type: LoadBalancer
  ports:
    - targetPort: 80
      port: 80
      nodePort: 30008
  selector:
    app: myapp
    type: front-end

Imperative vs Declarative

시험에서 적절히 두가지 방법을 사용할줄 알아야한다.

Imperative

• Create Objects

  kubectl create -f nginx.yaml

• Update Objects

  kubectl edit deployment nginx

  • 여기서 열리는 file은 위의 local file인 nginx.yaml과 다른 파일이다. edit 명령어로 열리는 파일은 kubernetes memory에 올라가있는 definition file로, 그 변화가 현재 살아있는 object에 적용된다.bash kubectl replace -f nginx.yaml ``````bash kubectl replace --force -f nginx.yaml
  • force 옵션을 쓰면 object를 완전히 삭제하고 다시 만들게 된다.

Declarative

• Create Objects

  kubectl apply -f nginx.yaml

  kubectl apply -f /path/to/config-files

• Update Objects

  kubectl apply -f nginx.yaml

  • replace와 다른점은, object가 사전에 미리 존재해있지 않다면 replace는 에러를 낸다.

kubectl apply command

apply 명령을 통해 local file의 내용을 kubernetes 안의 실제 live한 object의 정의 파일에 적용시키는 역할을 한다. 또한, last applied configuration을 저장해두기 때문에 apply 명령을 통해 수정된 local file을 적용시키면 변화를 감지하여 적용할 수 있다.> create 나 replace 명령어는 이런 last applied configuration을 저장하지 않는다.

#CKA #CKA/Core_Concepts

distributed reliable key-value store

kubectl get 명령으로 보는 모든 정보가 ETCD server로부터 온 것이다. cluster에 만든 모든 변화들이 이곳에 기록된다.

cluster을 어떻게 배포하느냐에 따라서 ETCD도 다르게 배포된다.

1. scratch
2. kubeadm (CKA 환경)

kubeadm으로 cluster을 구성하게 되면, ETCD server은 kube-system namespace에 POD 형태로 배포된다.

kube-apiserver

primary management component in kubernetes

kubectl 명령어를 치면, kubectl utility가 kube-apiserver로 전달된다. 그러면, kube-apiserver은 첫번째로 요청을 인증하고 검증한다. 그리고 ETCD cluster로부터 데이터를 가져와서 돌려준다.

Pod를 하나 만드는 과정을 살펴보면 명확하다.

1. user을 인증한다.
2. request 검증한다.
3. apiserver이 pod 객체를 만들고(아직 node에 할당하기 전) 이 사실을ETCD server에 업데이트하고 user에게 pod가 생성되었음을 알린다.
4. scheduler은 apiserver을 지속적으로 모니터링하고있다가 새로운 pod가 생긴것(node에는 할당되지 않은)을 알아차린다.
5. scheduler이 pod를 위치시킬 적당한 node를 확인하고 kube-apiserver에게 알리고 kube-apiserver은 이 사실을 ETCD cluster에 업데이트한다.
6. 그리곤 kube-apiserver은 해당 worker node에 있는 kubelet에 해당 정보를 전달하고
7. 그러면 kubelet이 해당 node에 pod를 생성하고 container runtime engine에게 application image를 배포하도록 시킨다.
8. 그리고 다시 kubelet은 status를 apiserver에게 전달하고 apiserver은 정보를 다시 ETCD cluster에 업데이트한다.

Kube Controller Manager

manages various controllers in kubernetes

Controller

process that continuously monitors the state of various components within the system and works towards bringing the whole system to the desired functioning state

예를들면, node controller은 node의 상태를 검사하고 application이 running할 수 있게 만들어야하는 의무를 가지고 있다. 단, 이러한 action은 kube-apiserver을 통해 수행한다.

kubernetes에서 나오는 모든 개념, namespaces, replicasets, deployment 모두는 controller으로부터 나온다.

이런 여러 controller을 하나의 패키지로 담은 것이 kube controller manager인 셈이다.

Kube Scheduler

deciding which pod goes on which node ** 실제로 pod를 node에 위치시키는건 kubelet

Kubelet

register node, create pods, monitor node&pods

특이점은 kubeadm tool을 사용하면 자동적으로 설치되었던 다른 component와는 달리, kubelet은 자동으로 배포되지 않는다. 항상 직접 worker node에 kubelet을 설치해야 한다.

Kube-proxy

process that runs on each node in the kubernetes cluster to look for new services and every time a new service is created, it creates the appropriate rules on each node to forward traffic to those services to the backend pods

예를들면, web pod와 db pod가 있다고 할 때, web pod는 db pod에 접근하기 위해 db pod의 ip에 직접 접근하는 것이 아니라(ip가 변할 수 있는 등의 이유 때문), db service를 통해 db pod(backend pod)에 접근한다. 여기서 kube-proxy는 iptables rule을 통해 각 node에 iptable을 만들어서 트래픽을 보낼 수 있게 만든다.

yum과 같은 package manager 대신, 소스를 직접 다운받아 컴파일해서 설치

그런데, 톰캣은 컴파일 과정은 없고 소스파일만 받아다가 잘 위치해놓고 서비스 등록하는 것으로 끝!

$ sudo yum install -y java-1.8.0-openjdk-devel.x86_64

$ mkdir /usr/local/tomcat8
$ cd /usr/local/tomcat8

$ wget https://downloads.apache.org/tomcat/tomcat-8/v8.5.64/bin/apache-tomcat-8.5.64.tar.gz
$ tar xvfz apache-tomcat-8.5.64.tar.gz

😊 서비스 등록

$ vim /usr/lib/systemd/system/tomcat.service

[Unit] Description=tomcat8.5.64 After=network.target syslog.target

[Service] Type=forking

Environment=CATALINA_HOME=/usr/local/tomcat8/apache-tomcat-8.5.64 User=root Group=root

ExecStart=/usr/local/tomcat8/apache-tomcat-8.5.64/bin/startup.sh ExecStop=/usr/local/tomcat8/apache-tomcat-8.5.64/bin/shutdown.sh

UMask=0007 RestartSec=10 Restart=always

SuccessExitStatus=143

[Install] WantedBy=multi-user.target

$ systemctl start tomcat
$ systemctl enable tomcat

이렇게 간단히 끝~~

한마디로 컨테이너를 관리하는 플랫폼이다.

• 컨테이너 플랫폼
• 마이크로서비스 플랫폼
• 이식성 있는 클라우드 플랫폼

[참고] Kubernetes docs

구성요소 및 API

마스터

클러스터의 컨트롤 플레인 제공

• API 서버(Kube-apiserver)
  • 쿠버네티스 클러스터의 모든 구성요소들은 API 서버를 통해 통신함
• etcd
  • 클러스터 데이터의 키-값 저장소
• 쿠버네티스 컨트롤러 관리자(kube-controller-manager)
  • 클러스터의 상태를 감시하고 필요한 상태로 이행하는 컨트롤 기능 담당
    • Node controller: 노드 상태 감시&대응
    • Replication controller: 복제 컨트롤러를 사용하는 모든 오브젝트 관리 & Pod 유지
    • Endpoint controller: Service와 Pod 연결
    • Service account 및 Token controller: namespace, account, token 담당
• 클라우드 컨트롤러 관리자(cloud-controller-manager)

노드

쿠버네티스의 컨테이너 런타임 환경 제공 즉, 실제로 일하는 애들

• kubelet
  • 각 노드에서 실행되는 에이전트
  • 마스터로부터 제공받은 파드의 구성정보를 받아 컨테이너의 동작을 관리
• 프록시(kube-proxy)
  • 호스트 레벨의 네트워크 규칙 구성
  • 외부 연결을 파드에 대한 포워딩 담당
• 컨테이너 런타임
  • 컨테이너 동작을 책임지는 구성요소
  • 기본적으로 도커 플랫폼 사용