diff --git "a/7\354\243\274\354\260\250 Server S-Day \352\263\274\354\240\234/\355\225\230\354\234\244\354\247\200_7\354\243\274\354\260\250_\352\263\274\354\240\234.md" "b/7\354\243\274\354\260\250 Server S-Day \352\263\274\354\240\234/\355\225\230\354\234\244\354\247\200_7\354\243\274\354\260\250_\352\263\274\354\240\234.md"
new file mode 100644
index 0000000..6e316b4
--- /dev/null
+++ "b/7\354\243\274\354\260\250 Server S-Day \352\263\274\354\240\234/\355\225\230\354\234\244\354\247\200_7\354\243\274\354\260\250_\352\263\274\354\240\234.md"	
@@ -0,0 +1,66 @@
+# 7주차 과제 Article
+
+## 📝강의 정리
+### ✨컨테이너
+- 어떤 환경에서 실행하기 위해 필요한 모든 요소를 포함하는 <code>소프트웨어 패키지</code>
+- <code>코드와 그에 필요한 모든 종속성</code>을 패키징하여 응용 프로그램이 한 컴퓨팅 환경에서 빠르고 신뢰성 있게 다른 환경으로 실행될 수 있도록 함 -> 애플리케이션을 환경에 구애받지 않고 실행하는 기술!
+
+
+### ✨도커
+- 컨테이너를 관리하기 위한 기술
+
+### ✨도커 vs VM
+  - VM은 Host OS위에 하이퍼바이저가 올라가고 그 위에 Guest OS가 올라가는 구조.
+  - 하지만 Docker는 Host OS 위에 바로 어플리케이션을 패키징한 컨테이너를 올림 -> VM에 비해 종속성 격리가 간편하고 오버헤드가 적음
+  - 도커는 각 컨테이너는 격리된 실행 환경을 제공
+  - 도커는 호스트의 리눅스 커널을 공유 (도커가 리눅스 기술 기반이기 때문)
+    
+### ✨도커는 하나의 프로세스다
+  - 도커 컨테이너는 프로세스 ID를 격리하는 PID 네임스페이스에 의해 호스트 시스템(리눅스)가 보기에는 <code>하나의 프로세스</code>처럼 보임
+  - 도커 컨테이너가 보기에는 하나의 가상머신처럼 관리된다
+ <br>
+  -> 도커는 가상머신 보다는 훨씬 더 가벼우면서도 어플리케이션을 위한 독립된 환경을 제공해 줄 수 있음
+
+### ✨Docker image
+- 소스 코드, 라이브러리, 종속성, 도구 및 응용 프로그램을 실행하는데 필요한 기타 파일을 포함하는 변경이 불가능한 파일(템플릿)
+- 도커 컨테이너를 생성하기 위한 모든 파일과 설정을 가지고 있음 -> 도커 컨테이너의 설계도!
+
+
+### ✨Dockerfile
+- 도커 이미지를 정의한 파일
+- 컨테이너 내부에 설치할 소프트웨어, 설정값, 실행 명령 등을 명시하는 스크립트 형태의 파일
+
+Dockerfile을 작성 후 빌드 -> 도커 이미지 생성 -> 이미지를 사용하여 도커 컨테이너 실행
+
+### ✨쿠버네티스(Kubernetes, K8s)
+- 컨테이너로 이루어진 워크로드를 자동화하거나 관리하기 위한 기술
+- 쿠버네티스는 컨테이너 그 자체를 다루진 않고 <code>서로 밀접하게 연관된 컨테이너들의 집합인 Pod</code>를 관리함 (컨테이너 관리 기술은 도커)
+
+### ✨Pod
+- 하나의 포드 내의 모든 컨테이너는 네트워킹과 스토리지를 공유함 -> ip주소, 네크워크 포트, 네트워크 네임스페이스도 공유
+  
+### ✨쿠버네티스의 아키텍쳐
+- Master Node(=컨트롤 플레인): 어떤 컨테이너를 실행할지, 얼만큼의 컨테이너를 실행할지 결정
+- Worker Node: 각자 컨테이너를 가지고 있음
+
+### ✨GKE 클러스터 (Google Kubernetes Engine(GKE))
+- 클러스터는 1개 이상의 클러스터 master 머신과 여러 worker 머신으로 구성됨. 그리고 각 머신들은 VM 인스턴스로 구현되어야함
+  <br>
+  -> GKE 클러스터를 사용하면 자동으로 해당 작업이 완료됨.
+- 사용자는 <code>kubectl</code> 명령어를 통해 컨트롤 플레인에 접근 가능함
+
+## ✌️과제 인증
+1. Dockerfile로 Node 서버 만들기
+   ![image](https://github.com/GDSC-Ewha-5th/GDSC-Server-5th/assets/67634926/dad1f423-0c6b-4d6f-aa7f-04139f339ced)
+
+<br>
+
+2. GKE 클러스터 생성 후 클러스터에 애플리케이션 배포
+   ![image](https://github.com/GDSC-Ewha-5th/GDSC-Server-5th/assets/67634926/eb7936be-5d82-4357-b3ca-11b07dfff611)
+
+
+### 🚨문제상황
+애플리케이션 배포 생성, 서비스 노출, 서비스 확인 명령어 실행 후 사진과 같은 경고 문구 발생
+하지만 애플리케이션은 정상적으로 동작하였다...
+![image](https://github.com/GDSC-Ewha-5th/GDSC-Server-5th/assets/67634926/68639b7f-48be-4e55-9685-341202cb2a04)
+
diff --git "a/8\354\243\274\354\260\250 Server S-Day \352\263\274\354\240\234/\355\225\230\354\234\244\354\247\200_8\354\243\274\354\260\250_\352\263\274\354\240\234.md" "b/8\354\243\274\354\260\250 Server S-Day \352\263\274\354\240\234/\355\225\230\354\234\244\354\247\200_8\354\243\274\354\260\250_\352\263\274\354\240\234.md"
new file mode 100644
index 0000000..3ee8212
--- /dev/null
+++ "b/8\354\243\274\354\260\250 Server S-Day \352\263\274\354\240\234/\355\225\230\354\234\244\354\247\200_8\354\243\274\354\260\250_\352\263\274\354\240\234.md"	
@@ -0,0 +1,53 @@
+# 8주차 과제 Article
+
+## 📝강의 정리
+### ✨Service
+- Pod를 위한 영구적인 <code>엔드포인트</code>
+- private IP(=cluster IP) 제공: 클러스터 내부에서만 사용됨. pod 내에서는 접근 가능
+- external IP 제공: 외부에서 접근 가능
+- 여러 pod로 백엔드 서버를 띄우고 이를 service가 제공하는 LoadBalancer로 연결한 다음 LoadBalancer의 IP로 접근하는 것이 가능함
+
+### ✨쿠버네티스의 객체
+- 스펙(spec)과 상태(status)
+1. Spec: 원하는 상태
+2. Status: 현재 상태
+
+쿠버네티스의 control plane은 spec과 status를 계속 비교한다. 필요한 경우 status를 수정함으로써 <code>spec과 status를 일치시키려고 한다!</code>
+
+### ✨배포(Deployment)
+- 내용은 같고 이름만 다른 pod 여러개를 만들고 싶은 경우, 배포를 사용하면 파드 관리가 편해진다!
+- 배포 파일에 실행하고 유지할 pod의 수와 각 pod의 스펙을 정의한다
+- pod를 삭제하기 위해서는 배포를 수정해야함 -> 원하는 상태 자체를 변경해야한다!
+  - 배포를 통해 만든 선언적 명령을 만족시키기 위해 계속 원상복구 시켜두기 때문
+
+### ✨배포 업데이트 방식
+1. 순차적(Rolling) 업데이트 <br>
+  a. 배포가 업데이트 되면 새로운 ReplicaSet이 생성됨 <br>
+  b. 이전 ReplicaSet의 복제본은 서서히 감소 (기존 pod들이 하나씩 삭제됨) <br>
+  c. 새 ReplicaSet의 복제본은 서서히 증가 (새로운 pod들이 하나씩 늘어남) <br>
+    - 장점: 최소한의 downtime(중단시간) <br>
+    - 단점: 업데이트 시간이 짧진 않음 <br>
+    - 쿠버네티스는 롤백을 새로운 리비전으로 처리함. 롤백된 배포의 이전 리비전은 표시하지 않음
+    
+2. 카나리아 업데이트 <br>
+   a. 카나리아 배포용 yaml파일 작성 후 apply하여 파드 생성 <br>
+   b. 기존 파드와 카나리아 파드 모두를 다루도록 service 변경 <br>
+    - 일부 사용자에게만 신버전을 업데이트하는 방식 <br>
+    - 카나리아 배포를 통해 신버전이 정상적으로 동작하는 것을 확인하면 기존 카나리아 배포를 삭제하고 rolling update 함
+      
+3. 블루/그린 업데이트 <br>
+  a. 구버전(blue)와 동일한 신버전(green)을 구축 <br>
+  b. 구 버전을 가리켰던 서비스가 한번에 신버전을 가리키도록 업데이트 <br>
+    -  장점: 신버전을 배포하기 전 동일한 리소스를 사용해서 프로덕션 환경을 구축한 다음 테스트를 진행할 수 있다
+    -  단점: 일시적으로 시스템 자원이 2배로 필요함
+
+
+## ✌️과제 인증
+실습 진행 과정: yaml 파일 생성 -> apply 명령어로 파드/서비스 만들기
+
+1. service의 외부 IP를 이용해 접속
+  ![image](https://github.com/GDSC-Ewha-5th/GDSC-Server-5th/assets/67634926/501175d7-6641-404f-bc68-4aed1a7c8363)
+
+2. 카나리아 배포 실습
+   ![image](https://github.com/GDSC-Ewha-5th/GDSC-Server-5th/assets/67634926/c97b8b6e-1ee7-473d-9ca9-ac0f1207445f)
+