IT Tech Note

Coherent란?

파동이 균일하고, 위상이 규칙성을 가지고 있는 상태를 말한다. 즉 주파수가 매우 안정적이고, 변동이 없는 광원을 Coherent 광이라고 한다.

광섬유 분야의 기술로, 단순히 광 신호의 세기 변조 및 직접 검출로 신호를 판별하는 것이 아니다. Coherent 검출 방식은 광 신호가 멀리 전송될 때 신호의 세기가 약해져도, 광 신호의 위상 또는 주파수 변조에 의해 신호를 판별, 수신 할 수 있는 기술을 말한다. 

기존의 광 전송 기술은 빛의 세기만으로 신호를 판별하였고, 2.5Gpbs, 10Gbps, 40Gbps, 100Gbps로 전송이 확장되면서 분산과 감쇠, 즉 신호 전송의 문제가 커지게되어 한계에 부딪혔고, Coherent 광 기술의 등장 배경이 되었다.

Coherent는 앞서 말한 위상을 통해 수신단에서 신호를 검출하기 때문에 장거리, 고용량 정보 전송에 적합한 첨단 복합 광전송 시스템이다.

광통신의 성능 잠재력을 더욱 활용하고, 대역폭을 늘리며, 에러 정정 기능으로 신뢰성 향상, 배포 비용을 줄이는데 도움을 주는 기술이다.

Choerent 기술은 백본망, 데이터 센터, 광 해저 케이블 그리고 5G/6G 통신망에 주로 활용된다. 

기존 백본 네트워크 WDM 시스템을 업그레이드 하거나, 5G 미드 백홀 시나리오에서도 사용 가능하다.

또한 데이터센터 상호 연결 (DCI) 시나리오에 초점을 맞춰 장거리 Coherent 광 모듈에 대한 수요를 충족시키기 위한 발전을 지속하고 있다.

하지만 기술적인 이점과는 별개로 복잡한 공정, 대용량, 높은 전력 소모 등 해결해야 하는 과제들이 남아있다.  

Coherent 장점

   1. 기존 전송 기술 방식 대비 10~100배 향상

   2. 100Gbps, 400Gbps, 1Tbps 이상 전송 가능

   3. 향상된 에러 정정 기능으로 신뢰성 향상

   4. 광 증폭기를 사용할 경우, 간섭 제거 가능 

   5. 주파수 대역 활용도가 크기 때문에, 수신간도와 주파수 활용 측면에서 효율적임

Coherent 동작 원리

   1. 입력 신호를 ASK, FSK, PSK를 통해 좁은 선폭을 갖는 반송파에 변조 시킨다.

   2. 수신단에서 광 국부 발진기를 사용하여(헤테로다인 방식으로(Optical FDM)), 광 IF(중간 주파수를) 만들어낸다. 

        **헤토로다인 중계기:

          무선 회선 중계 방식으로, 수신된 마이크로파를 중간 주파수파로 변환, 중간 주파수 증폭기로 필요한 만큼 증폭 한 뒤, 마이크로파로 다시 변환하여 송신하는 중계 방식

   3. 해당 주파수 필터를 통해 분리한다.

Coherent 주요 기술

편광 보존 기술

Coherent 검출시  신호 광과 국부 발진기 광의 편광이 동일해야 한다.(간섭 수신이 제공할 수 있는 높은 감도를 얻기 위해서는 둘의 전기적 벡터 방향이 동일해야 하기 때문이다. 고감도를 확보하기 위해서는 광파 편광 안정화를 위한 주파수 안전화 기술, 스펙트럼 압축 기술이 있다. 

 1. 주파수 안정화 기술
    -반도체 레이저의 주파수 안정성은 코히어런트 광통신에서 매우 중요함.

    -온도와 전류 변화에 민감해, 레이저 주파수가 다른 작동 조건으로 드리프트하면 IF 전류에 영향을 미쳐 BER이 증가함.
 2. 스펙트럼 압축 기술
    -광원의 스펙트럼 폭(좁은 선폭)은 Coherent 광통신에서 중요함.
    -반도체 레이저의 양자 진폭 변조 및 주파수 변조 노이즈가 수신기의 감도에 미치는 영향을 극복할 수 있음.
    -위상 드리프트로 인한 위상 노이즈가 작아짐.
    -일관된 광통신 요구사항을 충족(장거리 전송이 훨씬 쉬워짐)시키기 위해서는 스펙트럼 폭 압축 기술이 채택됨.

데이터 변조

위상차는 sin파와 cos파의 직교성을 통해 두 신호를 조합했을 때 어떠한 신호도 표기할 수 있게 된다. 이를 IQ Modulation이라고 한다.
즉 I와 Q신호를 별도로 조절했을 때, 모든 반송파 신호를 나타낼 수 있음을 의미한다. 

추가적으로, IQ변조를 통해 진폭과 위상 데이터를 직관적으로 나타낼 수 있어 많이 사용된다.

이외에도 HW 설계시 RF 반송파의 위상을 직접 조작하여 원하는 신호를 얻을 수 있기 때문에 많이 활용 된다.

IQ는 IQ-plot을 통해 다이어그램으로 나타낼 수 있다.

Modulation?

변조란 보내고자 하는 정보 신호를 가지고 Carrier(반송파)의 진폭, 주파수 및 위상을 변화시키는 것이며, 정보 신호의 주파수 스펙트럼을 높은 곳으로 옮기는 조작이다.

Modulation 종류

 1. ASK(Amplitude Shift Keying): 변조 신호를 가지고, 반송파의 진폭을 변화시키는 방식
 2. FSK(Frequency Shift Keying): 변조 신호를 가지고, 주파수를 변화시키는 방식
 3. PSK(Phase Shift Keying):  반송파의 위상을 변화시키는 방식
 4. QPSK(Quadrature Pahse Shift Keying) 직교 위상천이 변조: 위상변화를 ㅠ/2만큼 줘서, 4개의 디지털 심벌로 전송하는 방식
 5. QAM(Quadrature Apmlitude Modultaion): 반송파의 진폭과 위상을 같이 변화시키는 변조 방식(제한된 전송 대역을 이용한 데이터 전송 효율의 향상을 위해)으로 2개의 채널(I-채널, Q-채널)이 독립되도록 한 것으로, IQ변조와 같음.
 즉, 진폭을 바꾸는 ASK와, 위상을 바꾸는 PSK를 결합한 방식

**Coherent(가간섭성)

단일 주파수 스펙트럼이며, 위상이 일치되고 균일한 정현파의 광파로, 완전 Coherent한 광은 단일 파장, 단색광(Monochromatic Light)임
**Incoherent(비간섭성)

다양항 주파수 및 진폭을 가지며, 위상이 일치하지 않는 광파로 태양, 전구 같이 열을 발생시키는 광

(참고)

http://www.ktword.co.kr/test/view/view.php?m_temp1=907

https://rf-yeolmu.tistory.com/14

https://ensxoddl.tistory.com/353

https://blog.naver.com/wlsqor2/40117111555

WDM 기술 등장 배경

WDM(Wavelength Division Multiplexing)

인터넷 사용자의 급증과 데이터 통신 용량의 폭발적인 증가에 따라, 기존 전송 시스템으로는 한계에 마주했다.

기존 전송 시스템으로는 단일 파장에 데이터를 전송하는 방식으로, 전송할 수 있는 통신 용량이 제한적이었고다.

또한 더 많은 데이터를 전송하기 위해서는 더 많은 광섬유를 사용해야했다. 비용적인 측면의 어려움이 따랐던 것.

이에 대용량의 데이터를 전송할 수 있는 방법에 대해 고민하기 시작했고, WDM 기술이 등장했다. 

WDM은 여러 개의 서로 다른 파장의 빛을 하나의 광섬유에 동시에 전송하여, 통신 용량을 크게 증가 시켰다. 기존의 광섬유를 사용하였기 때문에, 비용적인 효율성까지 가져갈 수 있었다. 

1. WDM(Wavelength Division Multiplexing)

 광 신호 전송 시, 전기적 신호(1과 0)을 Header를 포함한 Frame화하여 ONU로 송신하게 된다.(Header 안에는 신호를 보호하면서 E2E 전송을 위한 보안, health check 등의 값을 포함하고 있다.)  

기존의 전송 방식은 한 개의 광섬유에 한 개의 파장만을 실어서 보냈으나, WDM 전송 방식은 여러 개의 파장을 가진 광신호를 하나로 묶어서 광섬유로 실어 보내는 방식이다. WDM의 기술 발전에 따라 분할되는 파장 간 사이 밀도가 좁아져 용량과 채널을 늘려갔다.

 WDM 장점 

   1. 전송 가능한 트래픽 양의 증가

   2. 기존 광섬유 자원을 활용

   3. 단일 광섬유에 여러 개의 파장을 실어 보내기 때문에, 설치 및 유지 관리 비용 절감 

   4. 새로운 파장을 추가하여 용량 확장 용이(확장성)

   5. 속도와 품질의 향상

정리하자면,

WDM 기술은 통신 용량 증가에 대한 요구와 광선유의 대역폭 활용 필요성에 따라 등장했고,

기존 광섬유 자원을 활용하면서, 전송 용량과 속도를 증가시키고, 비용 절감 및 확장성의 장점을 가지고 있다. 

WDM 기술이 발전됨에 따라 광 전송 분류에 대해 알아보자.

WDM 기술 

WDM 기술은 등장한 이후, 지속 발전해왔다.

초기 단일 파장에 여러 개의 비트를 전송하는 Coarse WDM(CWDM)기술이 사용되었고,

그 이후, 더 많은 파장을 사용하여 더 많은 데이터를 전송할 수 있는 Dense WDM(DWDM)기술.

사용자 정의 가능한 채널 간격을 사용하여, 더욱 효율적으로 광 스펙트럼을 활용할 수 있는 Flexible Grid WDM(FGWDM) 기술이 등장하였다. 

(각 WDM 기술 별로 파장이 나뉘어진 것이 아니라, 동일 파장대를 확장하여 사용함을 유념)

위 그림은 쉽게 잘 표현되어있어서 fibermall에서 발췌해 온 그림이다.

WDM 시스템을 고속도로에 비유하여, 각 역할을 나타낸다. 

 -고속도로: 광섬유

 -순찰차: 신호 모니터링

 -주유소: 광 증폭

 -회색 자동차: 클라이언트 측 다양한 서비스

 -컬러 자동차: 채널(파장)의 다양한 베어러 서비스 

 -레인: 광파장

1. CWDM(Coarse WDM) 

실어보낼 수 있는 채널이 10개 미만이며, Dense가 떨어지나 비용이 저렴하여, 비용측면에서 이점을 가지고 있다. 

DWDM과 유사하나, 파장 간격이 넓고(10nm 이상 20~40nm) 광 증폭기를 사용하지 않는 단거리(50km 이내) 전송에 주로 사용된다. 통상적으로 S,C,L-Band를 활용하며, 채널 파장 8개 기준 1470nm~ 1610nm 파장대를 사용한다. 파장 수를 늘리기 위해 1310nm를 이용하여 CWDM을 16개 채널로 확장할 수 있어 표준 WDM보다는 많은 채널 수를 가지지만, DWDM보다는 적은 채널수를 갖게 된다. 

CWDM 파장 스펙트럼 내에서 DWDM 채널을 매핑하면, 사이트 간 광섬유 인프라를 변경할 필요없어, 동일한 광섬유 케이블에서 훨씬 더 높은 데이터 전송 용량을 얻을 수 있다. 

2. DWDM(Dense WDM)

하나의 광섬유에 여러 개의 파장(빛)을 동시에 전송 가능하다. 최대 80개의 파장을 동시에 10Gbps 속도로 전송하며, 40~80개의 채널을 이용해 각 400Gbps의 전송 속도를 제공한다. 신호의 속도를 유지한 채 전송할 수 있는 파장 수를 증가시키는 방식으로, 광섬유당 총 전송 용량을 크게 증가 시킨 기술이다. WDM 채널보다 밀도가 높으며, 주로 C Band(1530nm ~ 1565 nm)대역에 걸쳐있다.(L-Band도 사용)

구성 요소로, 광학 송/수신기, DWDM Mux/Demux필터, 광학 Drop/Add 멀티플렉서(OADM), 광학 증폭기가 있다.

DWDM의 좁은 파장 간격은 단일 광섬유에 더 많은 채널을 적합하게 하지만, 구현 및 운용 비용이 더 많이 드는 특징이 있다. 

 DWDM 파장 간격 

이외에도 25GHz, 37.5GHz 등의 간격이 사용되나, 상용 시스템에서는 상기 표에 명시된 간격이 가장 많이 사용된다.

DWDM에서 파장 간격을 선택할 때는 "전송 용량, 광섬유 비용, 광 증폭기, 채널 간섭" 등의 요소를 고려하여 요구사항과 예산에 맞는 파장 간격을 설정해야 한다.

최근에는 Flexible Grid WDM(FGWDM) 기술이 등장하면서, 채널 간격을 사용자 정의하여 필요에 따라 사용할 수 있게 되었다. 특정 채널에 더 많은 용량을 할당하거나, 채널 간격을 최적화하여 스펙트럼 효율성과 유연성을 높일 수 있는 기술이다.

(FGWDM에 대한 내용은 아래 글을 참고)

https://kkomtech.tistory.com/15

(참고)

https://www.fibermall.com/ko/blog/things-about-cwdm-dwdm-oadm.htm

https://ko.opticalpatchcable.com/news/important-components-in-dwdm-system-33718546.html

http://www.ktword.co.kr/test/view/view.php?no=1847

https://www.fibermall.com/ko/blog/wdm-vs-otn.htm

Fixed Grid

사전적 의미 그대로, 고정된 주파수와 파장 대역을 사용한다. 

파장 대역이 고정되어 있기 때문에, 유연하게 대역폭을 조정할 수 없다.

신호 속도가 빨라지면서 광 신호 대역이 확장되었고, 여러 속도의 신호가 네트워크에서 전송되는 경우,

속도에 따른 최대 스펙트럼 대역폭이 고정 주파수 간격을 지켜야하기 때문에 손실과 낭비가 더욱 크게 발생하게 된다.

여기에서 Flexible Grid의 필요성이 나타나다.

Flexible Grid 

기존의 고정된 채널 간격 대신, 사용자 정의 채널 간격을 사용하여, 광 스펙트럼을 더욱 효율적으로 사용하는 기술이다.

즉, Fixed Grid에서 제한적이었던, 고정된 대역폭을 사용하지 않고,

다양한 데이터 전송 속도와 요구사항에 맞춰 채널 간격을 유연하게 조정할 수 있기에 대역폭 낭비가 없다는 큰 장점이 있다.

5G, 6G로 확장되면서, 테라급 고품질 대용량 장거리 신호 전달 기술이 요구되었다. 전달망에서 망의 유연성과 저전력 및 에너지 효율성, 저비용 경제성 확보가 요구된 것.

즉, 네트워크 트래픽 증가에 따라, 전송 속도는 400Gbps~최대 1Tbps로 증가하여 광 신호 스펙트럼이 넓어졌고, 에따라 유연한 스펙트럼 할당을 구현하여 효율적으로 사용하기 위한 Flexible Grid 기술이 활용된 것이다.

Flexible Grid ROADM 기술?

광신호의 분기(Drop) 및 결합(Add)뿐만 아니라, 파장 단위 스위칭(O-O-O)기반으로 회선을 재배치(Wavelength Reuse)가 가능한 기술

네트워크 트래픽 증가에 따라, 전송 속도는 400Gbps~최대 1Tbps로 증가하여 광 신호 스펙트럼이 넓어졌다.

Flexible Grid 기술은 37.5GHz ~400GHz 파장 간격을 제공할 수 있다.

Flexible Grid 장점

 1. 스펙트럼 효율성 향상: 고정된 채널 간격이 아닌, 필요에 따른 채널 간격을 최적화하여 광 스펙트럼의 활용도를 높일 수 있음.

 2. 전송 용량 증가: 더 많은 대용량의 데이터를 고품질, 장거리로 전송할 수 있음.

 3. 서비스 유연성 확보: 각기 다른 다양한 데이터 전송 속도와 요구사항에 맞춰 대역폭을 조정할 수 있음.

 4. 경제성: 기존 광통신 인프라를 활용할 수 있음.

Flexible Grid의 기술 구현은 WDM과 SDN 기술 등을 기반으로 구현된다. 

WDM기술에 대한 내용은 아래글을 확인하길 바란다.

https://kkomtech.tistory.com/16

(참고)

https://forum.huawei.com/enterprise/en/fixed-grid-vs-flexible-grid/thread/667235996061810689-667213856692383744

https://www.slideshare.net/EuncheolPark1/201610flexible-grid-roadm-pdf

https://forum.huawei.com/enterprise/en/fixed-grid-vs-flexible-grid/thread/667235996061810689-667213856692383744

광 트랜시버

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

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

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

송신단                         수신단

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

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

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

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

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

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

광 트랜시버 종류

광 트랜시버는 다양한 종류가 있으나, 그 중에서도 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

Security는 굉장히 방대하고, 어려운 파트 중 하나인데 k8s Security 역시  많은 내용을 담고있다.

k8s에서 kube-apiserver가 system component 및 Worker Node와 통신을 하는데, 이 kube-apiserver가 구성 컴포넌트에 따라 Server측이 되기도 하고, Client 측이 되기도 한다. 

물론 CA라는 신뢰된 인증서를 바탕으로, 각 구성 컴포넌트들의 인증서를 증명하는 역할을 수행한다.

k8s는 TLS를 통한 인증을 위해 PKI 인증서가 필요하다.

직접 인증키(.key)와 인증서 파일(.crt)을 생성하지 않고, kubeadm으로 k8s를 사용하게 되면, 각 Cluster에서 필요한 인증서는 자동으로 생성되어 편리하다. Private Key를 API 서버에 저장하지 않기에 더 안전하게 인증서를 생성할 수 있어 편리함과 동시에 보안성까지 더욱 갖출 수 있다.

대부분의 인증서 위치는 /etc/kubernetes/pki 디렉터리에 있다.

Root CA Certificate

최상위 인증서로, k8s의 오브젝트를 생성할 때 사용하는 최상위 인증서이다. 즉, 클러스터 내에서 발급된 다른 인증서의 진위여부를 확인하는 최상위 인증서이며, 암호화를 기반으로 기밀성과 무결성을 보장한다.

구성 컴포넌트가 주장하는 요소를 인증해주는 최상위 인증서.

-중간CA에 서명하여 개별 컴포넌트의 인증서에 서명함(신뢰성 보장)

-kubeadm과 같은 툴로 클러스터 셋업 시 자동 생성

-모든 클러스터 구성 요소에 접근할 수 있는 ConfigMap에 저장됨

Authentication of Root CA Certification

-컴포넌트 인증: 노드, api server, Controller 간 신원(인증서) 인증

-User 인증: k8s API 접근 허용 판단을 위한 사용자 인증서 검증

-워크로드 인증: 상호간 안전한 통신 채널인지 확인하기 위한 인증 수행

주의) ETCD Server의 루트CA는 별도로 관리됨(아래 참고)

kube-apiserver Certificate

아래 명령어로 kube-apiserver에 대한 설정 값과 인증서파일의 경로 및 키에 대해 알 수 있다.

cat /etc/kubernetes/manifests/kube-apiserver.yaml

apiVersion: v1
kind: Pod
metadata:
  annotations:
    kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint: 192.15.55.6:6443
  creationTimestamp: null
  labels:
    component: kube-apiserver
    tier: control-plane
  name: kube-apiserver
  namespace: kube-system
spec:
  containers:
  - command:
    - kube-apiserver
    - --advertise-address=192.15.55.6
    - --allow-privileged=true
    - --authorization-mode=Node,RBAC
    - --client-ca-file=/etc/kubernetes/pki/ca.crt
    - --enable-admission-plugins=NodeRestriction
    - --enable-bootstrap-token-auth=true
    - --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt
    - --etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt
    - --etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key
    - --etcd-servers=https://127.0.0.1:2379
    - --kubelet-client-certificate=/etc/kubernetes/pki/apiserver-kubelet-client.crt
    - --kubelet-client-key=/etc/kubernetes/pki/apiserver-kubelet-client.key
    - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
    - --proxy-client-cert-file=/etc/kubernetes/pki/front-proxy-client.crt
    - --proxy-client-key-file=/etc/kubernetes/pki/front-proxy-client.key
    - --requestheader-allowed-names=front-proxy-client
    - --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt
    - --requestheader-extra-headers-prefix=X-Remote-Extra-
    - --requestheader-group-headers=X-Remote-Group
    - --requestheader-username-headers=X-Remote-User
    - --secure-port=6443
    - --service-account-issuer=https://kubernetes.default.svc.cluster.local
    - --service-account-key-file=/etc/kubernetes/pki/sa.pub
    - --service-account-signing-key-file=/etc/kubernetes/pki/sa.key
    - --service-cluster-ip-range=10.96.0.0/12
    - --tls-cert-file=/etc/kubernetes/pki/apiserver.crt
    - --tls-private-key-file=/etc/kubernetes/pki/apiserver.key
    image: registry.k8s.io/kube-apiserver:v1.27.0
    imagePullPolicy: IfNotPresent
    livenessProbe:
      failureThreshold: 8
      httpGet:
        host: 192.15.55.6
        path: /livez
        port: 6443
        scheme: HTTPS
      initialDelaySeconds: 10
      periodSeconds: 10
      timeoutSeconds: 15
    name: kube-apiserver
    readinessProbe:
      failureThreshold: 3
      httpGet:
        host: 192.15.55.6
        path: /readyz
        port: 6443
        scheme: HTTPS
      periodSeconds: 1
      timeoutSeconds: 15
    resources:
      requests:
        cpu: 250m
    startupProbe:
      failureThreshold: 24
      httpGet:
        host: 192.15.55.6
        path: /livez
        port: 6443
        scheme: HTTPS
      initialDelaySeconds: 10
      periodSeconds: 10
      timeoutSeconds: 15
    volumeMounts:
    - mountPath: /etc/ssl/certs
      name: ca-certs
      readOnly: true
    - mountPath: /etc/ca-certificates
      name: etc-ca-certificates
      readOnly: true
    - mountPath: /etc/kubernetes/pki
      name: k8s-certs
      readOnly: true
    - mountPath: /usr/local/share/ca-certificates
      name: usr-local-share-ca-certificates
      readOnly: true
    - mountPath: /usr/share/ca-certificates
      name: usr-share-ca-certificates
      readOnly: true
  hostNetwork: true
  priority: 2000001000
  priorityClassName: system-node-critical
  securityContext:
    seccompProfile:
      type: RuntimeDefault
  volumes:
  - hostPath:
      path: /etc/ssl/certs
      type: DirectoryOrCreate
    name: ca-certs
  - hostPath:
      path: /etc/ca-certificates
      type: DirectoryOrCreate
    name: etc-ca-certificates
  - hostPath:
      path: /etc/kubernetes/pki
      type: DirectoryOrCreate
    name: k8s-certs
  - hostPath:
      path: /usr/local/share/ca-certificates
      type: DirectoryOrCreate
    name: usr-local-share-ca-certificates
  - hostPath:
      path: /usr/share/ca-certificates
      type: DirectoryOrCreate
    name: usr-share-ca-certificates
status: {}

위 인증서 관련 파라미터 중, 아래 매개변수에 대한 차이점을 이해해야 한다.

cafile

-CA(신뢰보장되는 공인 인증 기관)의 인증서 파일 경로를 지정

-Security 통신 중, 다른 Server가 제시한 인증서의 진위 여부를 확인하는데 사용함

certfile

-클라이언트의 인증서 파일 경로를 지정

-서버 인증에 사용되는 클라이언트(User or Service 계정)의 공개 키 및 ID 정보를 포함

(즉, apiserver를 ETCD서버의 클라이언트로 인증하는데 사용되는 파일은 Certfile임)

keyfile

-클라이언트 Private key 경로 지정

-클라이언트 인증서와 일치하는 개인키를 포함하여, 서명/암호화/복호화에 사용 됨

위 파라미터들은 k8s 클러스터 내에서 다양한 구성 컴포넌트 간 통신 채널의 보안 통신을 구축하는데 필수적이며, 인증서와 키 관리가 요구된다.

    - --tls-cert-file=/etc/kubernetes/pki/apiserver.crt
    - --tls-private-key-file=/etc/kubernetes/pki/apiserver.key

--tls-cert-file=/etc/kubernetes/pki/apiserver.crt  -> kube-apisever가 다른 서버를 인증할 때 사용하는 인증서

--tls-private-key-file=/etc/kubernetes/pki/apiserver.key -> kube-apiserver의 키

kube-apiserver의 인증서 세부사항 확인하기

위 kube-apiserver.yaml파일에서 참고한 kube-apiserver의 인증서를 openssl 구문으로 확인해보기

openssl x509 -in /etc/kubernetes/pki/apiserver.crt -text -noout
//openssl x509 -in [file-path.crt] -text -noout

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 4085601723811199419 (0x38b2f91f117d79bb)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN = kubernetes
        Validity
            Not Before: Jan 21 12:34:27 2024 GMT
            Not After : Jan 20 12:34:27 2025 GMT
        Subject: CN = kube-apiserver
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    00:e7:6c:c7:70:5d:a9:e7:0b:49:eb:09:b4:26:e1:
                    4c:1d:ea:9a:ee:bc:54:cc:c7:a2:f8:11:ae:f8:b3:
                    40:b8:6e:15:f6:ca:db:36:b1:9d:82:ea:5b:10:28:
                    92:43:8c:a5:3e:88:48:7c:01:84:78:64:9f:4e:7f:
                    ec:ed:16:67:b3:97:1c:78:25:9a:2b:5b:86:69:7b:
                    78:32:39:2d:90:aa:b7:82:71:eb:9c:81:96:20:4f:
                    72:11:04:10:fe:55:68:1a:47:10:c6:d2:ae:04:15:
                    ba:b3:c3:f5:24:1e:d5:e4:a8:fe:c0:0e:5d:02:41:
                    73:d9:95:71:66:74:c3:85:f8:ca:51:a8:d9:1c:db:
                    fa:23:dc:81:44:58:32:99:ae:1a:a6:25:f5:79:ef:
                    eb:69:a2:2b:1a:66:32:c3:1f:85:74:90:ac:36:43:
                    d3:8b:38:79:5e:15:c2:1d:6a:b4:45:87:91:ea:d8:
                    3c:e4:91:68:e1:c3:c7:5a:4a:91:35:cd:f4:b9:4b:
                    08:66:15:43:62:da:19:c9:8d:ee:25:ac:3b:2f:e6:
                    51:79:1d:4a:62:ba:3c:08:1d:a8:65:a8:1a:b3:5f:
                    aa:5d:7c:7f:46:82:46:ee:d3:18:e7:54:7e:dc:63:
                    24:71:f3:7b:67:76:75:3d:02:ea:e3:e1:5e:5b:cd:
                    2d:b7
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Authority Key Identifier: 
                keyid:90:DF:4D:87:6F:E6:C7:51:F4:17:A4:48:81:33:FA:BF:FE:A9:07:DA

            X509v3 Subject Alternative Name: 
                DNS:controlplane, DNS:kubernetes, DNS:kubernetes.default, DNS:kubernetes.default.svc, DNS:kubernetes.default.svc.cluster.local, IP Address:10.96.0.1, IP Address:192.20.97.8
    Signature Algorithm: sha256WithRSAEncryption
         64:97:ac:63:e1:48:a5:14:c4:a8:53:06:0c:eb:32:21:a0:69:
         4f:bc:23:44:6d:9b:4f:88:b1:d9:b3:06:90:53:ff:f8:b9:c2:
         33:42:7e:91:bf:87:53:1e:7a:9b:9d:22:82:4e:d2:4a:7b:e9:
         06:f6:82:4b:ad:06:78:dd:b0:97:26:ef:88:54:a3:9a:0f:bc:
         ee:07:cc:73:0a:69:03:1a:2d:bf:d7:23:9a:f4:78:1c:86:55:
         5e:d6:64:8a:a7:e5:4d:11:27:40:9d:97:5c:4a:a8:99:80:57:
         74:cf:4c:c5:b2:47:0c:dd:19:fe:d6:cd:16:87:e5:16:7a:af:
         99:45:6b:2a:ac:8b:48:85:ac:e6:f7:c2:8e:40:6b:cb:da:2f:
         63:9f:d6:68:6c:67:0f:d6:78:c7:b3:36:5f:76:ce:46:ea:8f:
         53:62:0b:68:d4:59:19:20:a6:d7:dc:be:2b:5c:f8:f7:1a:1e:
         1f:83:50:d8:b7:ec:ae:ca:7d:46:69:5d:27:07:08:c5:9e:f4:
         92:80:17:26:47:25:66:3a:95:8f:23:c4:bd:82:1b:a9:3c:e5:
         14:af:42:58:44:38:1f:8e:18:95:39:57:b1:76:ec:69:5e:c1:
         eb:ae:63:05:77:34:d1:15:80:b0:43:d6:c2:b0:ba:52:ec:c6:
         e1:7a:41:ca

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 4085601723811199419 (0x38b2f91f117d79bb)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN = kubernetes  //CA 인증서 발급자 확인
        Validity
            Not Before: Jan 21 12:34:27 2024 GMT
            Not After : Jan 20 12:34:27 2025 GMT		//인증서 유효성 확인(만료일자)
        Subject: CN = kube-apiserver	//CN 확인

CA 발급자와 인증서 유효기간, CN 등을 위에서 확인 가능하다.

X509v3 Subject Alternative Name: 
                DNS:controlplane, DNS:kubernetes, DNS:kubernetes.default, DNS:kubernetes.default.svc, DNS:kubernetes.default.svc.cluster.local, IP Address:10.96.0.1, IP Address:192.20.97.8
    Signature Algorithm: sha256WithRSAEncryption

위에서 확인 시, kube-apiserver의 Alternative Name을 모두 확인 할 수 있다.

kube-apiserver는 그 자체를 k8s라고 볼 수 있는데, 모든 구성 컴포넌트들과 연결되어 통신하고 상태를 체크하기 때문이다.

따라서, 각 구성 컴포넌트들과 어떤 때는 kube-apiserver가 서버이기도, 클라이언트이기도 하기 때문에 

불려지는 Name이 다양하다. 이를 모두 식별하기 위해 

X509v3 Subject Alternative Name: 아래에 정보가 담겨있다.

ETCD Server Certificate

ETCD Server와 관련된 정보는 아래 경로 디렉터리 내 etcd.yaml 파일에서 확인할 수 있다.

cat /etc/kubernetes/manifests/etcd.yaml

apiVersion: v1
kind: Pod
metadata:
  annotations:
    kubeadm.kubernetes.io/etcd.advertise-client-urls: https://192.20.97.8:2379
  creationTimestamp: null
  labels:
    component: etcd
    tier: control-plane
  name: etcd
  namespace: kube-system
spec:
  containers:
  - command:
    - etcd
    - --advertise-client-urls=https://192.20.97.8:2379
    - --cert-file=/etc/kubernetes/pki/etcd/server.crt
    - --client-cert-auth=true
    - --data-dir=/var/lib/etcd
    - --experimental-initial-corrupt-check=true
    - --experimental-watch-progress-notify-interval=5s
    - --initial-advertise-peer-urls=https://192.20.97.8:2380
    - --initial-cluster=controlplane=https://192.20.97.8:2380
    - --key-file=/etc/kubernetes/pki/etcd/server.key
    - --listen-client-urls=https://127.0.0.1:2379,https://192.20.97.8:2379
    - --listen-metrics-urls=http://127.0.0.1:2381
    - --listen-peer-urls=https://192.20.97.8:2380
    - --name=controlplane
    - --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
    image: registry.k8s.io/etcd:3.5.7-0
    imagePullPolicy: IfNotPresent
    livenessProbe:
      failureThreshold: 8
      httpGet:
        host: 127.0.0.1
        path: /health?exclude=NOSPACE&serializable=true
        port: 2381
        scheme: HTTP
      initialDelaySeconds: 10
      periodSeconds: 10
      timeoutSeconds: 15
    name: etcd
    resources:
      requests:
        cpu: 100m
        memory: 100Mi
    startupProbe:
      failureThreshold: 24
      httpGet:
        host: 127.0.0.1
        path: /health?serializable=false
        port: 2381
        scheme: HTTP
      initialDelaySeconds: 10
      periodSeconds: 10
      timeoutSeconds: 15
    volumeMounts:
    - mountPath: /var/lib/etcd
      name: etcd-data
    - mountPath: /etc/kubernetes/pki/etcd
      name: etcd-certs
  hostNetwork: true
  priority: 2000001000
  priorityClassName: system-node-critical
  securityContext:
    seccompProfile:
      type: RuntimeDefault
  volumes:
  - hostPath:
      path: /etc/kubernetes/pki/etcd
      type: DirectoryOrCreate
    name: etcd-certs
  - hostPath:
      path: /var/lib/etcd
      type: DirectoryOrCreate
    name: etcd-data
status: {}

ETCD Server의 CA 인증서는 kube-apiserver의 CA와는 달리 별도로 관리된다.

--cert-file=/etc/kubernetes/pki/etcd/server.crt -> ETCD Server Certificate file 경로

--trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt  -> ETCD Server 루트 CA 경로

ETCD Server 인증서 세부사항 확인하기

위 etcd.yaml파일에서 참고한 인증서를 openssl 구문으로 확인해보기

openssl x509 -in /etc/kubernetes/pki/etcd.crt -text -noout
//openssl x509 -in [file-path.crt] -text -noout

openssl x509 -in /etc/kubernetes/pki/etcd/server.crt -text -noout
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 3764440671794400025 (0x343dfad89c568b19)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN = etcd-ca
        Validity
            Not Before: Jan 21 12:34:28 2024 GMT
            Not After : Jan 20 12:34:28 2025 GMT
        Subject: CN = controlplane
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    00:a5:a1:db:df:4e:ff:85:2a:ad:d9:a4:9e:bd:6f:
                    0f:90:14:fd:e1:5c:97:ce:b0:68:69:ca:e6:de:64:
                    79:ad:76:52:de:4d:7e:14:b9:db:7d:42:79:b0:a4:
                    42:19:bd:72:46:66:6f:13:7a:0a:ff:34:d5:c7:eb:
                    02:36:3d:3d:d4:61:8a:89:36:d0:8c:f4:80:c9:52:
                    ba:e7:e2:f8:5a:dc:80:a4:2a:a0:e1:ba:5c:a7:25:
                    fb:d7:88:cf:91:7b:c4:ac:c7:fb:76:5c:1d:33:b7:
                    a8:93:e4:3f:5e:51:28:20:0b:0b:bd:10:1c:60:09:
                    5e:ec:1f:32:77:a9:78:ce:26:0e:35:71:0f:6d:62:
                    a7:f0:e0:35:e2:a4:0e:1e:dd:b5:0c:0e:95:db:40:
                    50:55:e8:f4:e8:77:dd:64:e1:cd:8e:1d:70:83:bd:
                    57:f8:5c:d9:44:3e:8c:6a:4a:da:ee:8d:ab:96:bb:
                    42:b3:bb:12:77:d9:cf:81:ea:47:d7:57:97:1f:df:
                    03:7b:b3:56:a4:52:e4:b7:32:3c:65:3a:7c:25:39:
                    8b:1e:7f:38:50:5a:89:67:4b:56:58:08:7b:9c:8e:
                    5f:e8:f3:bc:f3:1a:de:03:f2:e3:3e:ed:4b:e8:55:
                    a2:26:df:93:3a:58:ed:53:c2:66:00:12:b6:39:ca:
                    29:0b
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Authority Key Identifier: 
                keyid:E2:27:56:BC:4E:14:35:E4:B9:4E:12:05:35:D6:D0:82:A1:B2:10:18

            X509v3 Subject Alternative Name: 
                DNS:controlplane, DNS:localhost, IP Address:192.20.97.8, IP Address:127.0.0.1, IP Address:0:0:0:0:0:0:0:1
    Signature Algorithm: sha256WithRSAEncryption
         88:98:8f:41:5b:ad:1f:0b:63:2e:57:f6:b3:64:c5:c7:fa:9b:
         89:d0:23:06:92:49:1d:b0:47:40:30:96:b5:0a:6b:6b:36:af:
         86:0d:c9:fd:0e:6a:20:d6:ee:e8:f2:50:51:89:6e:9e:e2:ae:
         5a:c6:4c:a7:42:63:ee:62:20:bc:e0:a2:d6:5c:ba:e4:ea:ec:
         cf:01:e3:83:6a:29:32:f4:1d:16:e1:37:96:bb:f7:c7:27:44:
         85:0c:60:14:68:8d:d5:ec:dd:b7:20:3c:23:53:89:22:23:d1:
         91:35:0f:66:2e:94:c7:c0:c5:e0:19:ec:c3:4a:f8:83:71:6c:
         6a:88:b2:b0:51:55:c9:c8:ba:19:21:00:d0:5a:d2:b6:52:9b:
         36:00:8d:3d:32:65:8d:d7:53:9e:fe:a8:97:eb:b4:b5:36:bf:
         fe:be:fd:2a:ea:06:83:b5:c3:17:e0:f4:19:c7:44:6e:dc:d7:
         f3:2c:b7:cb:b7:28:07:cd:49:8d:fe:c0:f5:86:85:41:2d:32:
         d4:4b:75:f5:87:20:8a:58:a1:3a:97:88:fb:d6:f1:1e:e2:2f:
         7b:d6:1a:df:50:33:64:30:bc:28:4a:91:13:05:74:a9:ba:6f:
         81:07:82:2d:cf:9d:66:b0:84:9d:42:c3:fb:90:da:f6:11:94:
         d2:0a:d8:9a

광통신에서 분산이란?

분산(Dispersion)

광섬유 내 진행하는 빛 또는 광 펄스의 퍼짐(분산) 현상으로, 광섬유 내부에 빛이 전송되는 코어와, 빛을 굴절시키는 클래드로 구성.

코어의 직경에따라 굴절 정도가 달라지게되며, 코어의 직경과 굴절률에 따라 빛이 전파되는 방식이 달라짐

1) 모드 간 분산(Intermodal Dispersion) -다중모드 광섬유 (Multi Mode Fiber)

입력 펄스가 다중 모드로, 다수가 전송되면서 다른 시차로 모이는과정에서 펄스가 분산되는 것

-코어의 직경이 크고, SMF에 비해 전송 손실이 높음 특징

2) 모드 내 분산(Intramodal Dispersion) -단일모드 광섬유(Single Mode Fiber)

Fiber Dispersion이라고 불리며, 입력 펄스 내 여러 성분(스펙트럼, 편광)들이 각기 다른 속도를 가지면서 펄스 퍼짐 현상으로, 색 분산과 편광모드 분산이 있다.

-광섬유 코어 안 빛의 모드가 1개인 단일 모드로, 코어의 직경이 매우 작은 특징

-표준 SMF, DSF(분산 천이형 광섬유), NZ-DSF(비 영분산 광섬유) 등

 1. 색 분산(Chromatic Dispersion) 

 각 파장 성분(다른 빛)들의 전파 속도가 서로 달라 나타나는 광 분산 현상으로, 10Gbps까지의 단일모드광섬유(SMF)에서 가장 큰 문제

색 분산이 0이 되게 하는 파장(=영분산 파장)을 이용하여 고속 통신 가능: 전송 대역 파장 영역에서 분산이 0이 되도록 천이시키는 것

 >>영 분산점(Zero Dispersion Point): 단일모드 광섬유를 통한 광 전파 시, 단/장파장 성분이 같은 속도를 보이는 파장 점(1300nm 부근)으로, SMF에서 색분산 영향을 줄이는데 활용됨

 2. 편광모드 분산(Polarization Mode Dispersion)

광 신호가 광섬유를 따라 전송되는 과정에서, 광이 직각을 이루면서 다른 속도로 이동하는 편광모드가 원인이 되어 나타나는 분산 현상

시간, 파장, 온도, 진동, 압력 등 다양한 요인에 의해 발생되며 제어하기 까다로움 

-편광제어기 등을 이용하여 각각의 편광에 서로 다른 지연을 적용하여 속도 차이를 줄이는 방법 등으로 보정

[정보통신기술용어해설]

http://www.ktword.co.kr/test/view/view.php?no=2045

DBeaver란?

무료 DB 관리 Tool(DBMS(Database Management System)로,

자바와 이클립스 기반으로 개발되었다.(윈도우, 리눅스 맥OS에서 사용 가능)

jdbc 기반으로 DB를 연결하여, 다양한 DBMS(오라클, MySQL, PostgreSQL, 마리아디비 등등)를 사용할 수 있다.

DBMS를 왜 이용해야 할까?

관리 툴을 이용해야 데이터베이스에 들어가 있는 데이터의 관리(저장/백업/클린 데이터)가 쉬워지기 때문이다. 

1. DBeaver Community 접속 후, OS에 맞는 설치 파일 다운로드 받기

https://dbeaver.io/download/

2. 다운로드 받은 설치 파일 진행

3. 설치 완료 확인

DBeaver이 지원하는 DB 목록 확인하여 사용하기

맥북/아이맥 등으로 개발 환경을 설정할 때, 홈브류(homebrew)는 반드시 설치 해야 한다. 

왜? 

명령어 한 줄로 각종 프로그램과 이미지 등을 설치/제거 할 수 있어

맥OS의 개발환경 편의성을 높여주는 대표적인 애플리케이션이기 때문이다. 

Homebrew란?

macOS용 Package 관리 애플리케이션으로, 각종 프로그램 및 이미지 파일 등을 터미널에서 cmd로 간편하게 설치 할 수 있다. 

1. Homebrew를 설치하자 

아래 사이트로 이동하여 Install Homebrew의 명령어를 복사한다.

https://brew.sh/

명령어 오른쪽의 아이콘을 클릭하여 쉽게 복사 후,(혹은 아래 명령어 복사하기) iTerm에 입력하면 설치 완료

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

설치 완료 후, 버전을 확인하면서 설치 정상 완료 여부를 확인한다.

brew --version

2. homebrew 설치 완료 후, nvm을 설치한다. 

nvm이란?

node version manager의 약자로, Node.js의 여러 버전을 손쉽게 설치할 수 있도록 도와주며, 사용자는 여러 버전의 Node.js를 호환성을 확보하여 사용할 수 있다. 

brew install nvm

3. nvm 환경 변수를 등록하자

java 환경 변수를 설정했던 ~/.bash_profile에 vi 편집기를 이용해 아래 nvm환경변수 설정 커맨드를 입력한다.

export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0_311.jdk/Contents/Home
export PATH=${PATH}:$JAVA_HOME/bin


export NVM_DIR="$HOME/.nvm"
[ -s "/opt/homebrew/opt/nvm/nvm.sh" ] && \. "/opt/homebrew/opt/nvm/nvm.sh"  # This loads nvm
[ -s "/opt/homebrew/opt/nvm/etc/bash_completion.d/nvm" ] && \. "/opt/homebrew/opt/nvm/etc/bash_completion.d/nvm"  # This loads nvm bash_completion

설정한 환경 변수를 source 명령어를 통해 적용한다.

source ~/.bash_profile

>>lts 버전 설치하기

LTS버전 이란?

Long Term Support 버전을 다운로드 받는 것으로, LTS버전은 앞에 짝수단위의 버전으로, 보다 안정적이로 오랜 기간을 지원하는 버전이다. 꼭 LTS 버전이 아니더라도 원하는 버전을 설치할 수 있는데, 설치 가능한 Node 버전 목록을 확인할 수 있다.(아주 많음)

nvm list-remote

설치해보자

nvm install --lts