Day 72 - 세미프로젝트 (network policy, cloudwatch)

오늘 한 내용

- network policy 

- cloudwatch

 

---

Network Policy 

일반적으로 3tier를 구성할때 web tier와 was tier의 space를 분리하여 운영하는것이 바람직하다 (보안상!)

우리조는 k8s 내에서 frontend namespace와 backend namespace를 구분하여 각 pod, ns에 network policy를 주었다

이런식으로 .. 위의 구성도에서 backend ns안에 was, DB가 함께 있도록 설계하였다

network policy를 통해 web -> was로 was -> DB로 접속하도록 허용했다 (web -> DB 막음)

 

이때 기본 소스코드에서 수정사항은

1. nginx conf에서 proxy pass 를 FQDN 형식으로 수정

        upstream backend {
        server django-svc.backend:8000;  ## FQDN
        }

name space가 다르기때문에 FQDN으로 하지않으면 통신이 되지 않는다 

2. was deployment yml에서 init container 부분

      - name: init-mysql-svc
        image: busybox:1.28
        command: ['sh', '-c', "until nslookup db-0.mysql-svc.backend.svc.cluster.local; do echo waiting for mysql-svc; sleep 2; done"]

마찬가지로 네임스페이스를 명시해준다 

 

추가로 진행하면서 궁금했던 사항은 아래와 같이 np를 주면 backend 내부의 pod들이 서로 통신을 못한다는 것이었다!

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: network-policy1
  namespace: backend-ns
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              tire: web # ns의 label 

  egress:
    - to:
        - ipBlock:
            cidr: 0.0.0.0/0

 

이유는 np가 만들어지기 전까지는 pod끼리의 통신은 모두 열려있지만

np를 주는 순간 pod의 모든 통신은 막히고 지정한 policy만 허용되기 때문이다

 

위 야물에서 spec ->  podselector에서 파드를 지정해주었다면 그 파드의 모든 통신이 막히고 지정한 통신만 허영되지만 따로 pod를 명시해주지 않는다면 모든 pod의 policy가 바뀐다!

 

따라서 아래와 같이 network policy를 수정하면 frontend ns -> backend ns의 was로만! 통신이 가능해진다

추가로 위와는 다르게 backenf ns안의 pod끼리도 통신이 된다 (was는 제외)

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: web-was-np
  namespace: backend
spec:
  podSelector: 
    matchLabels:
      app: was
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            tier: web # ns의 label 

  egress:
    - to:
      - ipBlock:
          cidr: 0.0.0.0/0

하지만 was와 db도 연결해주어야 하는법 .. 

그럴때는 was pod와 db pod를 연결해주면 된다 (policy 생성) 이때 같은 ns내에서 통신을 정하기 때문에 ingress - from 에서 podselector를 사용한다

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-was-np
  namespace: backend
spec:
  podSelector:
    matchLabels: 
      app: mysql  # 여기로
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - podSelector: # 같은 ns안에서 정책
            matchLabels:
              app: was # pod의 label

  egress:
    - to:
        - ipBlock:
            cidr: 0.0.0.0/0

 

이게 너무너무 궁금해서 .. 한 30분 넘게 헤매다가 강사님과 같이 이유를 찾아보았다 덕분에 기억에도 깊게 남을것같다 하하 

우리조가 어쩌다보니 보안에 많이 신경쓰게 되었는데 오히려 좋은것같다 ㅎㅎ

 

---

Cloud watch

클라우드 서비스 모니터링을 위해 cloudwatch를 많이들 사용한다 

eks를 사용하기 때문에 eks container log를 watch로 보내는 과정을 알아보았다

 

Contianer insights 

Container Insights 사용 - Amazon CloudWatch

이를 지원하는 리전이 있으므로 꼭 확인하고 진행한다.

Contianer insights를 사용하기 위한 조건으로는 다음이 있다

• kubectl 설치
• RBAC 지원
• kubelet 인증모드 (?)
• 컨테이너 런타임 = Docker

+ Amazon EKS 작업자 노드가 지표 및 로그를 CloudWatch에 전송할 수 있도록 IAM 권한을 부여해야한다

다음 순서를 따르면 됨

1. Amazon EC2 콘솔을 열고 작업자 노드 인스턴스 중 하나를 선택하고 설명에서 IAM 역할을 선택합니다. (임의로 하나)
2. IAM 역할 페이지에서 정책 연결(Attach policies)을 선택합니다.
3. 정책 목록에서 CloudWatchAgentServerPolicy 옆의 확인란을 선택합니다. 필요한 경우 검색 상자를 사용하여 이 정책을 찾습니다.
4. 정책 연결(Attach policies)을 선택합니다.

 

클러스터 지표 수집

https://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/Container-Insights-setup-metrics.html

클러스터 지표를 수집하도록 CloudWatch 에이전트 설정 - Amazon CloudWatch

kubectl apply -f <https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/cloudwatch-namespace.yaml>
kubectl apply -f <https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/cwagent/cwagent-serviceaccount.yaml>
curl -o cwagent-configmap.yaml <https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/master/k8s-yaml-templates/cwagent-kubernetes-monitoring/cwagent-configmap.yaml>

• yaml 수정

# create configmap for cwagent config
apiVersion: v1
data:
  # Configuration is in Json format. No matter what configure change you make,
  # please keep the Json blob valid.
  cwagentconfig.json: |
    {
        "agent": {
            "region": "us-west-1" #
        },
        "logs": {
            "metrics_collected": {
                "kubernetes": {
                    "cluster_name": "gymin", # 
                    "metrics_collection_interval": 60
                }
            },
            "force_flush_interval": 5,
            "endpoint_override": "logs.us-west-1.amazonaws.com" #
        },
        "metrics": {
            "metrics_collected": {
                "statsd": {
                    "service_address": ":8125"
                }
            }
        }
    }
kind: ConfigMap
metadata:
  name: cwagentconfig
  namespace: amazon-cloudwatch

적용

kubectl apply -f cwagent-configmap.yaml
kubectl apply -f <https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/master/k8s-yaml-templates/cwagent-kubernetes-monitoring/cwagent-daemonset.yaml>
# 리소스 확인
kubectl get all -n amazon-cloudwatch

 

cloud watch 확인

 

fluentd로 수집

kubectl create configmap cluster-info --from-literal=cluster.name=CB-TEST-EKS-CLUSTER --from-literal=logs.region=us-west-1 -n amazon-cloudwatch
kubectl apply -f https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/master/k8s-yaml-templates/fluentd/fluentd.yaml

 

수집은 어렵지 않은데 ,, 어케 쓰는건지 모르겠다 ㅋㅋ 내일 상의해보기로!

 

오늘의 회고

• 오늘도 역시 빨리 끝날줄 알았던 network policy를 설정하면서 많은 시간을 보냈는데 ㅋㅋ 의미있는 토론이었다!! 더 기억에 잘 남을것같다 뿌듯한 하루~