IT Tech Note

광 트랜시버

광전송 시스템, 대용량 라우터 및 스위치 등 광통신 장치에서,

광전 신호 변환(광전 및 전기 광학 변환)을 수행하는 모듈로, 네트워크 상호 접속장치 이다. 

즉, 전기신호를 빛으로 바꾸어 광섬유를 통해 전송하게 되고, 수신측에서는 빛을 다시 전기신호로 바꾸어주는 광전변환 역할을 한다.

송신단                         수신단

전기 -> 빛  ------------ 빛 -> 전기

송신기와 수신기가 하나의 모듈에 통합되어 있으며,

광섬유 케이블을 통해 데이터를 송수신하는 장비(서버/스위치/라우터/광섬유 모뎀 등에 장착)에서 사용된다. 
광전 신호 변환 이외에, 다중화/역다중화 기능을 수행한다.

여러 개의 전기 신호를 하나의 광 신호로 다중화하거나, 하나의 광 신호를 여러 개의 전기 신호로 역다중화한다. 

광 트랜시버 선택 시 요구사항에 맞는 트랜시버를 선택해야 한다.

전송 속도, 전송 거리 및 파장을 지원하고, 시스템 형식에 맞는 광 트랜시버 모듈을 선택해서 사용하면 된다.

광 트랜시버 종류

광 트랜시버는 다양한 종류가 있으나, 그 중에서도 100GbE 데이터 전송을 지원하는 QSFP28 광 모듈인 SR4, LR4, ER4에 대해 알아보자. 

 1. SR4(Short Reach, 4 Lanes)

     -연결 거리: 최대 100m(멀티모드 광섬유)

     -파장: 850nm

     -송수신 방식: 4채널 병렬

     -장점: 저렴한 가격, 단거리 연결에 적합

     -단점: 장거리 불가

 2. LR4(Long Reach, 4 Lanes)

     -연결 거리: 최대 10km

     -파장: 1310nm

     -송수신 방식: 4채널 병렬

     -장점: SR4보다 더 긴 전송 거리, 높은 성능 

     -단점: SR4보다 가격이 비쌈

 3. ER4(Extended Reach, 4 Lanes)

     -연결 거리: 최대 40km(단일모드 광섬유)

     -파장: 1310nm

     -송수신 방식: 4채널 병렬

     -장점: SR4보다는 장거리 연결(10km 이상 가능), 저렴한 가격

     -단점: LR4보다 성능이 낮음

[요약]

데이터 센터 내 단거리 연결에는 SR4, 10km 이내의 고성능 장거리 연결에는 LR4를, 10km이상 장거리 연결에는 ER4를 선택하는 가이드를 줄 수 있다. 

파장대역, 가격, 전송 속도 및 연결 거리 등 요구사항에 맞는 모듈을 선택하여야 한다. 

광 트랜시버 활용

광 트랜시버는 아래와 같이 활용된다.

 -장거리, 데이터센터, 메트로망 등에 사용됨.

 -PON(Passive Optical Network): FTTH(Fiber To The Home)

 -WDM(Wavelength Division Multiplexing) 기술

그렇다면, 광 트랜스폰더는 무엇일까? 트랜시버와 무엇이 다르고, 어떻게 활용되는지 알아보자.

광 트랜스폰더(Transponder)

광섬유와 전기신호와의 쌍방향 변환을 실시하는 기능부를 트랜스폰더라고 칭한다. 
예를들어,  O-E-O 광 전광 변환을 해주는 Unit으로, O(1310nm)-E-O(1550nm)일 때, 1310nm의 파장을 1550nm파장으로 바로 변환하기 어려우므로, 파장 변환을 해주는 트랜스폰더를 사용하는 것이다.
  -Transponder는 Tx와 Rx 트랜스폰더가 있으며, 두 유닛 모두 같은 유닛에 사용되며 전송 방향만 다르다.

 트랜스폰더는 위에서 설명된 트랜시버의 광전 변환 기능에 더하여, 파장변환 기능을 추가로 가진다. 

트랜시버는 정해진 파장으로 전달하게 되지만 트랜스폰더는 파장 변환이 가능하다. 

  **파장 변환 기능 작동 

   1. 송신단: 트랜스폰더는 송신하려는 데이터를 각 채널에 할당된 파장에 맞춰 변환

   2. 전송: 변환된 광 신호는 광섬유 케이블을 통해 전송 됨

   3. 수신단: 트랜스폰더는 수신된 광 신호를 각 채널의 파장에 따라 분리하고, 원래 데이터로 변환함

즉, WDM 기술에서 광 신호의 파장 변환 및 증폭을 통해, 장거리 통신을 가능하게 하고, 용량을 확장하는 등 관리에 용이하다. 

[요약]
 -트랜스폰더는 수신된 광신호를 다른 파장의 광신호로 변환하고 송신할 수 있음 
 -WDM 시스템에서 다중 채널의 데이터를 동일한 광섬유 케이블로 전송 가능함
 -구성은 트랜시버 + 파장 변환 장치(Mux/DeMux)로 구성되어 있음 
 -WDM System에서 광신호의 파장 변환 및 증폭을 통해 장거리 통신을 가능하게 함
 -광섬유 NW 용량 확장 가능 및 관리에 용이함 

   **파장 변환 장치

     1. 트랜스폰더: WDM 시스템에서 광 신호의 파장 변환 및 증폭 담당

     2. Mux/Demux: 여러 채널의 광 신호를 결합/분리하는 장치 

     3. 광 라우터: 광섬유 네트워크에서 데이터를 라우팅하는 장치

(참고)

https://ettrends.etri.re.kr/ettrends/115/0905001427/24-1_012_023.pdf

 https://ko.fiberwdm.com/blog/optical-modules-vs-transponders-what-s-the-difference_b67

kubectl get pods
	--server my-kube-playground:6443
    --client-key admin.key
    --client-certificate admin.crt
    --certificate-authority ca.crt

{
 "kind": "PodList"
 "apiVersion": "v1",
 "metadata": {
   "selfLink": "/api/v1/pods",
   },
   "items": []
}

이전 글까지 클라이언트가 인증서 파일을 어떻게 사용하는지에 대한 내용과

키는 curl 을 이용해 Pod의 RestAPI를 쿼리하기 위해 사용됨

>>cluster는 Playground

-kube-api주소로 cert파일과 키를 curl로 보냄

curl https://my-kube-playground:6443/api/v1/pods \
 --key admin.key
 --cert admin.crt
 --cacert ca.crt

>>apiserver는 사용자를 인증하기 위해 유효성을 확인

kubectl get pods
  --server my-kube-playground:6443
  --client-key admin.key
  --client-certificate admin.crt
  --certificate-authority ca.crt

No resources found.

>>매번 인증 확인하지 않고, kubeconfig를  사용

kubeconfig file에 유효성 확인을 위한 내용을 넣어두고, kubeconfig 파일로 이동하도록 셋팅

kubectl get pods
  --kubeconfig config		//kubeconfig 옵션으로 명시

KubeConfig FIle 형식 확인하기

-Cluster: 액세스가 필요한 클러스터들(Development, Production, Google....)

-Contexts: 어떤 사용자 계정이 어떤 클러스터에 액세스하기 위해 사용될 지 정의됨-기존 사용자의 사용 권한을 가지고 있고, 각 클러스터에 접근하기 위한 사용자가 정의되어 있음

-Users: 클러스터에 액세스 권한이 있는 사용자(Admin, Dev User, Prod User)-클러스터마다 다른 권한을 가질 수 있음

따라서, 사용자 인증서와 서버 주소를 직접 지정할 필요가 없게 되는 것.

// $HOME/.kube/config
  --server my-kube-playground:6443 	//클러스터 섹션
  --client-key admin.key			//user섹션
  --client-certificate admin.crt	//user섹션
  --certificate-authority ca.crt	//클러스터 섹션

>>MyKubePlayground Context를 정의 -액세스 지정사항을 정의

실습따라하기

controlplane ~ ➜  cat /root/my-kube-config 
apiVersion: v1
kind: Config

clusters:
- name: production
  cluster:
    certificate-authority: /etc/kubernetes/pki/ca.crt
    server: https://controlplane:6443

- name: development
  cluster:
    certificate-authority: /etc/kubernetes/pki/ca.crt
    server: https://controlplane:6443

- name: kubernetes-on-aws
  cluster:
    certificate-authority: /etc/kubernetes/pki/ca.crt
    server: https://controlplane:6443

- name: test-cluster-1
  cluster:
    certificate-authority: /etc/kubernetes/pki/ca.crt
    server: https://controlplane:6443

contexts:
- name: test-user@development
  context:
    cluster: development
    user: test-user

- name: aws-user@kubernetes-on-aws
  context:
    cluster: kubernetes-on-aws
    user: aws-user

- name: test-user@production
  context:
    cluster: production
    user: test-user

- name: research
  context:
    cluster: test-cluster-1
    user: dev-user

users:
- name: test-user
  user:
    client-certificate: /etc/kubernetes/pki/users/test-user/test-user.crt
    client-key: /etc/kubernetes/pki/users/test-user/test-user.key
- name: dev-user
  user:
    client-certificate: /etc/kubernetes/pki/users/dev-user/developer-user.crt
    client-key: /etc/kubernetes/pki/users/dev-user/dev-user.key
- name: aws-user
  user:
    client-certificate: /etc/kubernetes/pki/users/aws-user/aws-user.crt
    client-key: /etc/kubernetes/pki/users/aws-user/aws-user.key

current-context: test-user@development
preferences: {}

context변경하기 

controlplane ~ ➜  kubectl config use-context research --kubeconfig /root/my-kube-config
Switched to context "research".

controlplane ~ ➜  cat /root/my-kube-config                                   apiVersion: v1
clusters:
- cluster:
    certificate-authority: /etc/kubernetes/pki/ca.crt
    server: https://controlplane:6443
  name: development
- cluster:
    certificate-authority: /etc/kubernetes/pki/ca.crt
    server: https://controlplane:6443
  name: kubernetes-on-aws
- cluster:
    certificate-authority: /etc/kubernetes/pki/ca.crt
    server: https://controlplane:6443
  name: production
- cluster:
    certificate-authority: /etc/kubernetes/pki/ca.crt
    server: https://controlplane:6443
  name: test-cluster-1
contexts:
- context:
    cluster: kubernetes-on-aws
    user: aws-user
  name: aws-user@kubernetes-on-aws
- context:
    cluster: test-cluster-1
    user: dev-user
  name: research
- context:
    cluster: development
    user: test-user
  name: test-user@development
- context:
    cluster: production
    user: test-user
  name: test-user@production
current-context: research
kind: Config
preferences: {}
users:
- name: aws-user
  user:
    client-certificate: /etc/kubernetes/pki/users/aws-user/aws-user.crt
    client-key: /etc/kubernetes/pki/users/aws-user/aws-user.key
- name: dev-user
  user:
    client-certificate: /etc/kubernetes/pki/users/dev-user/developer-user.crt
    client-key: /etc/kubernetes/pki/users/dev-user/dev-user.key
- name: test-user
  user:
    client-certificate: /etc/kubernetes/pki/users/test-user/test-user.crt
    client-key: /etc/kubernetes/pki/users/test-user/test-user.key

현재 상태를 기본 kubeconfig 파일로 사용하려면

controlplane ~ ➜  mv /root/my-kube-config /root/.kube/config 
controlplane ~ ➜  

controlplane ~ ➜  cat /root/.kube/config
apiVersion: v1
clusters:
- cluster:
    certificate-authority: /etc/kubernetes/pki/ca.crt
    server: https://controlplane:6443
  name: development
- cluster:
    certificate-authority: /etc/kubernetes/pki/ca.crt
    server: https://controlplane:6443
  name: kubernetes-on-aws
- cluster:
    certificate-authority: /etc/kubernetes/pki/ca.crt
    server: https://controlplane:6443
  name: production
- cluster:
    certificate-authority: /etc/kubernetes/pki/ca.crt
    server: https://controlplane:6443
  name: test-cluster-1
contexts:
- context:
    cluster: kubernetes-on-aws
    user: aws-user
  name: aws-user@kubernetes-on-aws
- context:
    cluster: test-cluster-1
    user: dev-user
  name: research
- context:
    cluster: development
    user: test-user
  name: test-user@development
- context:
    cluster: production
    user: test-user
  name: test-user@production
current-context: research
kind: Config
preferences: {}
users:
- name: aws-user
  user:
    client-certificate: /etc/kubernetes/pki/users/aws-user/aws-user.crt
    client-key: /etc/kubernetes/pki/users/aws-user/aws-user.key
- name: dev-user
  user:
    client-certificate: /etc/kubernetes/pki/users/dev-user/developer-user.crt
    client-key: /etc/kubernetes/pki/users/dev-user/dev-user.key
- name: test-user
  user:
    client-certificate: /etc/kubernetes/pki/users/test-user/test-user.crt
    client-key: /etc/kubernetes/pki/users/test-user/test-user.key

확인하기

controlplane ~ ➜  kubectl  config view 
apiVersion: v1
clusters:
- cluster:
    certificate-authority: /etc/kubernetes/pki/ca.crt
    server: https://controlplane:6443
  name: development
- cluster:
    certificate-authority: /etc/kubernetes/pki/ca.crt
    server: https://controlplane:6443
  name: kubernetes-on-aws
- cluster:
    certificate-authority: /etc/kubernetes/pki/ca.crt
    server: https://controlplane:6443
  name: production
- cluster:
    certificate-authority: /etc/kubernetes/pki/ca.crt
    server: https://controlplane:6443
  name: test-cluster-1
contexts:
- context:
    cluster: kubernetes-on-aws
    user: aws-user
  name: aws-user@kubernetes-on-aws
- context:
    cluster: test-cluster-1
    user: dev-user
  name: research
- context:
    cluster: development
    user: test-user
  name: test-user@development
- context:
    cluster: production
    user: test-user
  name: test-user@production
current-context: research
kind: Config
preferences: {}
users:
- name: aws-user
  user:
    client-certificate: /etc/kubernetes/pki/users/aws-user/aws-user.crt
    client-key: /etc/kubernetes/pki/users/aws-user/aws-user.key
- name: dev-user
  user:
    client-certificate: /etc/kubernetes/pki/users/dev-user/developer-user.crt
    client-key: /etc/kubernetes/pki/users/dev-user/dev-user.key
- name: test-user
  user:
    client-certificate: /etc/kubernetes/pki/users/test-user/test-user.crt
    client-key: /etc/kubernetes/pki/users/test-user/test-user.key

KubeConfig 실습

출처

Udemy k8s CKA 

 CA는 키와 인증서 파일 1개의 pair에 해당한다.

CA에 접근하여 k8s 환경을 구축할 수 있으므로, 안전하게 보관되어야 한다.

인증서 파일은 서버에 안전하게 보관되고, 인증서에 서명하고자 할 때마다 해당 서버에 접근하고 사용할 수 있는 권한이 있어야 함

마스터노드에 인증서 파일이 보관 될 서버가 위치하게 되고, rsa서버가 되기도 함

kubeadm tool도 마찬가지로 CA file을 생성하고 마스터노드에 저장함,

지금까지는 수동으로 요청에 서명했으나,

k8s에 내장된 Certificate API를 이용하여 k8s API Client가 X.509 자격 증명 프로비저닝을 자동화할 수 있도록 한다. (많은 사용자의 접근과, 유효한 인증서의 만료일자 등 자동으로 관리할 수 있도록 한다.)

k8s는 마스터노드에 Certificate API가 내장되어 있어 인증서 관리가 용이하다.

사용자는 관리자에게 Certificate Request를 Certificate API를 호출하여 k8s에 서명 요청을 보냄

관리자는 사용자에게 받은 서명 요청을 수행하기 위해,  마스터노드에 접속하여 수동으로 인증하지 않고,

CertificateSigningRequest Object(API 개체)를 만든다.

1. Create CertificateSigningRequest Object 

Object가 생성되면 인증서 요청에 대해  cluster관리자들이 해당 서명 요청을 보게 됨

2. Review Requests

3. Approve Requests

(kubectl을 통해 쉽게 검토하고 승인할 수 있음)

4. Share Certs to Users

검토되고,승인 된 위 인증서는 추출되어 사용자와 공유됨

--------

사용자는 관리자에게 Certificate Request를 Certificate API를 호출하여 k8s에 서명 요청을 보냄

관리자는 사용자에게 받은 서명 요청을 수행하기 위해,  마스터노드에 접속하여 수동으로 인증하지 않고,

CertificateSigningRequest Object(API 개체)를 만든다.

1. Create CertificateSigningRequest Object 

Object가 생성되면 인증서 요청에 대해  cluster관리자들이 해당 서명 요청을 보게 됨

2. Review Requests

3. Approve Requests

(kubectl을 통해 쉽게 검토하고 승인할 수 있음)

4. Share Certs to Users

검토되고,승인 된 위 인증서는 추출되어 사용자와 공유됨

--------

>>실습

1. 사용자는 key를 먼저 만들고, 사용자의 이름이 명시된 키를 사용해 관리자에게 인증서 서명 요청

openssl genrsa -out ysuekkom.key 2048
ysuekkome.key			//사용자 이름이 명시된 키 생성
openssl req -new -key ysuekkom.key -subj "/CN=ysuekkom" -out ysuekkom.csr	//인증서 서명 요청

2. 관리자는 사용자가 보낸 키를 사용하여, CertificateSigningRequest Object를 생성함

>>일반적인 k8s object와 마찬가지로 manifests file 체계로 생성됨

사용자가 보낸 인증서 서명을 인코딩하여 request field에 명시

apiVersion: certificate.k8s/io/v1
kind: CertificateSigningRequest
metadata:
  name: ysuekkom
spec:
  expirationSeconds: 600 
  usages:
  - digital signature
  - key encipherment
  - server auth
  request:
    - 
    		//사용자가 보낸 인증서 서명을 명시하는 곳--일반 텍스트를 그대로 쓰지않고
            //base64로 인코딩된 텍스트를 request field로 옮긴다: cat ysuekkom.csr | base64

참고) 디코딩하기 위해서는 base64 유틸리티를 이용하여, 디코딩 수행하기

>> 디코딩 시 일반 텍스트형식으로 인증서 내용 확인 가능

3. Object가 생성되면  모든 인증서 모든 CertificateSigningRequest는, kubectl 실행으로 관리자에 의해 확인할 수 있음

kubectl get csr

>> Name, age, signername, requestro, requestedduration, condition 등을 확인할 수 있음

4. kubectl 명령을 확인하여, 관리자가 사용자 승인 수행

kubectl certificate approve ysuekkom
ysuekkom approved!

>>새 요청을 확인하고, 요청 승인 할 수 있음

5. yaml 포맷으로 인증서를 확인하면, 생성된 인증서의 일부를 확인할 수 있음

kubectl get csr ysuekkom -o yaml

위 과정은 Master Node의 어떤 컴포넌트가 수행할까?

-인증서 관련 모든 작업은 Controller Manager 내 CSR-APPROVING, CSR-SIGNING이 수행

인증서에 서명이 필요하다면, CA서버의 경로, 인증서, 개인키가 필요함

Controller Manager 서비스 구성에는, 2가지 옵션이 있음

cat /etc/kubernetes/manifests/kube-controller-manager.yaml

spec:
  containers:
  - command:
    - kube-controller-manager
    - --address=127.0.0.1
    - --cluster-signing-cert-file=/etc/kubernetes/pki/ca.crt
    - --cluster-signing-key-file=/etc/kubernetes/pki/ca.key