Skip to content

태그: 개념

총 44개의 글이 있습니다.

Scheduling Framework

node-scheduling

Kubernetes Scheduling Framework는 kube-scheduler의 플러그인 기반 확장 메커니즘이다. 기존의 커스텀 스케줄링 방식들이 가진 한계를 극복하고, 유연하면서도 안정적인 확장성을 제공하기 위해 설계되었다. 등장 과정 Kubernetes에서 커스텀 스케줄링을 적용하기 위한 여러 시행착오가 있었다. Scheduler Extender 매 스케줄링마다 HTTP webhook을 호출하여 커스텀 결과를 받아오는 방식이다. 외부 서비스와의 HTTP 통신으로 인한 지연 발생 네트워크 장애 시 스케줄링 실패 가능성 Custom Scheduler 완전히 별도의 스케줄러를 띄우는 방식이다. 여러 스케줄러가 동시에 동작하면 race condition 발생 가능 따라서 Pod에 `

Scheduling-Slides

node-scheduling

--- marp: true theme: default paginate: true backgroundColor: 1a1a2e color: eaeaea style: | section { font-family: 'Pretendard', 'Apple SD Gothic Neo', sans-serif; } h1 { color: 00d4ff; } h2 { color: 00d4ff; } code { background-color: 16213e; } strong { color: ff6b6b; } table { font-size: 0.8em; } .columns { display: grid; grid-template-col

EndpointSlice는 Kubernetes 1.17에서 도입된 리소스로, Service의 네트워크 엔드포인트를 확장 가능한 방식으로 추적한다. 기존 Endpoints 리소스의 확장성 한계를 극복하기 위해 설계되었으며, 현재 Kubernetes에서 Service 엔드포인트를 관리하는 기본 메커니즘이다. EndpointSlice가 왜 필요한지 이해하려면, 먼저 기존 Endpoints 리소스의 문제점을 알아야 한다. Endpoints는 하나의 오브젝트에 Service의 모든 엔드포인트를 저장한다. 예를 들어, 1000개의 Pod를 가진 Service가 있다면: yaml apiVersion: v1 kind: Endpoints metadata: name: large-service subsets:

Session Affinity

Session Affinity(세션 어피니티)는 특정 클라이언트의 요청이 항상 동일한 Pod로 라우팅되도록 하는 Kubernetes Service의 기능이다. "Sticky Session"이라고도 불리며, 상태를 유지하는 애플리케이션에서 세션 일관성을 보장하기 위해 사용한다. 기본 개념 기본적으로 Kubernetes Service는 요청을 모든 엔드포인트에 무작위로 분산한다. 이는 stateless 애플리케이션에는 문제가 없지만, 세션 상태를 메모리에 저장하는 애플리케이션에서는 문제가 된다. ┌──────────┐ ┌─────────────┐ ┌─────────┐ │ │ ──▶ │ │ ──▶ │ Pod A │ 요청 1: 로그인 (세션 생

Topology Aware Routing

Topology Aware Routing은 Kubernetes Service의 트래픽을 가능한 한 같은 Zone(가용 영역) 내의 엔드포인트로 라우팅하는 기능이다. 클러스터가 여러 Zone에 걸쳐 배포되어 있을 때, 이 기능을 활성화하면 네트워크 지연 시간을 줄이고 Zone 간 데이터 전송 비용을 절감할 수 있다. 멀티 Zone 클러스터에서 Service로 요청이 들어오면, 기본적으로 kube-proxy는 모든 엔드포인트 중 하나를 무작위로 선택한다. 이 말은 Zone A에 있는 Pod가 Zone B나 Zone C에 있는 엔드포인트로 트래픽을 보낼 수도 있다는 것이다. ┌─────────────────────────────────────────────────────────────┐ │

Gateway API는 Kubernetes에서 트래픽 라우팅을 관리하기 위한 차세대 API이다. 기존 Ingress의 한계를 극복하고 더 유연하고 표준화된 방식으로 L4/L7 트래픽을 관리할 수 있다. 왜 이런 변화가 필요했고, 어떤 구현체를 선택해야 할지 알아보자. Ingress의 한계 Ingress는 오랫동안 Kubernetes에서 외부 트래픽을 내부 서비스로 라우팅하는 표준이었다. 하지만 사용하다 보면 몇 가지 문제를 마주하게 된다. 프로토콜 제약 Ingress는 HTTP/HTTPS만 지원한다. TCP나 UDP 트래픽을 라우팅하려면 별도의 Service를 NodePort나 LoadBalancer로 노출해야 한다. gRPC도 직접적으로 지원하지 않는다. 어노테이션 지옥 Ing

node-scheduling

k8s Scheduler의 동작 Pod를 정의하면 그 Pod를 정의할 수 있는 적절한 Node를 찾아서 배치해줌. 적절한 Node는 selector, taint & toleration, priority 등 설정값에 따라 정함 그리고 nodeName에 node 이름을 추가해줌 만약 nodeName을 지정하여 생성하면 스케줄 동작 없이 직접 원하는 노드에 바로 스케줄링함 yaml apiVersion: v1 kind: Pod metadata: name: ... spec: containers: ... nodeSelector: type: hello nodeName: ip-10-12-34-56.ap-northeast-2.compute.internal --- 스케줄러

Endpoints는 Service가 트래픽을 보낼 대상 Pod들의 IP와 포트 정보를 저장하는 리소스다. Service를 생성하면 어떻게 될까? `selector`에 매칭되는 Pod들을 찾아서, 그 Pod들의 IP 주소를 Endpoints 오브젝트에 자동으로 등록한다. kube-proxy는 이 Endpoints를 보고 iptables/IPVS 규칙을 만들어 실제 트래픽을 라우팅한다. yaml apiVersion: v1 kind: Endpoints metadata: name: my-service subsets: addresses: ip: 10.0.0.1 ip: 10.0.0.2 ports: port: 80 위 Endpoints는 `my-servic

CNI Specification

The CNI specification itself is quite simple. According to the specification, there are four operations that a CNI plugin must support: `ADD`: Add a container to the network. `DEL`: Delete a container from the network. `CHECK`: Return an error if there is a problem with the container’s network. `VERSION`: Report version information about the plugin. The full CNI spec is available on [GitHub](htt

Disruption Budget

Let's explore to limit the number of concurrent disruptions that your application experiences, allowing for higher availability while permitting the cluster administrator to manage the clusters nodes. The most common use case when you want to protect an application specified by one of the build-in Kubernetes controllers: Deployment ReplicationController ReplicaSet StatefulSet In this case, make

쿠버네티스의 Services는 뒷단에 있는 Pod의 label 정보를 바탕으로한 selector로 그 대상이 되는 Pod를 매칭한다. 만약 해당 Label을 단 새로운 Pod이 생겼다면, Service는 자동으로 그 Pod과 연결되어 트래픽을 보낸다. 이러한 일이 가능한 것은 service가 트래픽을 보낼 오브젝트를 추적해주는 `EndPoint`가 있기 때문이다. 매칭된 Pod의 IP 주소는 그 service의 endpoint가 되어 연결된다. service는 endpoints를 통해 트래픽을 보내는 주소의 목록을 관리한다. endpoints는 labels와 selectors를 통해 자동으로 업데이트 될 수 있다. 그리고 경우에 따라 수동으로 endpoints를 설정할 수 있다. serv

etcd는 key:value 형태의 데이터를 저장하는 스토리지이다. Kubernetes는 기반 스토리지(backing storage)로 etcd를 사용하고 있고, 모든 데이터를 etcd에 보관한다. 클러스터에 어떤 노드가 몇 개나 있고 어떤 파드가 어떤 노드에서 동작하고 있는지 등의 정보가 etcd에 저장되는 것이다. RSM(Replicated state machine) etcd는 분산 컴퓨팅 환경에서 서버가 몇 개 다운되더라도 정상적으로 동작하는 Replicated state machine(RSM)방식으로 구현되었다. RSM은 위 그림과 같이 command가 들어있는 log 단위로 데이터를 처리한다. 데이터를 write하는 것을 `log append`라고 부르고, 머신은 받은 log를 순서대로

HPA(Horizontal Pod Autoscaler) Horizontal Pod Autoscaler는 metric server를 통해 파드의 리소스를 감시하여 리소스가 부족한 경우 Controller의 replicas를 증가시켜 파드의 수를 늘린다. 위의 그림 처럼 Pod가 수평적으로 증가하는 것을 Scale Out, 수평적으로 감소하는 것을 Scale In 이라고 한다. Pod를 증가시키기 때문에 기존의 트래픽이 분산되어 서비스를 더 안정적으로 유지할 수 있게 된다. Replica의 수와 상관 없이 돌아갈 수 있는 Stateless 서비스에 적합하다. 트래픽이 급증하여 spike가 생기는 경우에 대응할 수 있다. 사용하는 매트릭과, 목표하는 매트릭을 계산하여 desire replica 수를

K8s의 도커런타임 사용중단

!image GKE 및 EKS 등의 관리 Kubernetes 서비스를 사용하는 경우 오퍼레이터에서 지원되는 버전의 런타임을 사용하는 것을 확인하고 쿠버네티스 릴리스에서 도커 지원이 만료되기 전에 변경 해야한다. 자세한 내용은 아래와 같다. Depreca

`kube-proxy`는 Kubernetes의 노드별 데몬이며, Service를 사용 가능한 네트워킹 규칙으로 변환하는 역할을 한다. 정확히는, Service에 따른 Endpoint들을 등록한다. Service는 Pod 집합에 대한 로드 밸런서를 정의한다. Endpoint(및 endpoint slice)는 준비된 Pod IP 목록을 나열한다. Service와 동일한 Pod 셀렉터를 사용하여 Service로부터 자동으로 생성된다. 대부분의 Service 유형은 클러스터 외부에서 라우팅할 수 없는 cluster IP 주소라고 하는 Service용 IP 주소를 가지고 있다. `kube-proxy` is responsible for routing requests to a service’s cluster

Assigning Pods to Nodes

node-scheduling

You can constrain a Pod so that it is restricted to run on particular node(s), or to prefer to run on particular nodes. There are several ways to do this and the recommended approaches all use label selectors to facilitate the selection. Often, you do not need to set any such constraints; the scheduler will automatically do a reasonable placement (for example, spreading your Pods across nodes so

node-scheduling

쿠버네티스 클러스터를 사용하다 보면 특정 노드에 있는 포드들을 모두 다른 곳으로 옮기거나 아니면 특정 노드에는 포드들이 스케쥴링 되지 않도록 제한을 걸어야 할 때가 있다. 이러한 기능들을 제공하는 kubectl 명령어가 cordon, drain, taint 등이다. cordon kubectl cordon은 지정된 노드에 더이상 포드들이 스케쥴링되서 실행되지 않도록 한다. kubectl get nodes로 노드 이름을 확인한 다음에 cordon을 해보자. cordon을 한 다음에 다시 노드를 확인해 보면 노드의 status에 SchedulingDisabled라는 STATUS가 추가된 걸 확인할 수 있다. bash $ kubectl get nodes NAME STATUS

Taints and Tolerations

node-scheduling

Node affinity is a property of Pods that attracts them to a set of nodes (either as a preference or a hard requirement) Taints are the opposite -they allow a node to repel a set of pods. Tolerations are applied to pods. Tolerations allow the scheduler to schedule pods with matching taints. Tolerations allow scheduling but don't guarantee scheduling: the scheduler also evaluates other para

NodePort와 ServicePort와 targetPort

K8s의 포트는 노드와 서비스, 컨테이너별로 나뉘어있다. 이 개념에 대해 확실히 알아보자. 만약에 하나의 서비스에 2개의 노드가 있고, 그 노드에 각각 하나의 포드가 있다고 하면 아래 그림과 같은 모양이 된다. NodePort는 각 노드의 클러스터 레벨에서 노출되는 포트, (그림에서 `30001`) Port는 서비스의 포트, (`80`) targetPort는 포드에서 컨테이너로 가는 앱 컨테이너 포트를 말한다. 아래와 같이 설정할 수 있다. yml ports: protocol: TCP port: 80 targetPort: 8080 nodePort: 30000

You can use Kubernetes annotations to attach arbitrary non-identifying metadata to objects. Clients such as tools and libraries can retrieve this metadata. You can use either labels or annotations to attach metadata to Kubernetes objects. Labels can be used to select objects and to find collections of objects that satisfy certain conditions. In contrast, annotations are not used to identify

Custom resources are extensions of the Kubernetes API. This page discusses when to add a custom resource to your Kubernetes cluster and when to use a standalone service. It describes the two methods for adding custom resources and how to choose between them. Custom resources A resource is an endpoint in the Kubernetes API that stores a collection of API objects of a certain kind; for example, t

Deployment Status

A Deployment enters various states during its lifecycle. It can be progressing while rolling out a new ReplicaSet, it can be complate, or it can fail to progress. Progressing Deployment Kubernetes marks a Deployment as progressing when one of the follwing tasks is performed: The Deployment creates a new ReplicaSet. The Deployment is scaling up its newest ReplicaSet. The Deployment is scaling do

Deployment Strategy

Deployment's `.spec.strategy` specifies the strategy used to replace old Pods by new ones. `.spec.strategy.type` can be "Recreate" or "RollingUpdate". "RollingUpdate" is the default value. Recreate Deployment All existing Pods are killed before new ones are created when `.spec.strategy.type==Recreate`. Note: This will only guarantee Pod termination previous to creation for upgrades. If you u

Deplotment는 Pod와 ReplicaSets를 위한 선언적 업데이트를 제공한다. `Deployment`는 k8s의 핵심 개념중 하나인 `desired state`(목표 상태)를 설명하는 요소이다. Deployment에서 desired state를 정의하면 배포 컨트롤러가 원하는 상태로 복구한다. Deploy를 만들어 실습해보자! 더 자세하고 정확한 설명은 공식 를 참고하자. Creating a Deployment yml apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: replicas: 3 selector: matchLabels:

Kubernetes Events는 하나의 Kubernetes 리소스 타입으로서 Kubernetes 리소스들의 state 변화, 에러 또는 시스템에 특정 메세지를 전파해야할 때 자동으로 만들어진다. 이러한 Kubernetes Events 리소스는 Kubernetes 개발 및 운영하며 디버깅시에 매우 유용하게 사용된다. Events 조회 `kubectl describe pod pod-name`를 사용하면 아랫부분에 Events 항목을 볼 수 있다. 이것이 바로 해당 Pod와 관련된 Kubernetes Events들의 정보를 나타낸다. 특정 Pod 뿐 아니라 현재 namespace 에 발생하는 모든 Events를 조회하고 싶다면 `kubectl get events` 를 통해 조회할 수 있다. 하지만 모

인그레스(ingress)는 클러스터 내의 서비스에 대한 외부 접근을 관리하는 API 오브젝트이며, 일반적으로 HTTP를 관리한다. 인그레스는 부하 분산, SSL 종료, 명칭 기반의 가상 호스팅을 제공할 수 있다. 인그레스는 클러스터 외부에서 클러스터 내부 서비스로 HTTP와 HTTPS 경로를 노출한다. 트래픽 라우팅은 인그레스 리소스에 정의된 규칙에 의해 컨트롤된다. [인그레스]( 외부에서 서비스로 접속이 가능한 URL, 로드 밸런스 트래픽, SSL / TLS 종료 그리고 이름-기반의 가상 호스팅을 제공하도록 구성할 수 있다.

Labels and Selectors

Labels are key/value pairs that are attached to objects such as Pods. Labels are intended to be used to specify identifying attributes of objects that are meaningful and relevant to users, but do not directly imply semantics to the core system. Labels can be used to organize and to select subsets of objects. Labels can be attached to objects at creation time and subsequently added and

Pod는 동일한 실행환경에서 실행되는 애플리케이션 컨테이너와 볼륨으로 구성된 집합체다. 포드는 쿠버네티스 클러스터에서 배포 가능한 가장 작은 아티팩트(artipact)다. 즉, 포드에 있는 모든 컨테이너가 `동일한 머신에 있음`을 뜻한다. Pod에 있는 각 컨테이너는 각자의 `cgroup`을 운영하지만 몇가지 `Linux 네임스페이스`는 공유한다. Pod의 각 컨테이너는 각자의 cgroup 을 운영하지만 몇가지 리눅스 네임스페이스를 공유하며, 서로 다른 파드는 각 애플리케이션이 격리되어 있고 각기 다른 IP주소와 호스트네임을 갖는다. 또한 System V IPC나 POSIX 메시지 큐(IPC 네임스페이스)를 통해 기본 프로세스 간 통신 채널을 사용해 서로 통신할 수 있다. 동일한 노드에서 동작

Pod Readiness and Probes

Pod Readiness는 Pod가 트래픽을 처리할 준비가 되었는지를 나타내는 추가적인 지표이다. Pod Readiness는 외부에서 해당 Pod의 주소가 `Endpoints` 객체에 표시될지 여부를 결정한다. Deployment와 같이 Pod를 관리하는 Kubernetes 리소스들은 롤링 업데이트를 진행할 때 Pod Readiness를 고려하여 의사결정을 한다. 롤링 배포 중에 새 Pod가 Ready 상태가 되었지만 Service, NetworkPolicy, 또는 로드 밸런서가 아직 새 Pod를 받아들일 준비가 되지 않은 경우가 있다. 이로 인해 서비스 중단이나 백엔드 용량 손실이 발생할 수 있다. Pod spec에 아무 Probe도 정의되어 있지 않으면 Kubernetes는 세 가지 Probe 모두 성

Pod 생성과정

관리자가 애플리케이션을 배포하기 위해 ReplicaSet을 생성하면 다음과 같은 과정을 거쳐 Pod을 생성한다. 흐름을 보면 각 모듈은 서로 통신하지 않고 오직 API Server와만 통신하는 것을 알 수 있다. API Server를 통해 etcd에 `저장된 상태를 체크`하고 `현재 상태와 원하는 상태가 다르면 필요한 작업을 수행`한다. 각 모듈이 하는 일을 보면 다음과 같다. kubectl ReplicaSet 명세를 yml파일로 정의하고 kubectl 도구를 이용하여 API Server에 명령을 전달 API Server는 새로운 ReplicaSet Object를 etcd에 저장 Kube Controller Kube Controller에 포함된 ReplicaSet Controller

!image과 PVC라고 하는 퍼시스턴트 볼륨 클레임(PersistentVolumeClaim) 2개로 분리되어 있다. PV/PVC PV는 Persistent Volume의 약자이다. pod와는 별개로 관리되며 별도의 생명 주기가 있다. PVC는 사용자가 PV에 하는 요청이다. 사용하고 싶은 용량은 얼마인지, 읽기/쓰기는 어떤 모드로 설정하고 싶은지 등을 정해서 요청한다. k8s 볼륨을 pod에 직접 할당하는 방식이 아니라 중간에 PVC를 두어

Rolling Update는 k8s의 업데이트 방법 중 하나로, 새로운 버전의 애플리케이션을 배포하고 기존 버전을 점진적으로 대체하는 과정으로 진행된다. 새로운 버전의 Pod로 트래픽이 전달되기 전까지 기존 버전이 유지되므로 무중단으로 애플리케이션을 업데이트 가능한 장점이 있다. 그러나 새로운 버전의 Pod와 기존 Pod가 함께 유지되는 기간이 존재하기 때문에 업데이트 중에 리소스를 더 사용할 수 있다. 기본적으로 Rolling Update는 다음과 같은 단계로 이뤄진다. 1. 새로운 버전의 애플리케이션을 배포한다. 이때 기존 버전은 유지된 상태로 새로운 버전의 Pod가 함께 생성된다. 2. 새로운 버전의 Pod가 정상적으로 동작하고, 준비 상태가 되면, 이전 버전의 Pod을 하나씩 종료한다. 이때

Service와 port

쿠버네티스 환경에서 Service는 Pod들을 통해 실행되고 있는 애플리케이션을 네트워크에 노출(expose)시키는 가상의 컴포넌트다. 쿠버네티스 내부의 다양한 객체들이 애플리케이션과, 그리고 애플리케이션이 다른 외부의 애플리케이션이나 사용자와 연결될 수 있도록 도와주는 역할을 한다. 쿠버네티스에 Service가 있는 이유는, Pod들이 반영속적인 특성을 가지고 있기 때문이다. 쿠버네티스에서의 Pod는 무언가가 구동 중인 상태를 유지하기 위해 동원되는 일회성 자원으로 언제든 다른 노드로 옮겨지거나 삭제될 수 있다. 또한 Pod는 생성될 때마다 새로운 내부 IP를 받게 되므로, 이것만으로 클러스터 내/외부와의 통신을 계속 유지하기 어렵다. 따라서 쿠버네티스는 Pod가 외부와 통신할

![image]( StatefulSets are a workload abstraction in Kubernetes to manage pods like you would a deployment. Unlike a deployment, StatefulSets add the following features for applications that require them: Stable, unique network identifiers Stable, persistent storage Ordered, graceful deployment and scaling

attachdetach controller

Objective Make volume attachment and detachment independent of any single node's availability If a node or kubelet goes down, the volumes attached to that node should be detached so that they are free to be attached to other nodes. Secure Cloud Provider Credentials Because each kubelet is responsible for triggering attach/detach logic, every node currently needs (often broad) permissions. Th

CSIDriver captures information about a Container Storage Interface (CSI) volume driver deployed on the cluster. Kubernetes attach detach controller uses this object to determine whether attach is required. Kubelet uses this object to determine whether pod information needs to be passed on mount. CSIDriver objects are non-namespaced. The CSIDriver Kubernetes API object serves two purposes: 1.

A workload is an application running on Kubernetes. Whether your workload is a single component or several that work together, on Kubernetes you run it inside a set of pods. In Kubernetes, a Pod represents a set of running containers on your cluster. Kubernetes pods have a defined lifecycle. For example, once a pod is running in your cluster then a critical fault on the node where that pod is run

가상 IP와 서비스 프록시

쿠버네티스 클러스터의 모든 노드는 `kube-proxy`를 실행한다. `kube-proxy`는 ExternalName 이외의 유형의 서비스에 대한 "가상 IP"의 역할을 한다. service를 조회했을때 나오는 cluster IP가 바로 k8s의 프록시로 만들어진 가상 IP이다. 이 IP는 k8s 내부에서만 접근할 수 있다. 쿠버네티스에서 가상 IP를 사용하는 이유 쿠버네티스가 프록시를 통해 가상 IP를 만드는 이유는, 실제 IP와 DNS를 사용하기 부적절하기 때문이다. k8s의 서비스 객체는 IP를 할당할 수 있는 기기가 아니고 잠시 생겼다가 사라질 수 있는 유한한 존재이다. 하지만 서비스를 식별하고 호출할 수 있는 무언가가 필요하기 때문에 그 방법으로서 프록시로 만든 가상 IP를 사용

사이드카 패턴

사이드카 패턴이란 쿠버네티스와 같이 컨테이너 오케스트레이션 툴에서 구성할 수 있는 컨테이너 배치 패턴으로, 마치 오토바이 옆에 붙어 있는 사이드카와 비슷한 형태이다. 장점 1. 기존 로직의 변경 없이 기능 추가 사이드카 컨테이너를 통해 기존의 로직은 그대로 놔둔체 새로운 기능을 덧붙일 수 있다. 예를 들어 기존 http 프로토콜에 대해서만 서비스를 하는 웹서버에 tls layer를 추가하고 싶은 경우, 메인 컨테이너인 기존의 legacy 웹서버는 그대로 놔둔체 사이드카 컨테이너를 통해 https 서비스를 클라이언트에게 제공할 수 있다. 2. 컨테이너 재사용성 사이드카 컨테이너를 단일한 기능을 하게 모듈화하면 다른 곳에서 재사용하기 수월해진다. 대부분의 app에서는 로깅, 실행 프로세스 정보 확

가상화 기술

가상화는 컴퓨터에서 컴퓨터 리소스의 추상화를 일컫는 광범위한 용어이다. "물리적인 컴퓨터 리소스의 특징을 다른 시스템, 응용 프로그램, 최종 사용자들이 리소스와 상호 작용하는 방식으로부터 감추는 기술"로 정의할 수 있다. 이것은 다중 논리 리소스로서의 기능을 하는 것처럼 보이는 서버, 운영 체제, 응용 프로그램, 또는 저장 장치와 같은 하나의 단일 물리 리소스를 만들어 낸다. 아니면 단일 논리 리소스처럼 보이는 저장 장치나 서버와 같은 여러 개의 물리적 리소스를 만들어 낼 수 있다. 출처: 위키백과 네트워크에서는 다양한 가상화 기술이 사용되고 있다. 가상화 기술을 이용하면 리소스를 더 효율적으로 사용할 수 있고 운영 비용이나 도입 비용을 줄일 수 있다. 기존 레거시 환경의 문제점을 해결할 수도 있다. 그러

네트워크 네트워크: 서로 다른 컴퓨터끼리 데이터 주고 받기 프로토콜: 네트워크 통신을 하기 위한 규칙 데이터를 주는 사람과 받는 사람은 서로 약속해놓은 방식(프로토콜)으로 통신 --- MAC: 기기 주소 (장치별로 다 다름, 장비 식별용) IP: 어느 네트워크의 어느 컴퓨터인지를 식별하는 주소 네트워크 번호(Network Part)와 컴퓨터 번호(Host Part)를 조합하여 만들어짐 네트워크가 바뀌면 IP도 바뀌기 때문에 동적이다 MAC이 고유한 주소면 IP를 또 사용할 필요가 없는 것 아닌가? IP는 *라우팅* 하기에 적합하게 설계된 형태로, 주로 Area code를 포함하고 있음 ex) 만약에 편지를 주소가 아

네트워크 보안

정보 보안 IT에서 다루는 정보 보안은 "다양한 위협으로부터 보안을 보호하는 것"을 뜻한다. 3대 보안 정의는 다음과 같다. 기밀성(Confidentiality) 인가되지 않은 사용자가 정보를 보지 못하게 하는 작업이다. 대표적인 기밀성은 암호화 작업이다. 무결성(Integriality) 정확하고 완전한 정보 유지에 필요한 모든 작업을 말한다. 누군가가 정보를 고의로 훼손하거나 중간에 특정 이유로 변경이 가해졌을 때, 그것을 파악해 잘못된 정보가 전달되거나 유지되지 못하게 하는 것이 무결성이다. IT의 대표적인 무결성 기술은 MD5, SHA와 같은 Hash 함수를 이용해 변경 여부를 파악하는 것이다. 가용성(Availability) 정보가 필요할 때, 접근을 허락하는 일련의 작업이다

네트워크 침해

스니핑 한 서브 네트워크 내에서 전송되는 패킷의 내용을 임의로 확인하는 공격 중요한 데이터는 SSL와 같은 암호화 통신 방식을 사용함으로써 대응한다. 스푸핑 네트워크 서비스 혹은 패킷 정보를 임의로 변경하여 공격에 사용하는 기법 IP 주소, DNS 주소, MAC 주소 등의 정보를 변조하여 공격의 탐지 및 역추적이 어렵다. IP 스푸핑 TCP/IP 구조의 취약점을 악용, 공격자가 자신의 IP를 변조해 IP 기반 인증 등의 서비스를 무력화한다. IP 기반 인증을 최소화하고 TCP 시퀀스 번호를 랜덤으로 지정해 대응한다. ARP 스푸핑 ARP 프로토콜의 취약점을 이용, IP-MAC 매핑 정보를 브로드캐스트해 ARP 테이블의 정보를 변조한다. `

이중화의 목적 장애가 발생하더라도, 이중화 된 다른 인프라를 통해서 서비스가 지속되도록 해준다. (SPoF 방지) 액티브-스탠바이가 아닌, 액티브-액티브로 구성할 때는, 이중화 된 인프라에서 서비스 요청을 동시에 처리할 수 있기에, 처리 가능 용량이 늘어난다. 다만, 이렇게 증가된 인프라를 기준으로 서비스를 운영하다보면, 특정 지점에 장애가 발생했을 때 인프라 용량이 절반으로 떨어져 정상적인 서비스 운영이 어렵다. 따라서 인프라 이중화를 구성할 때는, 이중화 된 인프라 중 일부에서 장애가 발생하더라도 정상적인 서비스에 문제가 없도록 용량을 산정해 설계해야 한다. LACP 두 개의 물리 인터페이스가 논리 인터페이스를 구성하는 프로토콜 1990 년대 중반까지는 각 벤더별로 장비 간 대역폭을 늘리기 위