• proxy 서버 대개체 작업 진행
• centos6 -> centos7 로 변경
• haproxy 로 구성되어있고 heartbeat 설정 되어있는데 keepalived로 변경 필요

1. haproxy 설정

1-1. haproxy 버전 이슈

기존 6버전에는 haproxy-1.5.18-1 버전인데 7버전에서는 haproxy-1.5.18-9 버전이 지원된다. so. rpm 파일을 전달하더라도 dependency 문제가 있어서 설치가 안되는 이슈가 있었다. (이미 depency 패키지가 높은 버전으로 존재하지만 설치 안됨)

외부에서 haproxy-1.5.18-9 rpm 파일 다운 받아서 scp로 전달. 의존성 파일 따로 없이도 rpm 파일이 설치 된다.

1-2 사전작업

정확한 내용은 보안으로 적지 못함 테스트 내용을 작성

httpd 서버 2대를 만들어준다

#app1/app2 서버 둘다 적용
yum install httpd
systemctl enable httpd --now ; systemctl status httpd

1-3. haproxy 설정작업

/etc/haproxy/haproxy.cfg 변경 정확한 내용은 보안으로 적지 못함 테스트 내용을 작성

1번2번 proxy 서버

• front end 변경
• port 를 9398 로 변경해주었음 yum install haproxy-1.5.18

frontend  main *:9398
    acl url_static       path_beg       -i /static /images /javascript /stylesheets
    acl url_static       path_end       -i .jpg .gif .png .css .js

    use_backend static          if url_static
    default_backend             app

• 라우드 로빈으로 설정해주었고 아래와 같이 백엔드에 httpd 서버 2대 설정해 주었음
• [app1 호스트 name] [ip:port]
• [app2 호스트 name] [ip:port]

backend app
    balance     roundrobin
    server  app1 192.168.241.99:80 check
    server  app2 192.168.241.101:80 check

• 실행 systemctl enable haproxy --now ; systemctl status haproxy

2. keepalived 설정

2-1. 사전 설정

proxy1,2번서버 에서 작업

• keepalived 설치 yum install keepalived

• 커널파라미터 변경 keepalived를 master에 적용하고 standby에 적용시 vip를 바라보지 못해서 keepalived 서비스가 실행되지 못한다. 아래 커널 적용하자.

vi /etc/sysctl.conf
> net.ipv4.ip_nonlocal_bind=1 

cat /proc/sys/net/ipv4/ip_nonlocal_bind
#결과: 1 이면 성공
#결과가 1이 아닐경우 재부팅

2-2. proxy1번 작업

• conf 파일 설정 변경
• state MASTER master서버로 선정
• interface 설정 필요 ex) ens33 eth1 등등
• priority 200 숫자가 높을 수록 우선 순위를 갖는다.
• adver_int 2 proxy 서버간 heartbeat 체크 시간 2초마다 체크하도록 설정했다.
• virtual_ipaddress 를 설정해주면 master의 ip에 VIP가 생성된다.

vi /etc/keepalived/keepalived.conf
>
! Configuration File for keepalived

global_defs {
        router_id LVS_DEVEL
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 200      
    advert_int 2
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.241.200/24  ## 나중에 기존 것 적용
    }
}

• 서비스 시작

systemctl enable keepalived.service --now ; systemctl status keepalived.service

2-3. proxy2번 작업

• conf 파일 설정 변경
• state BACKUP standby서버로 선정
• interface 설정 필요 ex) ens33 eth1 등등
• priority 100 master보다 낮은 숫자 설정.
• adver_int 2 proxy 서버간 heartbeat 체크 시간 2초마다 체크하도록 설정했다.
• virtual_ipaddress 를 설정해주면 standby에는 VIP가 생성되지 않는다. 향후 절체되어서 넘어오면 생긴다.

  ! Configuration File for keepalived
  

global_defs { router_id LVS_DEVEL }

vrrp_instance VI_1 { state BACKUP interface ens33 virtual_router_id 51 priority 100 advert_int 2 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 192.168.241.200/24 } }

```

• 서비스 시작 systemctl enable keepalived --now ; systemctl status keepalived

3. 테스트

고객사 서버를 구축하면서 내부망에 패키지 설치가 필요했다.

• iso 파일을 가져와서 각 서버마다 적용

• 파일을 서버에 넣기도 시간이 오래걸리고 디스크 용량도 은근 부담스럽다.

• repo 서버를 만들어서 참조시키면??

2. iso 파일 가져오기

내부망의 공용 서버를 이용하여 repo 서버를 구축 할 예정 외부 bastion 서버에 iso 파일을 넣고 내부 공용서버로 옮긴다.

용량이 안전한 곳으로 옮긴다 so. 사전에 고객사와 이야기하여 여유공간이 있는 디스크를 사용한다.

scp iso파일이름 user@[내부공용서버ip]:/root/

3. 내부 repo 만들기

[내부 공용 서버에서 작업]

• 작업은 /data 밑에서 진행하기로 했다. mkdir /data/iso
mkdir /data/dvd

• iso 마운트 진행 및 iso 파일을 저장해준다.

• cp 가 아니라 rsync를 사용한 이유 cp는 중간에 끊어지면 처음부터 다시 가져오지만 rsync는 증분만 가져온다. 전송 용량도 정할 수 있다.

mount CentOS-7-x86.64-DVD-2009.iso /data/dvd rsync -av /data/dvd/* /data/iso

• private repo를 만들어준다. cp /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/private.repo

• repo 입력

    cat << EOF > /etc/yum.repos.d/private.repo
    [base]
    baseurl=file://data/iso
    gpgcheck=1
    enabled=1
    gpgkey=file:///data/iso/RPM-GPG-KEY-CentOS-7
    EOF
  
    yum clean all
    yum repolist

• 삭제 진행

    umount /data/dvd 
    rm -rf /data/dvd
    rm $HOME/CentOS-7-x86.64-DVD-2009.iso

4. 아파치 repo

4-1. 아파치 설치

다른 서버에서 참조 할 수 있도록 아파치를 만들자 yum install httpd -y

4-2 Document Root

/etc/httpd/httpd.conf를 확인해보면 DocumentRoot "/var/www/html" 로 잡혀있다.

DocumentRoot를 /data/iso 로 참조해도 되지만 심볼릭 링크 를 거는게 훨씬 편하다.

4-3 심볼릭링크

ln -s [원본 디렉토리 or 파일] [link 걸릴 디렉토리 or 파일] ln -s /data/iso /var/www/html/iso

훠얼씬 편하다 !!!

4-4 아파치 실행

systemctl enable httpd --now

5. client 서버

5-1 client 서버 yum repolist

[클라이언트 서버에서 작업]

이제 다른 내부망 클라이언트 서버들의 설정을 진행한다.

vi /etc/yum.repo.d/private.repo
[private repo]
name=private-repo
baseurl=http://공용서버IP/
enabled=1
gpgcheck=1
gpgkey=http://공용서버IP/RPM-GPG-KEY-CentOS-7

yum clean all
yum repolist
yum install nmap

6. 결론

필요한 패키지들만 넣어주는 것도 좋지만 repo 서버를 만들어서 관리하면 여러개의 서버를 동시에 관리하지 않아도 되니 매우좋다.

1. 왜 알아보게 되었는가?

• ssh로 원격 명령어 시행하길 원함
• pw 입력하지 않기위해 공개키 이용
• 공개키를 서버마다 적용하면 너무 불편하다...

2. sshpass

2-1. sshpass설치

• sshpass를 설치 해준다.
• 문제는 private일 경우....... 서버 to 서버 ssh가 막혀있을 경우....ㅎㅎㅎ

yum install sshpass

2-2. 명령어 실행

sshpass -p 'password' ssh root@[원격서버IP] 'la -al' sshpass -p 'password' ssh root@[원격서버IP] < test.sh

3. 여러개에 서버 어떻게 적용?

• 스크립트를 이용해서 여러개의 서버에 적용한다.
• 단점: 각 서버의 pw 가 다를경우 노가다이고 하드코딩으로 pw 를 입력하기 때문에 보안 취약적이다.
• 장점: 한꺼번에 적용된다.

서버리스트 파일 만들기

vi list.txt
192.168.10.10
192.168.10.11
.
.
.
192.168.10.100

while 문 스크립트 만들기

vi test.sh

while read LIST ;
do

echo $LIST
sshpass -p 'test' ssh root@${LIST} 'netstat -antp | grep -i list'

done < list.txt

스크립트 권한 부여 chmod 700 test.sh ./test.sh

결론

ansible이 사용이 안된다면 위 방법도 괜찮은 방법이 될 수 있다.

k8s master 서버에서 workernode 에 명령어를 한번에 적용할 수 없을까?? 서버 하나씩 접속해서 join 하지 않고 싶다...

2. ssh 로 명령어 실행

2-1. ssh 로 명령어 전송

• 원격 접속하는 방법에서 명령어 입려해주면 된다.

• 다만 password 를 써주어야한다.... ssh ssh user@server_ip "ls -al;"

• 현재 서버의 스크립트를 원격에서 실행하는 방법도 있다.

• 다만 password 를 써주어야한다....

ssh myserver sh < test_script.sh

2-2. pw 입력안하기

ssh keygen

[클라이언트 서버]

1.클라이언트 서버에서 ssh key를 만들어준다.

ssh-keygen -t rsa -N '' -f $HOME/.ssh/id_rsa <<< y

2.만든 공개키를 원격 접속 하고자 하는 서버에 전송한다. scp $HOME/.ssh/id_rsa.pub root@원격접속하고 싶은 서버IP:$HOME/id_rsa.pub

[원격 접속 서버]

1. 원격젒고 서버에 권한 설정 및 파일 생성을 해준다.

   mkdir /root/.ssh
   chmod 700 /root/.ssh
   touch /root/.ssh/authorized_keys
   chmod 644 /root/.ssh/authorized_keys

2. 클라이언트에서 가져온 공개키를 등록한다. cat /root/id_rsa.pub >> /root/.ssh/authorized_keys

[접속테스트]

• *good~~!!! * pw 입력없이 접속된다
• 명령어도 pw 없이 되는지 해본다.
• good~~!!*

3. 결론??

그런데 서버에 공개키를 다 넣어주는게 너무 귀찮다 tool을 이용하지 않으면 너무 노가다 이다....(ansible?) 그럼 더 좋은 방법이 있는가??

더 좋은 방법으로 gogo

https://malwareanalysis.tistory.com/125

1. 왜 알아보게 되었는가?

1-1 인증서 관리

지금까지 설치한 히스토리가 나온다. yum history info

2. 설치가능한 패킷 확인

http 중에 설치 가능한 패킷 확인 yum list | grep http* httpd 가 중간에 보인다.

3. 의존성 확인하기

http 설치를 위한 의존성 패키지 검색 yum deplist httpd good

• 개인적으로 사용중인 worker node VM이 올라올 때 고정 ip가 적용되지 않는다.
• 매번 킬때마다 설정하기 귀찮으니 부팅시에 스크립트 실행해서 고정ip 붙이면서 실행시키고 싶다.

2. 부팅 시에 올라오게하자

2-1. /etc/rc.local

• /etc/rc.local 은 /etc/rc.d/rc.local을 심볼릭 링크로 연결되어 있다.

2-2. 실행할 스크립트

• 고정 IP 적용할 스크립트

  vi /root/ipset.sh
  

#!/bin/bash

nmcli con mod ens33 ipv4.addresses 192.168.241.100/24 echo "ip set complete"

nmcli con mod ens33 ipv4.gateway 192.168.241.2 echo "gw set complete"

nmcli con mod ens33 ipv4.dns 8.8.8.8 echo "dns set complete"

nmcli con mod ens33 ipv4.method manual echo "method set complete"

nmcli con up ens33 echo "ens33 up"

## 2-3. rc.local 에 등록

vi /etc/rc.local 아래 한줄 추가 /root/ipset.sh

```

3. error

3-1. enabled 안됨

systemctl enable rc-local --now 할 경우 status 확인시 아래와 같은 문구가 나온다.

에러로그를 보면 /etc/rc.d/rc.local과 매칭이 안된다는 문구이다. ls -al /etc/rc.d/ 확인해보면 rc.local 의 권한에 실행 권한이 없다. 권한을 추가해준다.

chmod +x /etc/rc.d/rc.local

3-2 다시 등록하기

• 설정을 변경했으니 다시 등록해본다. systemctl daemon-reload systemctl enable rc-local systemctl status rc-local 매우 잘된다. 이제 부팅하면 rc.local에 등록된 스크립트가 실행되면서 자동으로 ip세팅을 해준다.

3-3 확인 사살

• 완벽한 확인을 위해 데몬 상태 확인 명령어에서 grep으로 rc-local을 추출하자 systemctl list-unit-files | grep rc-local

good

마무리

작은 걸 가지고도 더 깊이 들어갈 수 있다.

• fedora core os를 사용하여 crontab 등록이 안된다.
• systemd에 데몬을 등록하는데 일정 시간에 작동되게 하고 싶다.

2.스크립트 만들기

2-1 daemon에 등록할 스크립트

• 각 worker node에 쌓이는 이미지를 지울 prune 명령어를 스크립트로 만듬
• crictl rmi --prune 은 사용하지 않는 이미지를 삭제하는 명령어

  $ vi /root/image-remove.sh
  

#!/bin/bash crictl rmi --prune

# 3. service 만들기
- 스크립트를 daemon으로 등록하기 위해 service를 만들어준다.
- 만들어주는 위치는 /etc/systemd/system/ 하위 이다.(반드시)
```$ cd /etc/systemd/system/```
```$ vi image_remove.service```  
서비스 이름은 자유롭게 지어주면 되며 맨뒤에 xxx.service를 반드시 넣어준다.

[Unit] Description=영어로 설명을 적어주시면됩니다.

[Service] Type=oneshot ExecStart=/root/image-remove.sh 스크립트 위치 적어준다.

[Install] WantedBy=multi-user.target systemd enabled 하기 위해서

# 4. timer 만들기
- cron 처럼 system daemon을 타임 설정하여 실행 시킬수 있다.
- 만들어주는 위치는 /etc/systemd/system/ 하위 이다.(반드시)
- timer 설정해주고 싶은 service와 같은 이름으로 만들어야한다(반드시)

```$ cd /etc/systemd/system/```
```$ vi image_remove.timer``` 
서비스 이름과 반드시 같게 만들어줘야하며 xxx.timer 형식으로 만들어준다

[Unit] Description=영어로 설명을 적어주세요

[Timer] OnCalendar=--* 10:00:00 년-월-일 시:분:초 형식으로 진행 AccuracySec=1s timer 실행 하는 시간이 맞는지 확인하는 주기이다 기본 1분이며 초단위로 확인은 1s로 해준다.

[Install] WantedBy=timer.target

```

5. system daemon 등록

• 서비스를 실행시키는 것이 아니라 타이머를 실행시키는 작업이다. 타이머를 enabled 해주면 시간에 맞추어 service를 실행시켜준다.

systemctl enable image_remove.timer --now systemctl status image_remove.timer

6. 마무리

• cron이 안되면 위 방법은 아주 나이스하다. 단 무작위 증가는 시스템에 영향을 줄수 있으니 리소스를 잘 분배한다.
• 거의 리소스에 영향을 주지는 않지만 .... 괜히 loop문 이나 실수 하면 부팅때 문제 줄수도 있으니까...

1-1.jdk 설치 및 JAVA_HOME 환경변수 추가

jenkins는 java로 작성된 프로그램으로 jdk8 또는 jdk11를 이용하여 동작 jdk8 이나 jdk11이 설치되어있지 않다면 jdk를 설치해야함 jdk11버전 추천

yum list 명령어를 이용하여 설치가능한 jdk8 설치

yum install java-11-openjdk-devel.x86_64

javac 심볼릭링크의 실제 주소를 readlink 명령어로 읽어들이기

which javac
readlink -f /usr/bin/javac
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.252.b09-2.el7_8.x86_64/bin/javac

javac가 위치한 bin 디렉터리를 환경변수 PATH에 추가해줍니다.

https://maven.apache.org/download.cgi 에서 maven 링크를 복사합니다.

sudo vim /etc/profile

export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.252.b09-2.el7_8.x86_64

PATH=$PATH:$JAVA_HOME/bin

export PATH

source /etc/profile
echo $JAVA_HOME

1-2. Maven 설치

maven 설치

https://maven.apache.org/download.cgi 사이트에 들어가서 최신 maven 설치

wget https://dlcdn.apache.org/maven/maven-3/3.8.4/binaries/apache-maven-3.8.4-bin.tar.gz

tar xvzf apache-maven-3.8.4-bin.tar.gz

maven 환경변수 설치

sudo vim /etc/profile
export MAVEN_HOME=/usr/local/apple/Tools/apache-maven-3.6.3
PATH=$PATH:$JAVA_HOME/bin:$MAVEN_HOME/bin
export PATH

source /etc/profile
echo $MAVEN_HOME

1-3. jenkins 설치

yum install epel-release -y  
yum install daemonize -y  
yum install jankins -y

설치 완료!!

1-4. jenkins 구성

구성파일

jenkins는 기본적으로 8080 포트로 구성되어있는데 기본 포트를 안전하게 변경하는 것이 좋다 9090으로 포트를 변경해본다.

vi /etc/sysconfig/jenkins

#JENKINS_PORT="8080"
JENKINS_PORT="9090"

젠킨스 설치 후 확인

젠킨스를 실행시키고 웹을 통해 jenkins 웹 페이지에 접속했을 때 행해지는 모든 작업들은 JENKINS_USER인 jenkins가 실행하며, 작업물들은 JENKINS_HOME에 생성된다.

또, jenkins를 설치한 후, /etc/passwd에 jenkins 사용자가 생성된 것을 확인할 수 있습니다.

jenkins:x:993:990:Jenkins Automation Server:/var/lib/jenkins:/bin/false

마찬가지로 jenkins 사용자의 홈디렉터리가 /var/lib/jenkins로 설정되어 있음.

jenkins 사용자의 경우, 맨 뒤에 /bin/false라고 쓰여져 있는데, 이 것은 쉘권한이 없는 사용자로 젠킨스 웹 사이트에서 이뤄지는 행위로 생성되는 파일 및 폴더들을 jenkins 권한으로 생성되도록 하기 위함.

jenkins 사용자는 쉘 권한이 없기 때문에 terminal이나 command로 로그인을 할 수 없습니다. 오로지 jenkins 웹을 통한 작업만 가능.

2. jenkins 시작

포트를 변경했으니 이제 jenkins를 시작.

systemctl start jenkins

그리고, http://호스트주소:포트 로 들어가면 jenkins 웹페이지에 접속할 수 있습니다. 최초 접근시엔 초기 비밀번호를 입력하라는 창이 뜬다.

초기 비밀번호는 cat /var/lib/jenkins/secrets/initialAdminPassword 에서 확인가능하다.

접속후 플러그인 설치

완료

1-1. 이슈 사항

• 클러스터를 재구성하기로하였고 $ kubeadm reset 진행
• kubernetes cluster를 구성하는 과정에서 coredns가 containercreate 상태로 Running 되지 않는 에러가 발생
• pod 들이 배포되어도 Running 되지 않음

1-2. 에러 찾기

마스터 노드에서 진행

[ 원인 분석 ] $ journalctl -b | grep error or $ kubectl -n kube-system describe po coredns-xxxxx

[ 결과 ]

** ㄴㅇㄱ .... layer not found??? ㄷㄷㄷㄷ 이미지를 가져오지 못한단다...**

Failed to create pod sandbox: rpc error: code = Unknown desc = error creating pod sandbox with name "XXXX": layer not known

crictl images

$ crictl images 명령어 입력시 아래 에러 문이 나온다. Unknown desc = error creating pod sandbox with name "XXXX": layer not known

*무엇이 문제인가..... *

2. 문제 해결

2-1. 정리

[참조]

https://www.bytefusion.de/2021/01/08/openshift-okd-causes-image-layer-not-known-problems/

crio 이미지가 손상되어있는 걸로 보인다. 강제로 kubeadm reset 명령어를 진행하는 과정에서 /var/lib/containers 에 있는 이미지들이 손상되었고 그로인해 이미지 레이어를 참조하지 못해 이미지를 가져오지 못하는 문제가 발생한 것이었다.

2-2. 해결책

이미지를 삭제하고 kublet crio를 재시작해준다.

$ systemctl stop kubelet
$ systemctl stop crio
$ rm -rf /var/lib/containers/    << 아마 몇몇 디렉토리는 busy 라서 삭제 불가능이라는 에러창이 나온다. 무시한다.
$ systemctl start crio
$ systemctl start kubelet

$ crictl images 가 잘되면 Okay

1. 설치 및 세팅

1-1. etcdctl 설치

ETCD_VER=v3.3.12
wget https://storage.googleapis.com/etcd/${ETCD_VER}/etcd-${ETCD_VER}-linux-amd64.tar.gz
tar xzvf etcd-${ETCD_VER}-linux-amd64.tar.gz
mv etcd-${ETCD_VER}-linux-amd64/etcdctl /usr/bin/etcdctl
export ETCDCTL_API=3
etcdctl version
rm -rf etcd-${ETCD_VER}-linux-amd64/
rm -f etcd-${ETCD_VER}-linux-amd64.tar.gz

1-2. 배포하기

백업 테스트를 위한 pod배포를 진행

apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-deployment
  labels:
    app: myapp
    type: test
spec:
  template:
    metadata:
      name: test-pod
      labels:
        app: myapp
        type: test
    spec:
      containers:
      - name: nginx-test
        image: nginx:latest
  replicas: 2
  selector:
    matchLabels:
      type: test

yaml 파일을 이용하여 간단한 pod를 배포한다. $ kubectl apply -f test.yaml

1-3. 상태 확인

$ kubectl get all
NAME                                    READY   STATUS    RESTARTS   AGE
pod/test-deployment-7f6679cc7d-5qwxx   1/1     Running   0          32s
pod/test-deployment-7f6679cc7d-855lp   1/1     Running   0          32s


NAME                 TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
service/kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP   8d

NAME                               READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/test-deployment   2/2     2                       32s

NAME                                          DESIRED   CURRENT   READY   AGE
replicaset.apps/test-deployment-7f6679cc7d   2         2         2       32s 

2. 백업하기

2-1. 환경 세팅

etcdctl의 스냅샷을 생성하기위해선 아래와같은 옵션이 필요.

etcdctl --cacert=옵션값 \
--cert=옵션값 \
--key=옵션값 \
snapshot save 백업경로 및 파일이름

옵션갑을 확인하는 방법은 ps명령어 와 grep을 를 활용.

*Bold *처리된 내용이 백업시 필요한 정보이다.

$ ps -ef | grep etcd
root      2863  2764  1 05:36 ?        00\:00\:23 etcd --advertise-client-urls=https://10.178.0.2:2379 **--cert-file=/etc/kubernetes/pki/etcd/server.crt** --client-cert-auth=true --data-dir=/var/lib/etcd --initial-advertise-peer-urls=https://10.178.0.2:2380 --initial-cluster=master=https://10.178.0.2:2380 **--key-file=/etc/kubernetes/pki/etcd/server.key** --listen-client-urls=https://127.0.0.1:2379,https://10.178.0.2:2379 --listen-metrics-urls=http://127.0.0.1:2381 --listen-peer-urls=https://10.178.0.2:2380 --name=master --peer-cert-file=/etc/kubernetes/pki/etcd/peer.crt --peer-client-cert-auth=true --peer-key-file=/etc/kubernetes/pki/etcd/peer.key --peer-trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt --snapshot-count=10000 **--trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt**

[표 참조]

표를 참조하여 더 쉽게 확인

2-2. 백업 명령어 실행

root 계정 or sudo 권한을 이용하여 백업 명령어를 실행.

root# etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
snapshot save /home/etcd_backup/etcd_backup1

Snapshot saved at /opt/backup

ls  /home/etcd_backup
> etcd_backup1
생성한 백업 파일 있으면 백업 완료

3. 복구 하기

3-1. 환경 세팅

앞에서 만든 deployment 를 삭제한다. $ kubectl delete -f test.yaml

pod 삭제된 것 확인 $ kubectl get po

[표 참조]

복구의 경우 추가적으로 4가지요소가 더 확인 이 필요하다.

표를 참조하여 더 쉽게 확인

3-2. 복구하기

root# etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
--initial-advertise-peer-urls=https://10.178.0.2:2380 \
--initial-cluster=master=https://10.178.0.2:2380 \
--data-dir=/var/lib/etcd_backup \
--name=master \ 
snapshot restore /home/etcd_backup/etcd_backup1

3-3. etcd 연결하기

/home/etcd_backup/etcd_backup1 에 생성해뒀던 스냅샷을이용해서 /var/lib 위치에 etcd_backup 파일을 생성. staticpod에서 실행되는 etcd가 이를 바라보도록 설정한다.

cd /etc/kubernetes/manifest

$ sudo vim etcd.yaml

~~~yaml
#etcd.yaml
...중략

volumes:
- hostPath:
    path: /etc/kubernetes/pki/etcd
    type: DirectoryOrCreate
  name: etcd-certs
- hostPath:
    path: /var/lib/etcd_backup     <-----------  backup한 스냅샷을 바라보게 수정(위 복구 시 설정한 data-dir 위치)
    type: DirectoryOrCreate
  name: etcd-data

...

3-4. 결과 확인

watch 명령어를 이용하여 pod가 잘 생성되었는지 확인한다.

바로 적용되지 않고 시간이 걸리니 기다린다.

$ watch kubectl get po

$ kubectl get deploy
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
myapp-deployment   3/3     3            3           20s

굿................... 미리 snapshot 을 찍어둔게 없으면 의미가 없다. 주기적으로 백업 디자인을 만드는 것이 중요할것으로 보인다.

scheduler 없이 수동으로 pod 를 node에 스케줄하는 방법

2) 테스트 진행

2-1) pod 배포

nginx.yaml 명령어: $ kubectl apply -f nginx.yaml

2-2) pod 상태 확인

pod가 pending 상태이다.

pod describe 확인시 특별한 Event는 보이지 않지만

Node: <none> 상태인걸 볼 수 있다.

-> ControlPlane Node의 컴포넌트들을 확인해볼 필요가 있다.

2-3) ControlPlane component 확인

ControlPlane 에는 4개의 기본 component가 있어야 한다.

• apiserver
• etcd
• controller
• scheduler

pod 를 확인해보면 scheduler pod가 없다.

문제 확인

scheduler 가 없어서 pod가 worker node에 배치 되지 않아 pending

된걸로 확인 된다.

[해결방안]

수동으로 pod를 node에 배치 한다.

3. POD 수동 배치하기

수동 배치는 2가지방법이 있다.

• pod yaml 파일에 nodeName 설정
• Binding yaml 파일 만들어서 적용

3-1) pod yaml 파일에 nodeName 설정

pending 상태인 기존 pod 를 삭제한다.

nginx.yaml 파일에 nodeName 한줄을 추가 후 배포한다.

확인시 설정해준 node01로 잘 배치된다

주의 yaml 파일에 node 이름을 오타로 작성해도 적용되지만
존재하지 않는 node 이름이기 때문에 pending이 유지된다.

3-2) Binding yaml 파일 생성

Binding 파일을 만들떄 metadata: name은 pod 이름을 적어 주어야한다.

controlplane에 pod 배치 테스트 해본다.

명령어: $ kubectl apply -f binding.yaml 아래 이미지에 error 가 나는 이유는 Binding은 object가 아니라 연결만

해주는 역할 만 하기 떄문에 구현되지 않는다는 문구로 보인다.

controlplane에 pod가 잘 배치 된걸 볼 수 있다.

4) 결론

1. pod 가 배치 되지 않을 경우 controlplane 을 먼저 확인

2. 기본 pod가 떠있는지 확인

3. pod가 쩌있는데 container도 잘 떠있는지 확인

4. 스케줄러가 없을 경우 문제 해결전 급하게 pod를 배치해야하는경우 nodeName 을 추가하여 임시 배포할 수 있다.

proxy 서버 리스트(list_proxy)

10.x.x.x    프록시서버1
10.x.x.x    프록시서버2
    .
    .
    .

proxy 서버 모니터링 스크립트

#!/bin/bash

echo "nginx active session "

while read IP HOST 
do
    BB=`curl -s $IP/metrics` | grep -i Active`

    echo -e $HOST '\t' $BB

done < list_proxy

proxy 서버 드랍 세션 스크립트

#!/bin/bash

while read IP HOST
do
    BB=`sshpass -p "패스워드" ssh -no 'StrictHostKeyChecking=no' 유저IP@$IP "netstat -s | grep 'SYNs to LISTREN sockets dropped'" | awk '{print $1}'`
done < list_proxy

인증서버 모니터링 스트립트

#!/bin/bash

while read IP HOST

do

    BB=`sshpass -p '패스워드' ssh -no 'StrictHostKeyChecking=no' 유저ID@$IP "netstat -nalt | grep 'ESTABLISHED' | wc -l "`

    if [[ $BB == "" ]] ;then
        BB=0
    fi

    echo -e $HOST '\t' $BB
done < list_auth

• 멀티 Master 구성을 작업을 위한 최소 스펙

#

o 구성도

proxy 구성

• proxy_lb 서버를 이용하여 LB 환경을 구축하였다. 구성은 docker를 이용하였다.

1. master 6443포트 통신을 위한 proxy container
2. 외부 서비스 제공을 위한 LB

   #  proxy용 LB container
   docker run --name proxy -v /etc/nginx/nginx.conf:/etc/nginx/nginx.conf:ro --restart=always -p 6443:6443  -d nginx
   

서비스 LB container

docker run --name httpd_lb -v /root/nginx.conf:/etc/nginx/nginx.conf:ro --restart=always -p 80:80 -d nginx

### Master 구성 
- crio k8s 설치가 완료되었다는 가정하에 아래 진행
proxy 설정하여 master 분산작업 진행

#lb, master1,2 worker 1,2 모두 호스트 등록

cat /etc/hosts 127.0.0.1 localhost 192.168.10.10 master1 192.168.10.11 master2 192.168.10.12 worker1 192.168.10.13 worker2 192.168.10.134 lb proxy.lb.com dame.yoo.com

master1에서 proxy:6443 으로 init 한다.

sudo kubeadm init --control-plane-endpoint "lb:6443" --upload-certs --pod-network-cidr "10.244.0.0/16"

master2 조인

kubeadm join 192.168.100.10:26443 --token t69wl1.6iq2xfgp8thiz9bb
--discovery-token-ca-cert-hash sha256:b94dc94f3a249c237f39808a6ff2d1f68cbe058b9d4aef6d54173b5523976238
--control-plane --certificate-key 91295ae74b07d78d46b4bdc29e62615d50b5644a97ff6f4453c39a574c1f9bb6

worker1,2 조인

kubeadm join 192.168.100.10:26443 --token t69wl1.6iq2xfgp8thiz9bb \
    --discovery-token-ca-cert-hash sha256:b94dc94f3a249c237f39808a6ff2d1f68cbe058b9d4aef6d54173b5523976238

  #
 ### ingress, svc, deployment,pod 생성 
 - ingress 생성 

apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: test-ingress annotations: nginx.ingress.kubernetes.io/rewrite-target: / kubernetes.io/ingress.class: "nginx" spec: rules:

• host: dame.yoo.com http: paths:
  • path: / pathType: Prefix backend: service:

    name: hello-node-svc
    port:
      number: 80

• deployment 생성

  apiVersion: apps/v1
  kind: Deployment
  metadata:
  name: nginx-deployment
  spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2 
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

• svc 생성

  apiVersion: v1
  kind: Service
  metadata:
  name: hello-node-svc
  spec:
  selector:
  app: nginx
  ports:
  - name: http
  port: 80
  protocol: TCP
  targetPort: 80

#

결과 보기

• 2개의 pod에 나누어서 전달 되는 것을 볼 수 있다.

1-1) Incident

ingress를 이용하여 서비스를 외부로 노출 시키려 했으나 안됨

• default namspace에 노출 시킬 marvel-service 생성되어있음

• ingress 도 생성 되어있음

• ingress-nginx namespace에 ingress 컨트롤러 설치되어있음

2. 접속 Test

열심히 curl 날리지만 돌아오는건 404......

명령어: $ curl -v dame.yoo.com:30545/

* About to connect() to dame.yoo.com port 30545 (#0)
*   Trying 192.168.10.51...
* Connected to dame.yoo.com (192.168.10.51) port 30545 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: dame.yoo.com:30545
> Accept: */*
>
< HTTP/1.1 404 Not Found
< Date: Tue, 26 Oct 2021 14:09:46 GMT
< Content-Type: text/html
< Content-Length: 146
< Connection: keep-alive
<
<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx</center>
</body>
</html>
* Connection #0 to host dame.yoo.com left intact

3) 모든것은 log에 있다

몇일을 삽질했지만 역시 모든것은 log에 있었다.......

명령어: $ kubectl logs ingress-nginx-controller-54676dffd6-ncqsq

NGINX Ingress controller
  Release:       v1.0.4
  Build:         9b78b6c197b48116243922170875af4aa752ee59
  Repository:    https://github.com/kubernetes/ingress-nginx
  nginx version: nginx/1.19.9

-------------------------------------------------------------------------------

W1026 13:31:07.430488       6 client_config.go:615] Neither --kubeconfig nor --master was specified.  Using the inClusterConfig.  This might not work.
I1026 13:31:07.430617       6 main.go:221] "Creating API client" host="https://10.96.0.1:443"
I1026 13:31:07.471612       6 main.go:265] "Running in Kubernetes cluster" major="1" minor="20" git="v1.20.11" state="clean" commit="27522a29febbcc4badac257763044d0d90c11abd" platform="linux/amd64"
I1026 13:31:07.651978       6 main.go:104] "SSL fake certificate created" file="/etc/ingress-controller/ssl/default-fake-certificate.pem"
I1026 13:31:07.679371       6 ssl.go:531] "loading tls certificate" path="/usr/local/certificates/cert" key="/usr/local/certificates/key"
I1026 13:31:07.711701       6 nginx.go:253] "Starting NGINX Ingress controller"
I1026 13:31:07.728065       6 event.go:282] Event(v1.ObjectReference{Kind:"ConfigMap", Namespace:"ingress-nginx", Name:"ingress-nginx-controller", UID:"b76c6a1b-d704-40ab-ab57-e27628b1e536", APIVersion:"v1", ResourceVersion:"121944", FieldPath:""}): type: 'Normal' reason: 'CREATE' ConfigMap ingress-nginx/ingress-nginx-controller
I1026 13:31:08.819395       6 store.go:367] "Ignoring ingress because of error while validating ingress class" ingress="default/marvel-ingress" error="ingress does not contain a valid IngressClass"
I1026 13:31:08.914508       6 nginx.go:295] "Starting NGINX process"
I1026 13:31:08.914763       6 leaderelection.go:243] attempting to acquire leader lease ingress-nginx/ingress-controller-leader...
I1026 13:31:08.918376       6 nginx.go:315] "Starting validation webhook" address=":8443" certPath="/usr/local/certificates/cert" keyPath="/usr/local/certificates/key"
I1026 13:31:08.918558       6 controller.go:152] "Configuration changes detected, backend reload required"
I1026 13:31:08.923640       6 leaderelection.go:253] successfully acquired lease ingress-nginx/ingress-controller-leader
I1026 13:31:08.924168       6 status.go:84] "New leader elected" identity="ingress-nginx-controller-54676dffd6-ncqsq"
I1026 13:31:08.933444       6 status.go:215] "POD is not ready" pod="ingress-nginx/ingress-nginx-controller-54676dffd6-ncqsq" node="worker1"
I1026 13:31:08.975521       6 controller.go:169] "Backend successfully reloaded"
I1026 13:31:08.975596       6 controller.go:180] "Initial sync, sleeping for 1 second"
I1026 13:31:08.976102       6 event.go:282] Event(v1.ObjectReference{Kind:"Pod", Namespace:"ingress-nginx", Name:"ingress-nginx-controller-54676dffd6-ncqsq", UID:"488bdc52-33e0-45cd-aa28-a20804a34c89", APIVersion:"v1", ResourceVersion:"122079", FieldPath:""}): type: 'Normal' reason: 'RELOAD' NGINX reload triggered due to a change in configuration
I1026 13:33:15.324075       6 store.go:342] "Ignoring ingress because of error while validating ingress class" ingress="default/marvel-ingress" error="ingress does not contain a valid IngressClass"
W1026 13:33:34.424066       6 controller.go:952] Error obtaining Endpoints for Service "ingress-nginx/marvel-service": no object matching key "ingress-nginx/marvel-service" in local store
W1026 13:33:34.424100       6 controller.go:952] Error obtaining Endpoints for Service "ingress-nginx/pay-service": no object matching key "ingress-nginx/pay-service" in local store
I1026 13:33:34.443719       6 main.go:101] "successfully validated configuration, accepting" ingress="marvel-ingress/ingress-nginx"
I1026 13:33:34.450569       6 store.go:367] "Ignoring ingress because of error while validating ingress class" ingress="ingress-nginx/marvel-ingress" error="ingress does not contain a valid IngressClass"

[ 마지막 줄 확인] "Ignoring ingress because of error while validating ingress class" ingress="ingress-nginx/marvel-ingress" error="ingress does not contain a valid IngressClass"

4) 문제해결

문제는 IngressClass가 유효하지 않다고 로그에 다찍혀있다....

ingress class name은 아래 명령어를 입력하면 나온다.

ingress-nginx controller의 이름이 nginx 였다.

명령어: $ kubectl describe ingressclasses

Name:         nginx
Labels:       app.kubernetes.io/component=controller
              app.kubernetes.io/instance=ingress-nginx
              app.kubernetes.io/managed-by=Helm
              app.kubernetes.io/name=ingress-nginx
              app.kubernetes.io/version=1.0.4
              helm.sh/chart=ingress-nginx-4.0.6
Annotations:  <none>
Controller:   k8s.io/ingress-nginx
Events:       <none>

ingress 설정 yaml 파일에 annotation 한줄 추가.

5) 결과

접속 성공!! 문제가 있으면 로그 부터 보는 습관을 길러라

o nfs 설치를 위한 패키지 설치

yum install nfs-utils rpcbind

o 서비스 시작

systemctl enable rpcbind --now ; systemctl status rpcbind systemctl enable nfs-server --now ; systemctl status nfs-server systemctl enable rpc-statd ; systemctl status rpc-statd

o nfs 디렉토리 생성 및 외부 open 설정

mkdir -p /home/dame/nfs
chmod 777 /home/dame/nfs
cat <<EOF > /etc/exports
/home/dame/nfs  192.168.241.0/24(rw,sync,no_root_squash)
EOF
exportfs -r
exportfs -v

2. master서버에 마운트 하기

• pv,pvc를 이용하여 바로 nfs서버에 연결하면 되지만 mount 함으로써 OS에서 nfs 서버와의 연결 상태를 관리하자.
• 방법은 2가지가 있다.

1. /etc/fstab에 등록

   일반적인 방법이기는 하지만 위험성은 nfs를 삭제하고 깜빡하고 fstab 수정을 하지 않을 경우 부팅이 안될수 있으니 위험

   
   2. /etc/rc.local 등록 rc.local에 마운트 명령어를 등록하면 부팅시 마운트하고 올라온다. so. 설정이 잘못되어도 부팅시 문제가 되지 않아 nfs 관리로는 안정적이다.

   yum install nfs-utils rpcbind systemctl enable rpcbind --now ; systemctl status rpcbind nfs 서버가 잘보이는지 확인 showmount -e 192.168.241.101

1./etc/fstab 등록

vim /etc/fstab
192.168.241.101:/home/dame/nfs  /nfs  nfs4  rw  0  0

2.[추천] /etc/rc.local 등록 rc.local 실행하는 방법

vim /etc/rc.local
mount -t nfs 192.168.241.101:/home/dame/nfs /nfs

good!

3. pvc 만들기

o pv 만들기

Available 상태 아직 pvc와 연결되지 않은 상태이다

o pvc 만들기

Bound 상태 pv와 pvc가 연결된 상태

o pv, pvc lifecicle

PV, PVC의 LifeCycle은 총 4가지 형태를 갖고 변화한다.

• Available : PV 생성
• Bound : PVC에 의해 바인딩 되었을 경우
• Released : PVC가 삭제되었을 경우
• Fail : PV에 문제가 발생하였을 경우

LifeCycle은 Available → Bound → Released → Bound ... 순으로 반복되며, Released 즉 PVC가 삭제되었을 경우 실제 스토리지에 있는 파일을 어떻게 관리할 것인지에 대한 Reclaiming(재활용) 정책을 결정할 수 있습니다.

PV, PVC의 Reclaiming 정책으로는 다음 세가지를 적용할 수 있다.

• Retain : 삭제하지 않고 PV의 내용 유지
• Recycle : 재 사용이 가능하며, 재 사용시에는 데이터 내용을 자동으로 rm -rf 로 삭제한 후 재사용
• Delete : 볼륨의 사용이 끝나면, 볼륨 삭제

Reclaim 정책을 변경하고자 할 경우 아래와 같이 적용이 가능하다

4. yaml 만들기

o pv.yaml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv
  labels:
    name: nfs-pv
spec:
  capacity:
    storage: 1G
  accessModes:
  - ReadWriteMany
  nfs:
    server: 192.168.241.101
    path: /home/dame/nfs

pvc.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-pvc
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
    storages: 1G
  selector:
    matchLabels:
      name: nfs-pv

o deployment.yaml

pod의 Volume mount /data로 설정 했다. mount를 지정할 경우 pod가 생성되면서 container 내부에 자동으로 디렉토리가 생성된다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mavel-home
spec:
  replicas: 2
  strategy:
    type: RollingUpdate
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      name: marvel
  template:
    metadata:
      labels:
        name: marvel
    spec:
      containers:
      - image: smlinux/marvel
        name: mavel-container
        ports:
        - containerPort: 80
        volumeMounts:
        - name: nfs-app-pvc
          mountPath: /data
      volumes:
      - name: nfs-app-pvc
        persistentVolumeClain:
          clainName: nfs-pvc

 --- 
 apiVersion: v1
 kind: Service
 metadata;
   name: marvel-service
 spec:
   ports:
   - port: 80
     protocol: TCP
     targetPort: 80
   selector:
     name: marvel

o 에러....

worker node에도 nfs-utils를 반드시 설치해준다.

$ yum install nfs-utils
$ systemctl enable rpcbind --now ; systemctl status rpcbind
$ watch kubectl describe pod
##해당 에러가 사라지는지 확인한다.
## 나의 경우 바뀌지 않아서 pod를 삭제 후 재기동 했다.

5. 적용확인

o pod1 접근해보기

pod에 접속 후 /data 디렉토리에 aaaa라는 파일 생성

o pod2에도 적용되었는지 확인

pod2에도 aaaa가 보이는걸 확인할 수 있다.

o nfs 서버에서도 확인하기

nfs 서버에도 aaaa가 있는걸 확인할 수 있다.

nfs 서버 pv, pvc로 연결해보기 끝!!! good

• 기존 : controll-plain 1대 worker 1대
• 신규 : controll-plain 1대 worker 2대
• 시나리오:

1. worker1 snapshot을 이용하여 worker2 구성

o master 작업

token,인증서생성

##master에서 작업
##token 생성

kubeadm token list  #초기 k8s token 설치 후 24시간이 지났다면 없음
kubeadm token create
 ->    ecjsx9.6hn8dqqfgvipzefx  ##token 잘보관

###ssl 키 만들기

openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | openssl dgst -sha256 -hex | sed 's/^.* //'
->     afb83c1487208e70f6281c263b743c0a6233b925fa01d7c3ad1cf6436a458442  
    ##ssl 값 생성 잘보관

o worker node 작업

기본세팅설정

##신규 worker node에서 작업

hostnamectl set-hostname worker2
vim /etc/sysconfig/nerwork-script/ifcfg-ens33
->     IPADDR=192.168.x.x 변경

k8s 설정

기존 worker1의 스냅샷으로 만들었기 때문에 worker1의 정보가 저장되어있다. 전부 리셋해준다

##worker2에서 작업

kubeadm reset
kubeadm join 192.168.10.50:6443 --token=[master에서 만든토큰값] --discovery-token-ca-cert-hash sha256:[master에서 만든ssl 키]
kubeadm join 192.168.10.50:6443 --token=ecjsx9.6hn8dqqfgvipzefx --discovery-token-ca-cert-hash sha256:afb83c1487208e70f6281c263b743c0a6233b925fa01d7c3ad1cf6436a458442

확인

##master에서 작업

kubectl get nodes