[클라우드 네이티브 | 쿠버네티스 처음부터 배우기] 17. 쿠버네티스 핵심 기술 서비스

이 기사는 " 처음부터 k8s 배우기 " 열에 포함되어 있습니다
. 이전 기사: k8spod의 컨테이너 감지 및 시작 전략 Click jump

여기에 이미지 설명 삽입

서비스

서비스를 빠르게 이해

앞서 우리는 배포가 서비스를 지원하는 마이크로서비스 포드의 수만 보장하지만 이러한 서비스에 액세스하는 방법의 문제는 해결하지 못한다는 것을 배웠습니다. Pod는 실행 중인 서비스의 인스턴스일 뿐이며 언제든지 한 노드에서 중지하고 다른 노드에서 새 IP로 새 Pod를 시작할 수 있으므로 명확한 IP 및 포트 번호로 서비스를 제공할 수 없습니다.

서비스를 안정적으로 제공하려면 서비스 검색 및 로드 밸런싱 기능이 필요합니다. 서비스 검색에 의해 수행되는 작업은 클라이언트가 액세스하는 서비스에 대한 해당 백엔드 서비스 인스턴스를 찾는 것입니다. K8S 클러스터에서 클라이언트가 액세스해야 하는 서비스는 서비스 개체입니다. 각 서비스는 클러스터 내에서 유효한 가상 IP에 해당하며, 가상 IP를 통해 클러스터 내에서 서비스에 접근한다.

K8S 클러스터에서 마이크로 서비스의 로드 밸런싱은 kube-proxy에 의해 구현됩니다. kube-proxy는 k8s 클러스터 내부의 로드 밸런서입니다. 분산 프록시 서버이며 K8S의 각 노드에 하나씩 있으며 이 설계는 확장성 이점을 반영하여 서비스에 액세스해야 하는 노드가 많을수록 로드 밸런싱 기능을 제공하는 kube-proxy가 많을수록 높은 수의 가용성 노드도 증가합니다. 이에 반해 우리는 일반적으로 서버 측 부하 분산을 위해 역방향 프록시를 사용하며 역방향 프록시의 고가용성 문제를 추가로 해결해야 합니다.

서비스 존재의 의미

Pod 연결 해제 방지 [서비스 검색]

Pod가 생성될 때마다 IP 주소에 해당하고 이 IP 주소는 수명이 짧고 Pod가 업데이트될 때마다 변경됩니다. 또한 백엔드에 여러 개의 Pod가 있으므로 서로 액세스할 때 등록 센터를 통해 Pod의 IP 주소를 가져와 해당 Pod에 액세스해야 합니다.
이미지 설명을 추가하세요

Pod 접근 정책 정의 [부하 분산]

페이지의 프론트 엔드에 있는 Pod는 서비스 계층을 통해 백엔드에 있는 Pod에 액세스하며 여기서 서비스도 로드 밸런싱을 수행할 수 있습니다. 로드 밸런싱을 위한 구현 전략은 다음과 같이 많이 있습니다.

무작위의
투표
응답률

Pod와 서비스의 관계

여기서 Pod와 서비스 간의 연결은 여전히 레이블 및 선택기를 기반으로 합니다. [컨트롤러와 동일]

이미지 설명을 추가하세요
서비스에 접속할 때 실제로는 IP 주소가 필요하며, 이 IP는 확실히 Pod의 IP 주소가 아니라 가상 IP입니다.vip

일반적인 서비스 유형

서비스에는 세 가지 일반적인 유형이 있습니다.

ClusterIp: 클러스터 내 액세스
NodePort: 외부 액세스 응용 프로그램에서 사용
LoadBalancer: 외부 접근 애플리케이션, 퍼블릭 클라우드에 사용

예시

서비스의 구성 정보가 포함된 파일을 내보낼 수 있습니다.

kubectl expose deployment web --port=80 --target-port=80 --dry-run -o yaml > service.yaml

service.yaml은 다음과 같습니다.

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: null
  labels:
    app: web
  name: web
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: web
status:
  loadBalancer: {
    
    }

설정하지 않으면 첫 번째 방법인 ClusterIp가 기본적으로 사용되는데, 이는 클러스터 내부에서만 사용할 수 있으며, type 필드를 추가하여 서비스 유형을 설정할 수 있습니다.

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: null
  labels:
    app: web
  name: web
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: web
  type: NodePort
status:
  loadBalancer: {
    
    }

명령을 수정한 후 다음을 사용하여 포드를 만듭니다.

kubectl apply -f service.yaml

그러면 NodePort 유형으로 성공적으로 수정되었음을 알 수 있으며 마지막으로 남은 방법은 LoadBalanced: 공용 클라우드를 사용하는 외부 액세스 응용 프로그램입니다.

노드는 일반적으로 인트라넷에 배포되고 외부 네트워크는 일반적으로 액세스할 수 없으므로 액세스하는 방법은 무엇입니까?

외부 네트워크를 통해 액세스할 수 있는 머신을 찾아 nginx를 설치하고 역 프록시
nginx에 액세스 가능한 노드를 수동으로 추가

LoadBalancer를 사용하면 nginx의 기능과 유사한 로드 밸런싱 컨트롤러가 있으며, 우리는 이를 nginx에 직접 추가할 필요가 없습니다.

레이어 4 로드 밸런싱 서비스: 개념 및 원리 해석

왜 서비스가 있습니까?

kubernetes에서 Pod에는 수명 주기가 있으며 Pod가 다시 시작되면 해당 IP가 변경될 수 있습니다. 우리 서비스 모두가 파드의 IP 주소를 죽도록 쓰고 파드가 멈추거나 다시 시작하면 방금 다시 시작된 파드와 관련된 다른 서비스는 그것과 관련된 파드를 찾을 수 없을 것이다.이 문제를 해결하기 위해 kubernetes에서 정의한다 서비스 리소스 개체를 사용하여 서비스는 클라이언트가 서비스 뒤의 애플리케이션 클러스터 인스턴스에 액세스할 수 있는 서비스 액세스 항목을 정의합니다. 서비스는 일반적으로 다음을 통해 구현되는 서비스에서 액세스할 수 있는 Pod 그룹의 논리적 모음입니다. 태그 선택기.
이미지 설명을 추가하세요
1. 포드 ip가 자주 변경됩니다. 서비스는 포드의 프록시입니다. 클라이언트가 액세스할 때 우리는 서비스에 액세스하기만 하면 되며 요청은 포드에 프록시됩니다.

2. Pod IP는 k8s 클러스터 외부에서 액세스할 수 없으므로 k8s 클러스터 외부에서 액세스할 수 있는 서비스를 생성해야 합니다.

서비스 개요

서비스는 고정 액세스 계층입니다. 클라이언트는 서비스의 IP 및 포트에 액세스하여 서비스와 연결된 백엔드 포드에 액세스할 수 있습니다. 이 서비스의 작업은 kubernetes 클러스터에 배포된 액세서리인 kubernetes dns 서비스에 따라 다릅니다. (kubernetes dns 서비스마다 다름) 기본적으로 사용하는 dns의 버전도 다릅니다. 1.11 이전 버전은 kubeDNS를 사용하고 최신 버전은 coredns를 사용합니다. 서비스의 이름 확인은 dns 첨부 파일에 따라 다르므로 배포해야 합니다. k8s가 배포된 후 dns 부착, kubernetes는 클라이언트에 네트워크 기능(예: IP 할당)을 제공하기 위해 타사 네트워크 플러그인(플란넬, 칼리코 등)에 의존해야 합니다. 각 K8s 노드에는 kube-proxy라는 구성 요소가 있습니다.kube-proxy의 이 구성 요소는 항상 apiserver의 서비스 리소스에 대한 변경 정보를 모니터링합니다.마스터의 apiserver와 상호 작용하고 언제든지 apiserver에 연결하여 kubernetes 고유의 요청 방식 감시(모니터링)를 통해 구현되는 서비스 자원과 관련된 모든 자원 변경 상태 획득 서비스 자원의 내용(예: 생성, 삭제)이 변경되면 작업은 etcd 에 저장됩니다. 그런 다음 백엔드별 포드 리소스에 대한 규칙에 대한 요청을 예약합니다. 이 규칙은 서비스 구현 방식에 따라 iptables 또는 ipvs일 수 있습니다(규칙을 직접 구성할 수 있음). 예를 들어 새 svc가 생성되면 svc에는 ip가 있고 이 ip의 네트워크 세그먼트는 클러스터가 생성될 때 구성됩니다(기본값은 10).

서비스 작동 방식

k8s는 서비스를 생성할 때 레이블 선택자(lable selector)에 따라 Pod를 조회하고 그에 따라 서비스와 동일한 이름으로 엔드포인트 객체를 생성합니다.포드 주소가 변경되면 엔드포인트도 변경되고, 서비스가 프런트 엔드 클라이언트 요청을 수신하면 엔드포인트를 통해 액세스하기 위해 전달할 Pod의 주소를 찾습니다. (어떤 노드로 전달되는 Pod는 로드 밸런싱 kube-proxy에 의해 결정됨)

[root@k8smaster node]# kubectl get endpoints
NAME         ENDPOINTS             AGE
kubernetes   192.168.11.139:6443   15d
[root@k8smaster node]# kubectl get pods -n kube-system -o wide
NAME                                READY   STATUS    RESTARTS   AGE   IP               NODE     
kube-apiserver-k8smaster            1/1     Running   4          15d   192.168.11.139   k8smaster 
apiserver是绑定了宿主机的网络ip，apiserver这个pod，封装的k8sapiservice服务端口是443，这个service关联的pod是apiserver，ednpoints列表里编写的也是apiserverpod的ip和端口

Kubernetes 클러스터에는 세 가지 유형의 IP 주소가 있습니다.

1、Node Network（节点网络）：物理节点或者虚拟节点的网络，如 ens33 接口上的网路地址
[root@k8smaster node]# ip addr
ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:0c:29:94:59:0f brd ff:ff:ff:ff:ff:ff
    inet 192.168.11.139/24 brd 192.168.11.255 scope global noprefixroute dynamic ens3

2、Pod network（pod 网络），创建的 Pod 具有的 IP 地址 
[root@k8smaster node]#  kubectl get pods -o wide
NAME                        READY   STATUS    RESTARTS   AGE   IP            NODE       NOMINATED NODE  
frontend-d5tr9              1/1     Running   0          23h   10.244.2.30   k8snode    <none>          
Node Network 和 Pod network 这两种网络地址是我们实实在在配置的，其中节点网络地址是配置在节点接口之上，而 pod 网络地址是配置在 pod 资源之上的，因此这些地址都是配置在某些设备之上的，这些设备可能是硬件，也可能是软件模拟的 
 
3、Cluster Network（集群地址，也称为 service network），这个地址是虚拟的地址（virtual ip），没有配置在某个接口上，只是出现在 service 的规则当中。 
[root@xianchaomaster1 ~]# kubectl get svc 
[root@k8smaster node]# kubectl get svc
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP   15d

끝에 쓰다

만들기가 쉽지 않습니다. 컨텐츠가 도움이 된다고 생각하시면 3링크 팔로우를 통해 저를 지원해 주세요! 틀린 부분이 있으면 댓글로 지적해주시면 시간이 지나면 수정하겠습니다!
현재 업데이트 중인 시리즈: k8s 처음부터 배우세요
시청해주셔서 감사합니다 개인적인 이해가 섞인 글입니다 오류가 있으면 연락주시고 지적해주세요~
여기에 이미지 설명 삽입