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: 8080ctrl+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 ''
이렇게 돌아갈 수 있음
이렇게 다시 최신으로 돌아갈 수도 있음
항상 나중에 봐도 이해할 수 있게 잘 적어놓아라..
현재형과 과거형의 찬반이 있었는데 현재형이 이김
맨뒤에 링크는 이슈들에 대한 내용을 연결시켜줌
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를 잘 사용해보기
기존에 있던 commit에 포함시키고싶다면
이렇게 추가할 수 있다.
만약 지금까지 변경사항들이 맘에 안들어서 마지막 커밋상태로 돌리기위해
git checkout이 하는 일이 너무 많아서 어렵다.
그래서 restore같은 명확은 의미의 명령어들이 생김
ls
cd kubespray
git remote하면 origin이 있다.
origin이 있고 이름지은 것들이 있다..
특정 버전에서 가지치기가 가능하다
B가 A1을 받아오지 않으면 A3을 오리진에 업데이트시킬 수 없게된다.
checkout을 통해 바라보는 브랜치를 바꿀 수 있다.
-b 옵션을 통해 없는 브랜치를 만들면서 이동이 가능하다.
다음 시나리오를 생각해보자
이거를 Fast forward라고 한다.
충돌시나리오
dev3 브랜치를 만들고
같은 파일을 안다루는게 가장 좋지만 이런 일이 일어날 수 있다.
충돌이 나면 abort하고 다시 빌드해야함...
충돌 안나게 조심해서 하길 바람
아무것도 지정하지않고 만들면
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