20220526 필기노트

강재민·2022년 5월 26일
k8s
0

필기노트

목록 보기
16/23
post-thumbnail
post-custom-banner

Statefulset Mysql

https://kubernetes.io/docs/tasks/run-application/run-replicated-stateful-application/


0번은 프라이머리 나머지는 복제본을 구성하도록 마스터와 슬레이브를 구별하게 한다.


최초 동기화
메인 어플리케이션
이후 동기화
로 나누어서 역할이 있는것을 생각해보기

Pod Scheduling

https://kubernetes.io/ko/docs/concepts/scheduling-eviction/kube-scheduler/

파드를 어디에 배치할 지를 결정하게 된다.
1. 필터링
2. 스코어링
필터링은 cpu, memory등등을
스코어링은 가중치를 매겨서 Pod를 어디다가 배치할 것인지를 결정하게 된다.

https://kubernetes.io/ko/docs/concepts/scheduling-eviction/assign-pod-node/
nodeName은 스케쥴러의 영향을 무시하고 강제로 특정 노드에 배치할 수 있게 한다.
잘 사용하지는 않는다고 함..

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: myweb-rs-nn
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      nodeName: node2
      containers:
        - name: myweb
          image: ghcr.io/c1t1d0s7/go-myweb

kubectl delete -f .

NodeSelector


데몬셋의 경우 NodeSelector를 주로 사용하게 된다.
그리고 모든 컨트롤러들은 노드셀렉터가 다 존재힌다. 파드도 존재함

노드 레이블

kubectl label node node1 gpu=highend
kubectl label node node2 gpu=midrange
kubectl label node node3 gpu=lowend
kubectl get nodes -L gpu				#-L은 레이블 여기서는 gpu레이블을 말함 -l은 검색

mkdir nodeselector && cd nodeselector
vi nodeselector.yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: myweb-rs-ns
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      nodeSelector:
        gpu: lowend
      containers:
        - name: myweb
          image: ghcr.io/c1t1d0s7/go-myweb

kubectl create -f .

어피니티, 안티-어피니티


어피니티는 선호도이다.
그래서 가능하면 선호하는 노드를 사용하게하고 아니어도 된다라는 유연성을 두는 스케쥴링이다.

이런 예제가 있음


최악의 경우 이런 상황이 될 수 있다.
이러면 물리적인 네트워크를 타고 계속해서 오버헤드가 발생한다.
그래서 이렇게 만들어줘야함

Pod와 Pod간의 선호도를 만들어줘서 웹과 데이터베이스를 친구로 만들어줄 수 있다.

다만

이렇게 될 수 있으므로
Pod antiaffinity를 설정해주어야함

그래서 서로 이렇게 나누어지게됨


node마다 hostname이 있을꺼니까 anti-affinity를 해주면 node마다 서로 배척하는 식으로 구성이 된다고 한다.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: myweb-a
spec:
  replicas: 2
  selector:
    matchLabels:
      app: a
  template:
    metadata:
      labels:
        app: a
    spec:
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 10
              preference:
                matchExpressions:
                  - key: gpu
                    operator: Exists
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                 matchLabels:
                   app: a
              topologyKey: "kubernetes.io/hostname"
      containers:
        - name: myweb
          image: ghcr.io/c1t1d0s7/go-myweb

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: myweb-b
spec:
  replicas: 2
  selector:
    matchLabels:
      app: b
  template:
    metadata:
      labels:
        app: b
    spec:
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 10
              preference:
                matchExpressions:
                  - key: gpu
                    operator: Exists
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                 matchLabels:
                   app: b
              topologyKey: "kubernetes.io/hostname"
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                 matchLabels:
                   app: a
              topologyKey: "kubernetes.io/hostname"
      containers:
        - name: myweb
          image: ghcr.io/c1t1d0s7/go-myweb

a를 따라가면서도 자기 자신끼리는 배척하도록 설정된다.

Cordon & Drain

kubectl cordon
kubectl drain
kubectl get nodes

새롭게 만들어지는 Pod는 더이상 해당 노드에 배치되지 않는다는 의미임

kubectl cordon node2
kubectl undordon node2


pending이 걸려있다.

kubectl uncordon node2

kubectl drain node2 --ignore-daeminsets

### drain 통해 강제로 데몬셋도 삭제를 하고 물론
### drain을 하면 cordon도 되어있다.
### 커널 패치나 업데이트를 하게 되면 drain작업을 하게 된다고 함

kubectl uncordon node2

테인트와 톨러레이션

https://kubernetes.io/ko/docs/concepts/scheduling-eviction/taint-and-toleration/

테인트는 컨트롤 플레인과 워커노드를 분리시키기 위한 설정이다.

Taint는 특정 노드에 역할을 부여한다.
toleration은 taint되더라도 Pod를 배치시키게 해줌





이렇게 toleration을 설정해주면 node1에도 배치가 됨

taint는 노드에 특정 역할을 부여할 수 있게 하는것이고 toleration을 이용해서 특정 Pod를 배치시킬 수 있게 하는 것이다.

이건 무적..
API static Pod는 node1에 배치되어야한다.

원리는 간단하지만 나름 복잡하게 쓰이나봄..

RBAC

Role Based Access Control
Kubeconfig

vi ~/.kube/config

kubectl 어떤서버에 인증할 정보와
ca인증서를

ca가 발급해준 인증서를 가지고 인증을 함..


context를 직접 변경할 수 도 있고 명령형 커맨드를 통해서 변경할 수도 있다고 하심

관리자 권한으로 Powershell 열고

choco install kubernetes-cli --version=1.22.4
y
kubectl


다 복사를해서
home 디렉토리에서
mkdir .kube
code .config

하면 

kubectl get nodes

이렇게 할 수 있다고 함..
AWS AKS등을 이용할 때도 이렇게 인증서를 가지고 있으면 접근할 수 있다고 하심

kubectl config view


인증서 관련된 정보는 가려진다


이렇게 추가해보고

이렇게 할 수 있다.

이렇게 변경할 수 있고

이렇게 다시 변경가능하다..
kubectl config set-cluster

Authenticating

https://kubernetes.io/docs/reference/access-authn-authz/authentication/
인증에 관한 내용이다.
Service Account(sa): 쿠버네티스가 관리하는 SA 사용자
Normal User: 일반 사용자(쿠버네티스가 관리X)
우리가 Normal User를 사용하는 것임

인증 방법:

  • x509
  • 정적 토큰
    -Bearer Token
    • http 헤더:
    • ...
    • SA Token
      • JSON Web Token: JWT



이렇게 확인할 수 있다.

­https://jwt.io/



...

예를들어 nfs를 사용하면 pvc를 만들고 pvc가 pv를 만드는데 nfs가 pv를 만들려면 권한이 필요한데 이 권한이 Service Account라고 하심..

okta를 통해 중앙집중화된 인증관리가 가능해진다고 하심..
외부 서비스를 둘 때 사용을 한다..

OIDC는 기억하기 바람..

Using RBAC Authorization

식별은 주민등록증같은거
그사람이 맞다라고 하는것을 증명하는게 인증
그러기위해서 하는게 자격증명 패스워드나 토큰같은거
권한을 부여하는게 인가

RBAC
ABAC : 더이상 사용하지 않는다
Role
Atribute


재시작을 해야해서 사용하지않는다고 하심..

RBAC

  • Role: 권한(NameSpace)
  • ClusterRole: 권한(Global)
  • RoleBinding
    • Role <-> RoleBinding <-> SA/User
  • ClusterRoleBinding
    • ClusterRole <-> ClusterRoleBinding <-> SA/User

Role 예제

https://kubernetes.io/docs/reference/access-authn-authz/rbac/

https://kubernetes.io/ko/docs/reference/access-authn-authz/authorization/

kubectl get po
kubectl get po -v=9
kubectl get po -v=0
kubectl get po -v=7


HTTP방식으로 통신을 한다고 한다..

또다른 예제

또다른 예제

이런식으로 롤바인딩과 클러스터 롤바인딩이 연결되고있는것이고..


여기도 예제가 있음..


system이라고 붙어있는 것은 쿠버네티스를 설치할 때 기본적으로 만들어진것들임

ClusterRole중에 view라고 되어있는 것이 있는데,

우리가 일반적으로사용하는 권한들이 이것들이다.



이게 view이고


이게 edit

안되는 것들도 있다.

SA

kubectl create sa <NAME>
kubectl create sa myuser1
kubectl get sa
kubectl describe sa myuser1
kubectl get secret

cluster

이렇게 그룹에 속해있어서 모든 권한이 있는 것이라고 하심..

사용자 생성을 위한 x509인증서

openssl genrsa -out myuser.key 2048
openssl req -new -key myuser.key -out myuser.crt -subj "/CN=myuser"

이제 서명을 받아야함

vi csr.yaml


-tr은 트림이고 \n을 다 잘라낸다는 뜻임

kubectl create -f .
kubectl get csr

### 컨디션이 Pending상태로 유지되어 있는게 정상

kubectl certificate


이렇게 하면 서명된 인증서가 된다.


인증서를 볼 수 있다..
Issuer 발급자
Subject 발급대상
그 밑에가 공개키..


이게 자체서명인증서임
ssc

그래서 결국 이 인증서를 가지고 인증을 할 수가 있다고 한다..

vi ~/.kube/config

둘 다 가능하다.


이렇게되면 나중에 키나 디렉토리 구조가 바뀌면 달라진다

그래서


이렇게 해주면

키가 고대로 들어간다

kubectl config set-credentials myuser --client-certificate=myuser.crt --client-key=myuser.key --embed-certs=true

이제 context를 만들어보자

kubectl config set-context myuser@cluster.local --cluster=cluster.local --user=myuser --namespace=default

확인해보면

역할을 부여한적이 없어서 Forbidden 이라고 해서 거부되어졌다.

간단한 숙제
kubectl config get-users
kubectl config get-clusters
kubectl config get-contexts
kubectl config use-context myuser@local
새로 생성한 사용자에게 view권한을 주는것이 숙제임
롤 바인딩을 만들어서 연결시켜주고 사용자 전환시에 정보가 확인이 되는지 확인을 해보기

내일은 EKS

profile
강재민
이전 포스트

20220525 필기노트

다음 포스트

20220527 필기노트

post-custom-banner

0개의 댓글