20220531 필기노트

강재민·2022년 5월 31일
0

필기노트

목록 보기
20/23

Fargate


루트사용자는 쿠버네티스 정보를 볼 수 없음
어제꺼 클러스터를 올림

Fargate는 EC2인스턴스를 추상화했기 때문에 Pod만 관리하면 된다.

https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/fargate.html

Fargate는 ec2인스턴스가 없으므로 ip타입으로만 Pod에 연결할 수 있다.

데몬셋은 노드마다 배치하는건데 Fargate는 가상머신도 추상화되었으므로 노드가 없어서 데몬셋이 필요가 없음

Fargate는 VPA와 HPA둘 다 조정 가능하다.


이 조건들을 만족시키지 않으면 워커노드에 배치되게 된다.



ctrl+shift+p 해서 apply

이렇게 일반 노드에 배치가 된다.

apiVersion: v1
kind: Pod
metadata:
  name: fg
  namespace: dev
  labels:
    name: fg
    env: fargate
spec:
  containers:
  - name: fg
    image: ghcr.io/c1t1d0s7/go-myweb
    ports:
      - containerPort: 8080

ctrl+shift+p 해서 apply


1개의 Pod는 1개의 Fargate-Node로 되어있다.
내부적으로 아주 경량의 VM에 띄우는거라고 하심

여기에 ALB나 NLB를 만들어서 통신을 해보십시오

apiVersion: v1
kind: Service
metadata:
  name: myweb-svc-lb
  namespace: dev
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: "external"
    service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "ip"
	service.beta.kubernetes.io/aws-load-balancer-scheme: "internet-facing"
spec:
  type: LoadBalancer
  selector:
    env: fargate
  ports:
    - port: 80
      targetPort: 8080




apiVersion: v1
kind: Service
metadata:
  name: mysvc
  namespace: dev
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: "external"
    service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "ip"
    service.beta.kubernetes.io/aws-load-balancer-scheme: "internet-facing"
spec:
  selector:
    app: myfg
  ports:
  - port: 80
    targetPort: 8080
  type: LoadBalancer
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myfg
  namespace: dev
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myfg
  template:
    metadata:
      labels:
        app: myfg
        env: fargate
    spec:
      containers:
      - name: myfg
        image: ghcr.io/c1t1d0s7/go-myweb
        resources:
          limits:
            memory: "128Mi"
            cpu: "500m"
        ports:
        - containerPort: 8080

VPA

https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/vertical-pod-autoscaler.html

https://github.com/kubernetes/autoscaler

vpa down은 혹시나 이전에 설치가 되어있었다면 실행시켜주어야함

GIT BASH 접속을 하고



반응이 안나와서 다시 만들어봄

제대로 안만들어졌음


다시 지우고

다시 만들고..

다시지우고..
vpa up 했을 때 오류가 난다고 하심
인증서를 생성해야하는데 인증서를 생성할 수가 없는 상태라고 하심

### 관리자권한으로 터미널 열어서

choco search openssl
choco install openssl -y

### 재부팅을 해야함..


리눅스에서 해야함..

나중에 vm 띄워서 하면 될것임


실습하고나면 꼭 삭제해주기
alb나 nlb가 만들어진 상태에서 지우면 클러스터가 안지워짐

젠킨스 앤서블 톰켓 깃헙 쿠버네티스 연동을 할 예정임


GIT


오마이지쉘에서 git관련된 도움을 받을 수 있으므로 vm으로 하면 좋음

Vagrant.configure("2") do |config|
        # Define VM
        config.vm.define "jenkins" do |ubuntu|
                ubuntu.vm.box = "ubuntu/focal64"
                ubuntu.vm.hostname = "jenkins"
                ubuntu.vm.network "private_network", ip: "192.168.59.10"
                ubuntu.vm.provider "virtualbox" do |vb|
                        vb.name = "jenkins"
                        vb.cpus = 2
                        vb.memory = 3000
                end
        end
        config.vm.provision "shell", inline: <<-SHELL
          sed -i 's/PasswordAuthentication no/PasswordAuthentication yes/g' /etc/ssh/sshd_config
          sed -i 's/archive.ubuntu.com/mirror.kakao.com/g' /etc/apt/sources.list
          sed -i 's/security.ubuntu.com/mirror.kakao.com/g' /etc/apt/sources.list
          systemctl restart ssh
        SHELL
end

윈도우에서 작업해도 무방함

오마이 지쉘 설정하고..
https://git-scm.com/
git과 관련된 학습자료..
https://git-scm.com/doc

progit이라는 책이 있음
https://git-scm.com/book/ko/v2
이게 git의 교과서같은 거임..

SCM source control management
TXT기반 파일들을 버전관리 해줌

VCS version control system


중앙식은 단일실패지점이 생길 수 있음

그래서 분산 버전 관리 DVCS
를 사용하려고 하지만 결국 중앙집중식으로 관리되고있음
gitlab 장애가 나면 쉬는날..



가장 중요한 핵심 워크플로우임..
만약 기존의 파일을 수정했다고 하면 현재 디렉토리에서 작업을 했고
그러고나면 파일을 Staging상태를 만든다.
git add를 하고나면 이제부터 변경되면 추적을 하겠다는 뜻임.
Staging은 리허설같은것임
문제가 없다면
git commit을 하게됨
모든 버전정보는 .git directory에 저장됨 이게 local repository

로컬 저장소를 만드는 방법은
2가지
1. 아무거도 없는 저장소를 만들거나
2. 원격 저장소에 있는거를 받아오거나

git clone

git clone https://github.com/kubernetes-sigs/kubespray.git
ls -a			#.git이라는 디렉토리가 있음

### 이런식으로 하면됨
### .git디렉토리를 삭제했다가 다시만들면 안됨
mkdir mykube
cd mykube
ls -a
git init
tree .git			#이 디렉토리는 소중히 간직해야함

예를들어서
vi pod.yaml

git status
git add pod.yaml			#staging임
git commit					#오류가남

### commit을 한다는건 기록을 한다는것이어서 누가했는지를 적어야함

git config --global user.name "Jang"			#이 컴퓨터 전체에 대해서 설정한다.
git config --global user.email "Jang@encore.com"
git config --global --list
git commit


이걸 commit massage라고 함


master 색깔 바뀐거 확인
commit하나하나가 다 버전임




명렁어를 inline형태로 붙이는 것도 가능하긴한데 추천하지는 않는다.
좀더 자세하게 쓰는걸 추천드림


이렇게 commit을 할 때마다 버전이 생긴다고 함..

git config --global core.pager ''


이렇게 돌아갈 수 있음



이렇게 다시 최신으로 돌아갈 수도 있음


항상 나중에 봐도 이해할 수 있게 잘 적어놓아라..

https://stackoverflow.com/questions/3580013/should-i-use-past-or-present-tense-in-git-commit-messages

현재형과 과거형의 찬반이 있었는데 현재형이 이김

맨뒤에 링크는 이슈들에 대한 내용을 연결시켜줌

github계정을 만들꺼면 이런 깃 메시지를 잘 관리해서 보여주시라


파일의 라이프사이클임 매우중요함

git rm하면 파일을 지우게됨

제일 중요한 개념임


README.md를 읽어서 구성하게됨
이것도 제출 시에 써야함



제외할 파일 선택할 수 있다.
그리고 당연하겠지만 홈디렉토리를 사용하면 안됩니다.

Initial commit할 때 readmi.md .git.kg==ignore해주는게 좋음
라이센스도 있음

stage나 commit을 하면됨


-a옵션은 추가하라는 뜻 add

commit을 할 때는 원자성이 중요하다.

연관관계가 없는 수정을 섞어서 하나의 commit으로 만들면 안된다.

커밋을 한 번 하더라도 의미있게 또개서 해보라

이렇게 하면 안됨



이렇게 사용해주어야함

gir rm svc.yaml



이런식으로 삭제가 가능하다 !

최근상태로 돌아가기

git mv pod.yaml mypod.yaml
git mv mypod.yaml pod.yaml
git status

중간중간 git stats를 잘 사용해보기


https://git-scm.com/book/ko/v2/Git%EC%9D%98-%EA%B8%B0%EC%B4%88-%EC%BB%A4%EB%B0%8B-%ED%9E%88%EC%8A%A4%ED%86%A0%EB%A6%AC-%EC%A1%B0%ED%9A%8C%ED%95%98%EA%B8%B0

기존에 있던 commit에 포함시키고싶다면


이렇게 추가할 수 있다.



만약 지금까지 변경사항들이 맘에 안들어서 마지막 커밋상태로 돌리기위해





git checkout이 하는 일이 너무 많아서 어렵다.


그래서 restore같은 명확은 의미의 명령어들이 생김

ls
cd kubespray
git remote하면 origin이 있다.

origin이 있고 이름지은 것들이 있다..


https://git-scm.com/book/ko/v2/Git-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EB%B8%8C%EB%9E%9C%EC%B9%98%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80


특정 버전에서 가지치기가 가능하다

B가 A1을 받아오지 않으면 A3을 오리진에 업데이트시킬 수 없게된다.

checkout을 통해 바라보는 브랜치를 바꿀 수 있다.



-b 옵션을 통해 없는 브랜치를 만들면서 이동이 가능하다.




다음 시나리오를 생각해보자



이거를 Fast forward라고 한다.


충돌시나리오
dev3 브랜치를 만들고



같은 파일을 안다루는게 가장 좋지만 이런 일이 일어날 수 있다.

충돌이 나면 abort하고 다시 빌드해야함...
충돌 안나게 조심해서 하길 바람

https://git-scm.com/book/ko/v2/Git%EC%9D%98-%EA%B8%B0%EC%B4%88-%EB%A6%AC%EB%AA%A8%ED%8A%B8-%EC%A0%80%EC%9E%A5%EC%86%8C


아무것도 지정하지않고 만들면







MFA를 해놓으면 비밀번호만으로는 접속이 안됨


토큰을 가지고 로그인 할 수가 있다.




가장 좋은것은 ssh이긴하다고 하심


fetch 가지고오는것




아무렇게나 하나 추가


fetch와 pull의 차이를 알기를 바람
fetch는 원격저장소의 내용만 가져오고 원래있던 head상태 그대로 이쓴것임
pull은 fetch와 merge를 같이하게됨
문제는 충돌






일반적으로 collaborators는 극소수의 사람들만 둔다.
그게 아닌사람들은 어떻게 하느냐

fork를 해서 clone을 뜬다



이런식으로 할 수 있다고 하심..





포크해서 브랜치 만들어서 PR날려주세요
라고 주로 하심..

그게 아니라면 collaborator로 push 하면 됨

Collaborator 권한이 있다면 바로 push하면 끝난다..

모두 Collaborator를 가지고 브랜치를 각각만들어서 작업을 하거나
누구 하나 총대를 매고 다른 사람들은 PR을 요청해서 작업하는식으로 할 수 있음 후자는 PR 로그가 남아서 좀 편할 수 있음

핵심만 있는 문서
https://rogerdudler.github.io/git-guide/index.ko.html


태그

https://git-scm.com/book/ko/v2/Git%EC%9D%98-%EA%B8%B0%EC%B4%88-%ED%83%9C%EA%B7%B8


git tag -a 'v0.1' -m 'Version 0.1'
git tag -l

heading한 곳에 태그가 정해짐


태그도 일종의 브랜치이기 때문에 push를 해줘야함

팀별로 작업을 한 번 해보면서 어떤게 편할지 작업을 해보아야한다..



여기에 등록해주면됨


이렇게하면 언제든지 push할 수 있다.

git remote -v

0개의 댓글