부산시는 30일 오후 4시에 부산빅데이터혁신센터에서 '클라우드 컴퓨팅 기반의 데이터 분석·활용' 포럼을 개최할 예정입니다. 이번 포럼은 부산시가 운영하는 '디지털전환(DX)포럼'의 8번째 프로그램으로, 부산에서 빅데이터 관련 최신 기술과 동향 등의 정보를 습득하고 발전 방향을 모색하기 위해 개최됩니다.

클라우드 컴퓨팅은 대량의 데이터를 처리하고 저장하는 데 필수적인 기술이며, 데이터의 효과적인 활용을 위해 클라우드 서비스가 안정적이고 유연하게 제공됩니다.

이번 포럼은 세 개의 세션으로 구성되어 있으며, 첫 번째 세션은 '클라우드 기반의 빅데이터로 500만 명의 취향 저격하기'로서 클라우드 인프라 전문가인 정태환 밀리의서재 팀장이 발표자로 참여합니다. 두 번째 세션은 '지금 당신의 엘리베이터에, 클라우드 기반의 디지털 옥외광고 혁신'이라는 주제로 정윤진 포커스미디어코리아 최고기술경영자(CTO)가 발표를 진행할 예정입니다. 세 번째 세션에서는 아마존웹서비스(AWS)의 민지수 솔루션즈 아키텍트가 '데이터 분석, 가장 쉽게 시작하는 방법!'에 대해 강연할 예정입니다.

이 포럼을 통해 클라우드 컴퓨팅 기반의 데이터 분석과 활용에 대한 지식과 정보를 공유하고 소통함으로써 신규 수입 모델 발굴과 경영혁신을 위한 계기가 될 것으로 기대됩니다. 포럼 참가를 원하시는 분들은 부산빅데이터혁신센터의 누리집 '디엑스(DX)챌린지'를 통해 신청하시면 됩니다.

출처: https://newsis.com/view/?id=NISX20230529_0002319642&cID=10811&pID=10800 

목차로 이동

한국에서 SaaS(Software as a Service)가 주목받고 있습니다. SaaS는 클라우드 기반의 소프트웨어 제공 모델로, 클라우드 제공업체가 애플리케이션 소프트웨어를 개발하고 유지 관리하여 인터넷을 통해 최종 사용자에게 제공하는 형태입니다. SaaS의 주요 장점은 높은 접근성과 이용 편의성, 비용 절감, 유연성과 확장성입니다.

높은 접근성과 이용 편의성은 사용자가 언제 어디서나 인터넷 브라우저나 모바일 앱을 통해 서비스에 접근할 수 있다는 장점을 의미합니다. 또한, 기존의 소프트웨어 구매 및 설치에 필요한 초기 투자 비용이 크게 감소하고, SaaS 제공 업체가 유지 보수를 책임지므로 관리 부담도 해소됩니다. 또한, 사용자는 필요에 따라 구독 서비스를 조정할 수 있어 유연한 작업 환경을 제공받을 수 있습니다.

국내에서도 SaaS를 통해 비즈니스를 진행하는 기업들이 늘어나고 있습니다. 삼성SDS, SK㈜ C&C, 이노그리드 등이 SaaS를 활용한 솔루션을 개발하고 공급하고 있습니다. 국내 SaaS 시장은 미래에도 성장이 기대되며, 한국 IDC에 따르면 향후 5년간 연평균 15.5%의 성장률을 기록할 것으로 전망되고 있습니다.

글로벌 시장에서도 SaaS는 확대되고 있으며, 연평균 19.7% 성장하여 2029년에는 8833억 4000만 달러에 이를 것으로 예상됩니다. 이에 따라 업계에서는 소프트웨어 산업 경쟁력 강화와 민·관 협력을 통한 투자 확대, SaaS 친화 정책의 필요성을 강조하고 있습니다. 정부도 관련 정책을 펼치며 국내 SaaS 기업의 확대와 해외 진출을 지원할 예정입니다.

출처: https://www.epnc.co.kr/news/articleView.html?idxno=233438 

목차로 이동

엔비디아는 인공지능(AI) 대중화를 이끌면서 AI 연산에 사용되는 전용 반도체를 제공하여 독보적인 경쟁력을 갖고 있습니다. 이로 인해 엔비디아는 AI를 개발하고 운영하는 전체 생태계를 포함하는 기업으로 성장하고자 합니다. 데이터센터 분야에서의 매출이 증가하며, 게임용 제품 매출은 감소하였지만 전체 매출은 큰 폭으로 감소하지 않았습니다.

엔비디아는 주요 클라우드서비스제공자(CSP)와 인터넷 기업, 일반 산업군과의 협력을 통해 AI를 도입하는 기업들과 널리 협력하고 있습니다. 엔비디아의 GPU 기반 제품들은 메타와 같은 인터넷 기업들에 의해 사용되고 있으며, 자동차, 금융, 통신 등 다양한 산업군에서도 AI 수요가 높아지고 있습니다.

엔비디아는 낮은 비용을 추구하며, AI 도입 및 운영에 필요한 총소유비용(TCO)을 줄이는 것에 주력하고 있습니다. 또한, 소프트웨어 생태계를 구축하여 운용과 개발을 지원하며, 다양한 AI 서비스들이 엔비디아의 GPU 기반으로 작동하도록 하는 전략을 추구하고 있습니다.

엔비디아는 AI 개발에 필요한 제품들을 공급하고 있으며, 생성형 AI 시장 공략을 위해 다양한 영역에 특화된 제품을 출시하고 있습니다. 또한, GPU를 사용하는 가속 컴퓨팅으로의 전환을 예상하고 있으며, AI 반도체 시장에서의 지배력을 더욱 확대할 계획입니다.

엔비디아의 CEO인 황 CEO는 생성형 AI 시대에 가속 컴퓨팅을 도입하기 위한 경쟁이 거세지고 있다며, 이에 대응하기 위해 공급을 확대할 계획이라고 밝혔습니다.

출처: https://www.bloter.net/news/articleView.html?idxno=602114 

목차로 이동

네이버는 정치적 민감성이 있는 국가들에 맞춤형 AI 시스템을 개발하는 것에 집중하고 있습니다. 이를 통해 자국의 정치 및 문화적 맥락을 고려한 애플리케이션을 제공하고 있으며, 마이크로소프트와 구글과는 다른 전략을 채택하고 있습니다. 네이버는 최근 사우디아라비아와의 예비 계약을 통해 디지털 경제 전환을 지원하는 AI 도구를 제공하기로 했습니다.

네이버는 자체 개발한 AI 모델을 해외에 수출하는 것을 중요한 사업으로 여기고 있습니다. 성낙호 네이버클라우드 하이퍼스케일 AI 기술 총괄은 네이버의 AI 모델 수출을 "원자력 발전소를 건설해 운영을 돕는 것과 비슷하다"고 비유하며, 낮은 가격으로 서비스를 제공할 수 있다고 주장하고 있습니다. 그러나 일부 전문가들은 네이버의 AI 시스템이 해외 시장에서 성공할 가능성에 대해 비관적인 견해를 제시하고 있습니다.

네이버는 현지화된 AI 시스템의 중요성을 강조하며, 해외에서의 기회를 노리고 있습니다. 그러나 현재는 한국과 일본 시장에 집중하고 있으며, 올여름에는 한국어 학습량이 가장 큰 '하이퍼클로바X'를 출시할 예정입니다. 네이버는 자사의 AI 기술이 한국어 서비스에 적합하다고 주장하고 있습니다.

FT는 네이버가 한국의 AI 생태계 개발에 선두에 서고 있으며, 삼성전자와의 협력을 통해 AI에 최적화된 칩을 개발하고 있다고 보도했습니다. 또한 네이버는 한국에서 구글에 비해 검색 시장에서 지배적인 위치에 있으며, 구글의 한국어 AI 서비스 출시로 인해 치열한 경쟁에 직면할 가능성이 높아졌다고 언급되었습니다.

출처: https://www.bloter.net/news/articleView.html?idxno=602117 

목차로 이동

서울 광화문 포시즌스 호텔에서 만난 시스코 글로벌파트너사업 수석 부사장은 한국을 빠르게 혁신할 수 있는 얼리어답터 국가로 극찬했습니다. 한국은 DX(디지털 전환) 전환을 적극 추구하고 있는 모범 사례이며, 신기술을 시험해볼 수 있는 롤모델로 보입니다. 시스코는 한국을 중요한 시장으로 꼽고 있으며, 한국의 정부 지원과 잘 구축된 광대역 통신망을 강조하고 있습니다. 또한, 시스코는 생성AI 확산에 따른 네트워크 서비스 수요 증가에 대비하고 있으며, 보안 솔루션에서도 머신러닝과 AI 기술을 도입하고 있다고 밝혔습니다. 시스코는 다양성을 확보하고 지역사회에 기여하기 위해 노력하고 있으며, 직원들의 사회공헌을 적극 장려하고 있다고 소개되었습니다.

출처: https://www.hankyung.com/it/article/202305284339i

목차로 이동

가전업계에서는 IoT 시장을 주력으로 성장 동력을 모색하고 있습니다. 매터(Matter)라는 IoT 통신 표준에 관심이 집중되고 있으며, 삼성전자와 LG전자를 포함한 다양한 기업들이 참여하고 있습니다. 매터는 다양한 제조사의 IoT 플랫폼과 호환되어 소비자에게 편의성을 제공합니다. 삼성전자는 이미 매터를 스마트싱스 플랫폼에 적용하고 있으며, 정부의 사업에도 참여하여 IoT 기기 개발과 확산에 기여하고 있습니다. 전 세계 가전 연합체인 HCA와도 협력하고 있어 IoT 시장의 성장 가능성이 큽니다. 예상에 따르면 매터 1.2 버전의 출시로 대형 기기를 포함한 IoT 시장이 더욱 성장할 것으로 전망됩니다. 

출처: https://www.mk.co.kr/news/business/10747067

목차로 이동

교육 및 지식 공유 플랫폼 클라썸의 대표는 인공지능(AI) 기반 유사질문 추천 기능인 'AI 도트'가 사내 데이터를 활용하여 답변하기 때문에 사용자는 정보 출처를 확인하고 신뢰도를 판단하여 활용할 수 있다고 설명했습니다. 클라썸은 기업에서 활용하는 솔루션에 AI를 적용하여 데이터 맥락을 이해하고 업무 질의에 대답하는 역할을 수행할 수 있도록 개발되었습니다. 대구 연구특구개발진흥재단은 클라썸의 AI 도트를 활용하여 업무 질의응답 시스템을 구축하고 단순업무 최소화와 혁신적인 업무 프로세스를 이루었습니다. 또한, 클라썸의 AI 도트 2.0은 GPT-3.5 언어모델을 기반으로 하여 내부 데이터를 활용한 질의응답을 지원합니다. 클라썸은 국내외에서 유망한 기업으로 선정되어 있으며, 데이터 관리와 기업 성공을 위해 사내 지식과 노하우를 디지털화하여 AI가 학습하도록 함으로써 생산성 향상을 도모하고자 합니다. 

출처: https://www.fnnews.com/news/202305281948481208

목차로 이동

샘 올트먼 오픈AI CEO가 AI에 대한 규제를 강조하며 새로운 AI 정책을 수립하기 위해 주요 국가를 방문하고 있다. 이러한 움직임으로 인해 미국 빅테크 기업들이 AI 규제 국제 기준을 마련하는 데 영향력을 발휘하고 있다는 관측이 나왔다. 미국과 유럽연합(EU)은 혁신 AI 서비스에 대한 신경전을 벌이고 있으며, EU는 고강도 규제를 예고하고 AI 개발 기업이 데이터 출처와 저작권을 공개하도록 요구하는 AI Act 초안을 마련했다. 이에 대해 올트먼 CEO는 민주적인 방법으로 정책을 도입하자고 제안하며 유럽식 고강도 규제 움직임에 대한 우려를 표출했다. 미국 행정부도 빅테크 기업의 의견을 수렴하여 AI 정책을 전개하고 있다. 현재 미국과 중국은 AI 주도권을 두고 치열한 경쟁을 벌이고 있는 가운데, 미국이 AI 서비스의 위험성에 대해 더 신중한 정책을 펼치는 이유는 AI 패권 경쟁에서 스스로 경쟁력을 포기하는 위기의식이 팽배하기 때문이다. 또한 중국도 AI 규제 초안을 마련하여 생성형 AI 서비스 이용자는 실명을 사용해야 하고, 보안평가를 실시해야 한다는 규정을 제시했다.

출처: https://n.news.naver.com/mnews/article/009/0005136494

목차로 이동

한국과 중국의 통상담당 장관급 인사가 만나 반도체 협력을 논의했습니다. 중국 정부는 회담 후 보도자료를 통해 양국이 반도체 산업망과 공급망 협력을 강화하기로 합의했다고 밝혔습니다. 그러나 한국 정부는 반도체에 대한 언급 없이 교역과 투자 안정화를 논의했다는 내용의 보도자료를 발표했습니다. 이로 인해 중국이 반도체 협력을 강화하기 위해 한국에 손을 내민 것으로 해석되고 있습니다. 미·중 '반도체 전쟁'이 격화하는 상황에서 중국이 한국과의 반도체 협력 필요성을 절실히 느끼고 있는 것으로 분석됩니다.

출처: https://n.news.naver.com/mnews/article/015/0004849767

목차로 이동

캐나다 연방정부와 주정부가 개인정보 침해 여부를 규명하기 위해 챗GPT 개발사인 오픈AI를 합동 조사하고 있습니다. 캐나다 개인정보 보호기관인 프라이버시위원회는 앨버타주 등 3개 주와 협력하여 오픈AI를 조사하는 계획을 밝혔습니다. 이 조사는 개인정보에 대한 국민적 관심을 반영하여 진행되고 있으며, 사용자의 개인정보를 불법적으로 수집, 사용, 공개하는 문제에 대한 민원을 접수한 것을 바탕으로 진행됩니다. 프라이버시위는 오픈AI가 사용자로부터 '유효하고 유의미한' 동의를 받았는지, 개인정보를 불법적으로 활용했는지 등을 조사할 예정입니다. 이와 관련해 캐나다 녹색당 의원은 디지털정보 보호를 강화하기 위해 조사가 마무리되기 전에 초당적 태스크포스를 구성하는 것이 중요하다고 강조했습니다.

출처: https://n.news.naver.com/mnews/article/015/0004849732

목차로 이동

포스코그룹은 모든 계열사에서 이용할 수 있는 임직원용 '포스코형 초거대 인공지능(AI)'을 개발하고 있습니다. 이 AI는 내부 및 외부 정보를 수집하여 원하는 지식을 빠르고 정확하게 제공하는 '지식 Q&A' 서비스입니다. 포스코그룹은 이 서비스를 전 계열사에 제공하여 차세대 소재 개발에 속도를 낼 계획이며, 세계 논문, 특허, 전문 서적 등을 검색하여 원하는 정보를 추출하는 방식을 사용합니다. 이를 통해 연구원들은 자료 검색에 소요되는 시간을 크게 줄일 수 있게 됩니다. 포스코그룹은 고체 전해질 개발이나 실리콘 음극재, 하이망간 배터리 등의 차세대 소재 개발에 이 AI를 활용할 예정입니다. 포스코는 자체 개발된 AI를 통해 업무 생산성을 높일 수 있으며, 동시에 보안 문제를 우려할 필요 없이 회사 정보를 보호할 수 있다고 기대하고 있습니다.

출처: https://n.news.naver.com/mnews/article/015/0004849760

목차로 이동

LG전자는 오는 31일에 이동식 대형 스크린 '스탠바이미 고(GO)'를 출시할 예정입니다. 이 제품은 '007 가방' 모양으로 디자인되어 캠핑족을 대상으로 한 것으로 분석되고 있습니다. 스크린 대각선 길이는 약 68㎝(27형 크기)이며 가격은 100만~110만원대입니다. 스탠바이미 고는 이전 모델인 스탠바이미와 마찬가지로 대형 스크린 모니터와 스탠드로 구성되어 있으며 최장 3시간 동안 전원 연결 없이 사용할 수 있습니다. 그러나 이 제품은 가방 일체형으로, 가방 한쪽 면에 대형 스크린과 스탠드가 부착되어 있습니다. 가방을 열면 대형 스크린이 펼쳐지고 스탠드를 통해 높낮이를 조절할 수 있습니다. 이 제품은 야외 활동에 적합하게 설계되었으며 LG전자는 가정 및 사무실에서도 사용할 수 있도록 고려하였습니다.

출처: https://n.news.naver.com/mnews/article/015/0004849756

목차로 이동

국내 배터리 업계인 LG에너지솔루션, 삼성SDI, SK온 등은 배터리 산업의 폭발적인 성장으로 필요한 인력을 확보하기 위해 공격적인 인재 채용에 나서고 있습니다. LG에너지솔루션은 LG그룹 통합 채용 사이트인 'LG커리어스'를 통해 신입과 경력 인재를 모집하고 있으며, 글로벌 인재 확보에도 힘을 쏟고 있습니다. 삼성SDI는 경력사원 채용을 진행하고 있으며, 회사 전 부문에서 50여 개 직무에 필요한 인력을 모집하고 있습니다. SK온은 신입사원 수시 채용을 진행하고 있으며, 연구개발, 엔지니어, 경영지원 등 다양한 분야에서 인재를 찾고 있습니다. 이러한 업체들은 대학이나 연구소와 산학협력하거나 계약학과를 신설하여 우수 인재를 육성하고 확보하고 있습니다. 배터리 업계 직원 수도 증가하여 작년 말에 비해 약 3605명 증가한 것으로 나타났습니다.

출처: https://n.news.naver.com/mnews/article/015/0004849750

목차로 이동

아래 포스팅과 내용이 이어집니다!

앰배서더 컨테이너를 이용한 API 서버 통신 간소화

HTTPS, 인증서, 인증 토큰을 다루는 일은 때때로 너무 복잡해 보일 때가 있습니다. 종종 서버 인증서의 유효성 검사를 비활성화하는 경우를 많이 있습니다. 실제로 이러한 사유로 공겨을 당해 보안 이슈가 공개 되는 경우도 있었구요. 다행히 보안을 유지하면서 통신을 훨씬 간단하게 만들 수 있는 방법이 있습니다.

바로 전 포스팅에서 kubectl proxy 명령을 다루었습니다. API 서버에 좀 더 쉽게 액세스할 수 있도록 로컬 컴퓨터에서 명령을 실행했습니다. API 서버로 직접 요청을 보내는 대신 프록시로 요청을 보내 인증, 암호화 및 서버 검증을 처리하게 합니다. 파드 내에서도 동일한 방법을 사용할 수 있습니다.

앰배서더 컨테이너 패턴 소개

API 서버를 쿼리해야 하는 애플리케이션이 있다고 가정하고 이전에 proxy를 다루었던 것처럼 API 서버와 직접 통신하는 대신 메인 컨테이너 옆의 앰배서더 컨테이너에서 kubectl proxy를 실행하고 이를 통해 API 서버와 통신할 수 있습니다.

API 서버와 직접 통신하는 대신 메인 컨테이너의 애플리케이션은 HTTPS 대신 HTTP 로 앰배서더에 연결하고 앰배서더 프록시가 API 서버에 대한 HTTPS 연결을 처리하도록 해 보안을 투명하게 관리할 수 있습니다. 시크릿 볼륨에 있는 default-token 파일을 사용해 이를 수행할 수 있습니다. 파드의 모든 컨테이너는 동일한 루프백 네트워크 인터페이스를 공유하므로 애플리케이션은 localhost의 포트로 프록시에 액세스할 수 있습니다.

추가적인 앰배서더 컨테이너를 사용한 curl 파드 실행

앰배서더 컨테이너 패턴을 실제로 보려면 앞에서 만든 curl 파드와 같은 파드를 새로 생성 해야 하지만, 이번에는 파드에서 단일 컨테이너를 실행하는 대신 제가 공부하고 있는 책의 저자가 이미 만들어서 도커 허브에 푸시해놓은 다목적 kubect1-proxy 컨테이너 이미지를 기반으로 추가적인 앰배서더 컨테이너를 실행하겠습니다. 직접 빌드하려는 경우 코드 아카이브(/Chapter08/kubectl_ proxy/)에서 이미지의 Dockerfile을 찾을 수 있을 것입니다.

파드의 매니페스트는 다음 예제와 같습니다.

예제 1) 앰배서더 컨테이너가 있는 파드: curl-with-ambassador.yml

apiVersion: v1
kind: Pod
metadata:
  name: curl-with-ambassador
spec:
  containers:
    - name: main
      image: tutum/curl
      command: ["sleep", "9999999"]
    - name: ambassador                 # kubectl-proxy 이미지를 실행하는 앰배서더 컨테이너
      image: luksa/kubectl-proxy:1.6.2

파드 스펙은 이전과 거의 동일하지만 파드 이름과 추가적인 컨테이너가 다릅니다. 파드를 실행한 다음 main 컨테이너로 들어갑니다.

$ kubectl exec -it curl-with-ambassador -c main bash
root@curl-with-ambassador:/#

이제 파드에는 두 개의 컨테이너가 있으며 main 컨테이너에서 bash를 실행하려면 -c main 옵션이 필요합니다. 파드의 첫 번째 컨테이너에서 명령을 실행하려는 경우 컨테이너를 명시적으로 지정할 필요는 없습니다. 그러나 다른 컨테이너 내에서 명령을 실행하려면 -c 옵션 을 사용해 컨테이너 이름을 지정해야 합니다.

앰배서더를 통한 API 서버와의 통신

이제 앰배서더 컨테이너로 API 서버에 접속할 수 있습니다. 기본적으로 kubectl proxy는 포트 8001에 바인딩되며, 파드의 두 컨테이너 모두 루프백을 포함해 동일한 네트워크 인터페이스를 공유하므로 다음 예제와 같이 curl로 localhost:8001에 접속할 수 있다.

예제 2) 앰배서더 컨테이너로 API 서버 액세스하기

root@curl-with-ambassador:/# curl localhost:8001
"paths": [
"/api",
...
]
}

 curl로 출력된 결과는 앞에서 본 것과 동일한 응답이지만 이번에는 인증 토큰 및 서버 인증서를 처리할 필요가 없습니다.

정확히 무슨 일이 일어났는지 명확하게 파악하려면 아래 그림을 보면 이해가 쉬울 것입니다. curl은 (인증 헤더 없이) 일반 HTTP 요청을 앰배서더 컨테이너 내에서 실행 중인 프록시로 전송한 다음, 프록시는 HTTPS 요청을 API 서버로 전송하며, 토큰을 전송해 클라이언트 인증을 처리하 고 서버의 인증서를 검증해 서버의 신원을 확인합니다.

이것은 외부 서비스에 연결하는 복잡성을 숨기고 메인 컨테이너에서 실행되는 애플리케이션을 단순화하기 위해 앰배서더 컨테이너를 사용하는 좋은 예시입니다. 앰배서더 컨테이 너는 메인 애플리케이션의 언어에 관계없이 여러 애플리케이션에서 재사용할 수 있습니다. 단점은 추가 프로세스가 실행 중이고 추가 리소스를 소비한다는 것입니다.

클라이언트 라이브러리를 사용해 API 서버와 통신

애플리케이션이 API 서버와 간단한 몇 가지 작업만 수행하면 되는 경우, 특히 이전 예제에 서 했던 방식과 같이 kubectl-proxy 앰배서더 컨테이너를 이용하면 일반적인 HTTP 클라이언트 라이브러리를 사용해서 간단히 HTTP 요청을 수행할 수 있습니다. 그러나 단순한 API 요청 이상을 수행하려면 쿠버네티스 API 클라이언트 라이브러리 중 하나를 사용하는 것이 좋습니다.

클라이언트 라이브러리 사용

현재 API Machinery SIG Special Interest Group에서 지원하는 Kubernetes API 클라이언트 라이브러리는 두 가지가 있습니다.

• Golang 클라이언트: https://github.com/kubernetes/client-go
• Python: https://github.com/kubernetes-incubator/client-python/

 공식적으로 지원되는 두 개의 라이브러리 외에도 다른 여러 언어에 관한 사용자 제공 클라이언트 라이브러리 목록이 다음과 같이 있습니다.

• Java client by Fabric8: https://github.com/fabric8io/kubernetes-client madu)
• Java client by Amdatu: https://bitbucket.org/amdatulabs/amdatu-kubernetes
•  Node.js client by tenxcloud: https://github.com/tenxcloud/node-kubernetes-client
• Node.js client by GoDaddy: https://github.com/godaddy/kubernetes-client 
• PHP: https://github.com/devstub/kubernetes-api-php-client
• Another PHP client: https://github.com/maclof/kubernetes-client
• Ruby: https://github.com/Ch00k/kubr
• Another Ruby client: https://github.com/abonas/kubeclient
• Clojur: https://github.com/yanatan16/clj-kubernetes-api
• Scala: https://github.com/doriordan/skuber
• Perl: https://metacpan.org/pod/Net::Kubernetes

이 라이브러리는 일반적으로 HTTPS를 지원하고 인증을 관리하므로 앰배서더 컨테이너를 사용할 필요가 없습니다. 이 외에도 쿠버네티스 커뮤니티에는 쿠버네티스의 특정 영역에 초점을 맞춘 다수의 SIG와 워킹 그룹 (Working Group)이 있습니다. https://github.com/kubernetes/community/blob/master/sig-list.md에서 목록을 찾을 수 있습니다.

Fabric Java Client를 사용한 쿠버네티스와의 상호작용 예시

클라이언트 라이브러리를 사용해 API 서버와 통신하는 방법을 이해하기 위해 다음 예제는 Fabric쿠버네티스 클라이언트를 사용해 Java 애플리케이션에서 서비스를 나열하는 예시를 보여줍니다.

예제 3) Fabric8 Java client를 사용한 파드의 나열, 생성, 업데이트, 삭제

import java.util.Arrays;
import io.fabric8.kubernetes.api.model.Pod;
import io.fabric8.kubernetes.api.model.PodList;
import io.fabric8.kubernetes.client.DefaultKubernetesClient;
import io.fabric8.kubernetes.client.KubernetesClient;

public class Test {
    public static void main(String[] args) throws Exception {
        KubernetesClient client = new DefaultKubernetesClient();

        // List pods in the default namespace
        PodList pods = client.pods().inNamespace("default").list();
        pods.getItems().stream()
                .forEach(s -> System.out.println("Found pod: " + s.getMetadata().getName()));

        // Create a pod
        System.out.println("Creating a pod");
        Pod pod = client.pods().inNamespace("default")
        	.createNew()
        	.withNewMetadata()
        		.withName("programmatically-created-pod")
            .endMetadata()
            .withNewSpec()
                .addNewContainer()
                	.withName("main")
                	.withImage("busybox")
                	.withCommand(Arrays.asList("sleep", "99999"))
                .endContainer()
            .endSpec()
            .done();
        System.out.println("Created pod: " + pod);

        // Edit the pod (add a label to it)
        client.pods().inNamespace("default")
            .withName("programmatically-created-pod")
            .edit()
            .editMetadata()
                .addToLabels("foo", "bar")
              .endMetadata()
              .done();
        System.out.println("Added label foo=bar to pod");

        System.out.println("Waiting 1 minute before deleting pod...");
        Thread.sleep(60000);

        // Delete the pod
        client.pods().inNamespace("default")
                .withName("programmatically-created-pod")
                .delete();
        System.out.println("Deleted the pod");
    }
}

Fabric8 클라이언트는 훌륭하고 유창한 도메인 특화 언어(DSL, Domain-Specific-Language) API를 제공하기 때문에 코드를 자체적으로 설명되도록 작성해야 합니다. 또한 가독성이 좋고 이해하기 쉽습니다.

스웨거와 OpenAPI를 사용해 자신의 라이브러리 구축

선택한 프로그래밍 언어에 사용할 수 있는 클라이언트가 없는 경우 스웨거 Swagger API 프 레임워크를 사용해 클라이언트 라이브러리와 문서를 생성할 수 있다. 쿠버네티스 API 서버는/swaggerapi에서 스웨거 API 정의를 공개하고 /swagger.json에서 OpenAPI 스펙을 공개합니다.

스웨거 프레임워크에 대한 자세한 내용을 보려면 웹사이트(http://swagger.io)를 방문하여 확인할 수 있습니다.

스웨거 UI로 API 살펴보기

이전 포스팅 앞부분에서 curl을 이용해 REST 엔드포인트에 접속하는 대신, REST API를 탐색하는 더 좋은 방법을 알려준다고 언급했습니다. 이전 절에서 언급한 스웨거는 API를 설정하기 위한 도구일 뿐만 아니라 스웨거 API 정의를 공개하는 경우 REST API를 탐색하기 위한 웹 UI도제공합니다. 이 UI로 REST API를 더 나은 방식으로 탐색할 수 있습니다.

쿠버네티스는 스웨거 API가 공개돼 있는 데다가 API 서버에 스웨거 UI도 통합돼 있지만 기본적으로 활성화돼 있진 않습니다. API 서버를 --enable-swagger-ui=true 옵션으로 실 행하면 활성화할 수 있습니다. UI를 활성화한 후 브라우저에서 다음 URL로 접속해 UI를 실행할 수 있습니다.

http(s)://<api 서버>: <port>/swagger-ui

스웨거 UI를 사용해보셨으면 합니다. 쿠버네티스 API를 탐색할 수 있을 뿐만 아니라 API MA 와 상호작용할 수도 있습니다(예를 들어, JSON 리소스 매니페스트를 POST하고 리소스를 PATCH 또는 DELETE할 수 있다).

이번 포스팅은 여기서 마무리하도록 하겠습니다. 끝까지 읽어주셔서 감사합니다!

쿠버네티스 API 서버와 통신하기

이전 Downward API와 메타데이터 포스팅에서 DwonwardAPI가 어떻게 특정 파드와 컨테이너의 메타데이터를 그 안에서 실행되는 프로세스를 쉽게 전달하는지 살펴봤습니다. Downward API는 단지 파드 자체의 메타데이터와 모든 파드의 데이터 중 일부만 노출합니다. 그러나 때때로 애플리케이션에서 클러스터에 정 의된 다른 파드나 리소스에 관한 더 많은 정보가 필요할 수도 있습니다. 이 경우 Downward API는 도움이 되지 않습니다.

서비스와 파드에 관한 정보는 서비스 관련 환경변수나 DNS로 얻을 수 있습니다. 그러나 애플리케이션이 다른 리소스의 정보가 필요하거나 가능한 한 최신 정보에 접근해야 하는 경우 API 서버와 직접 통신해야 합니다.

파드 내의 애플리케이션이 쿠버네티스 API 서버와 통신하는 방법을 살펴보기 전에 먼저 로컬 컴퓨터에서 서버의 REST 엔드포인트를 살펴본 후 API 서버와 통신하는 방법을 확인해보겠습니다.

쿠버네티스 REST API 살펴보기

쿠버네티스 API와 통신 하는 애플리케이션을 개발하기 위해 API에 관해 먼저 알아봐야 합니다. API에 알아보기 위해서 API 서버에 직접 접속해 보는 방법이 있습니다. kubectl cluster-info를 실행해 URL을 얻을 수 있습니다.

$ kubectl cluster-info
Kubernetes master is running at https://192.168.99.100:8443

 서버는 HTTPS를 사용하고 인증이 필요하기 때문에 직접 통신하는 것은 간단하지 않습니다. curl을 사용해 접속하고 curl의 --insecure(또는 -k) 옵션을 사용해 서버 인증서 확인을 건너뛰도록 시도해볼 수 있지만 원하는 결과를 얻지는 못할 것 입니다.

$ curl https://192.168.99.100:8443-k
Unauthorized

하지만 다행히도 인증을 직접 처리하는 대신 kubectl proxy 명령을 실행해 프록시로 서버와 통신할 수 있습니다.

kubectl 프록시로 API 서버 액세스하기

kubectl proxy 명령은 프록시 서버를 실행해 로컬 컴퓨터에서 HTTP 연결을 수신하고 이 연결을 인증을 관리하면서 API 서버로 전달하기 때문에, 요청할 때마다 인증 토큰을 전달할 필요가 없습니다. 또한 각 요청마다 서버의 인증서를 확인해 중간자(man in the middle)가 아닌 실제 API 서버와 통신한다는 것을 담보합니다.

프록시를 실행하는 것은 생각보다 아주 쉽습니다. 다음 순서로 명령어를 입력해줍니다.

$ kubectl proxy
Starting to serve on 127.0.0.1:8001

 kubectl은 필요한 모든 것(API 서버 URL, 인증 토큰 등)을 이미 알고 있으므로 다른 인자 를 전달할 필요가 없습니다. 시작하자마자 프록시는 로컬 포트 8001에서 연결을 수신하기 시작합니다. 잘 작동하는지 살펴봅시다.

$ curl localhost:8001
{
paths": [
"/api",
"/api/v1",
...

이렇게 요청을 프록시로 보내면 이 요청을 API 서버로 보낸 다음 프록시는 서버가 반환하는 모든 것을 반환하게 됩니다. 이제 내용을 살펴보겠습니다.

kubectl proxy로 쿠버네티스 API 살펴보기

curl을 계속 이용하거나 웹 브라우저를 열어 http://localhost:8001로 접속할 수 있게 되었습니다. 기본 URL에 접속해 API 서버가 무엇을 반환하는지 좀 더 면밀히 살펴보겠습니다. 서버는 다음 예제와 같이 경로 목록을 반환합니다.

• 예제 1) API 서버의 REST 엔드포인트 목록: http://localhost:8001

$ curl http://localhost:8081
{
"paths": [
"/api",                     
"/api/v1",                            > 대부분의 리소스 타입을 여기서 확인할 수 있습니다.
"/apis",
"/apis/apps",
"/apis/apps/v1beta1",
...
"/apis/batch",                     > batch API 그룹과 이 그룹의 두 가지 버전
"/apis/batch/v1",
"/apis/batch/v2alpha1",
…

 이러한 경로는 파드, 서비스 등과 같은 리소스를 생성할 때 리소스 정의에 지정한 API 그룹과 버전에 해당합니다. 이전 쿠버네티스 포스팅들을 정독했다면 /apis/batch/v1 경로의 batch/v1가 잡 리소스의 API 그룹과 버전이란 것을 알아차릴 수 있을 것입니다.

마찬가지로 /api/v1은 생성한 일반적인 리소스(Pods, Services, ReplicationController 등)에서 참조하는 apiVersion: v1에 해당합니다. 초기의 쿠버 네티스는 API 그룹 개념을 사용하지 않았기 때문에, 초기 버전의 쿠버네티스에 도입된 가장 일반적인 리소스 유형들은 특정 그룹에 속하지 않습니다. API 그룹은 나중에 도입됐습니다. 때문에 API 그룹이 없는 초기 리소스 유형은 이제 core API 그룹에 속하는 것으로 간주됩니다.

• 쿠버네티스에 관한 다른 글들은 다음 페이지에 정리해되어있습니다.

배치 API 그룹의 REST 엔드포인트 살펴보기

잡 리소스 API를 살펴보겠습니다. 다음 예제에 표시된 대로 /apis/batch 경로 뒤에 무엇이 있는지 살펴보겠습니다. 이 예제에서는 버전이 생략되었습니다.

• 예제 2) /apis/batch 아래 있는 엔드포인트 조회: http://localhost:8001/apis/batch

$ curl http://localhost:8001/apis/batch
{
  "kind": "APIGroup",
  "apiVersion": "v1",
  "name": "batch",
  "versions": [
    {
      "groupVersion": "batch/v1",                 >  두 가지 버전을 갖는 batch API 그룹
      "version": "v1"
    },
    {
      "groupVersion": "batch/v2alpha1",       > 두 가지 버전을 갖는 batch API 그룹
      "version": "v2alpha1"
    }
  ],
  "preferredVersion": {
    "groupVersion": "batch/v1",                     > 클라이언트는 v2alpga1 대신 v1 버전을 사용해야 합니다.
    "version": "v1"
  },
  "serverAddressByClientCIDRs": null
}

 응답에는 사용 가능한 버전과 클라이언트가 사용해야 하는 선호 버전에 관한 정보와 batch API 그룹에 관한 설명이 표시됩니다. 계속해서 /apis/batch/v1 경로 뒤에 무엇이 있는지 살펴보겠습니다.

• 예제 3) batch/v1 내의 리소스 유형: http://localhost:8001/apis/batch/v1

$ curl http://localhost:8001/apis/batch/v1
{
  "kind": "APIResourceList",     >  batch/v1 API 그룹 내의 API 리소스 목록
  "apiVersion": "v1",
  "groupVersion": "batch/v1",
  "resources": [                         <  이 그룹의 모든 리소스 유형을 담는 배열
    {
      "name": "jobs",
      "namespaced": true,          >  네임스페이스 지정(namespaced) 필드가 true인 잡 리소스에 관한 설명
      "kind": "Job",
      "verbs": [
        "create",
        "delete",
        "deletecollection",            >  이 리소스와 함께 사용할 수 있는 동사들은 다음과 같습니다(잡을 생성할 수 있고,
        "get",                                    각각 또는 여러 개를 한꺼번에 삭제할 수 있으며 검색, 감시, 업데이트할 수 
        "list",                                    있습니다).
        "patch",
        "update",
        "watch"
      ]
    },
    {
      "name": "jobs/status",         <  리소스는 상태를 수정하기 위한 특수한 REST 엔드포인트가 있습니다.
      "namespaced": true,
      "kind": "Job",
      "verbs": [
        "get",                                 >   상태 정보는 검색, 패치, 업데이트할 수 있습니다.
        "patch",
        "update"
      ]
    }
  ]
}

보다시피 API 서버는 batch/v1 API 그룹에서 리소스 유형 및 REST 엔드포인트 목록을 반환합니다. 그중 하나가 잡 리소스입니다. API 서버는 리소스 이름과 관련 kind 외에도 리소 스에 네임스페이스가 지정됐는지(namespaced) 여부, 짧은 이름(있는 경우에 표시합니다. 잡은 짧은 이름이 없습니다)과 해당 리소스에 사용할 수 있는 동사(verbs) 목록도 갖고 있습니다.

반환된 목록은 API 서버에 노출된 REST 리소스를 설명합니다. "name": "jobs"는 API 에/apis/batch/v1/jobs 엔드포인트가 포함돼 있음을 알려줍니다. "verbs" 배열은 해당 엔 드포인트로 잡 리소스를 검색, 업데이트, 삭제할 수 있음을 알려줍니다. 특정 리소스의 경우 추가 API 엔드포인트도 노출됩니다(예: iohs/status 경로는 잡의 상태만 변경 가능합니다).

클러스터에 있는 모든 잡 인스턴스 나열하기

클러스터에서 잡목록을 얻으려면 다음 예제와 같이 /apis/batch/v1/jobs 경로에서 GET 요청을 실행해야 합니다.

• 예제 4) 잡 목록: http://localhost:8001/api/s/batch/v1/jobs

$ curl http://localhost:8001/apis/batch/v1/jobs
{
    "kind": "JobList",
    "apiVersion": "batch/v1",
    "metadata": {
        "selfLink": "/apis/batch/v1/jobs",
        "resourceVersion": "225162"
},
"items": [
{
    "metadata": {
        "name": "my-job",
        "namespace": "default",
…

 클러스터에 잡 리소스가 배포돼 있지 않기 때문에 항목(items) 배열이 비어 있을 것입니다. Chapter08/my-job.yaml에 있는 잡을 배포하고 REST 엔드포인트를 다시 접속하면 위 예제 4와 동일한 결과를 얻을 수 있습니다.

이름별로 특정 잡 인스턴스 검색

앞 예제의 엔드포인트는 모든 네임스페이스의 모든 잡 목록을 반환했습니다. 하나의 특정 잡을 반환하려면 URL에 이름과 네임스페이스를 지정해야 합니다. 앞 예제에 표시된 잡(name: my- job; namespace: default)을 검색하려면 다음 예제와 같이 /apis/batch/v1/namespaces/default/jobs/my-job 경로를 요청해야 합니다.

• 예제 5) 이름으로 특정 네임스페이스에 있는 리소스 검색

$ curl http://localhost:8001/apis/batch/v1/namespaces/default/jobs/my-job
{
    "kind": "Job",
    "apiVersion": "batch/v1",
    "metadata": {
        "name":"my-job",
        "namespace": "default",
…

 보다시피 다음 명령을 실행한 것과 정확히 동일하게 my-job 잡 리소스에 관한 전체 JSON 정의를 얻을 수 있습니다.

$ kubectl get job my-job -o json

특별한 도구를 사용하지 않고도 쿠버네티스 REST API 서버를 탐색할 수 있지만, REST API 전체를 탐색하고 상호작용하기 위한 더 나은 옵션은 나중에 다뤄보도록 하겠습니다. 지금은 이렇게 curl을 사용해 둘러보는 것만으로도 파드에서 실행되는 애플리케이 션이 쿠버네티스와 어떻게 통신하는지 이해하기에 충분할 것입니다.

파드 내에서 API 서버와 통신

kubectl proxy를 사용해 로컬 컴퓨터에서 API 서버와 통신하는 방법을 배웠습니다. 이제 자주 사용되는 kubectl이 없는 파드 내에서 통신하는 방법을 알아보겠습니다. 파드 내부에서 API 서버와 통신하려면 다음 세 가지를 처리해야 합니다.

•  API 서버의 위치를 찾아야 합니다.
•  API 서버인 척 가장하는 누군가와 통신하는 것이 아니라) API 서버와 통신하고 있는지 확인해야 합니다.
•  API 서버로 인증해야 한다. 그렇지 않으면 볼 수도 없고 아무것도 할 수 없습니다.

 다음 부분에서 이 작업을 수행하는 방법을 살펴보겠습니다.

API 서버와의 통신을 시도하기 위해 파드 실행

가장 먼저 필요한 것은 API 서버와 통신할 파드입니다. (sleep 명령을 실행하는 컨테이너 하나만 있는) 아무것도 하지 않는 파드를 실행한 다음, 컨테이너의 셸에서 kubectl exec를 실행한다. 그런 다음 curl을 사용해 해당 셸 내에서 API 서버에 액세스할 것입니다.

curl 바이너리가 포함된 컨테이너 이미지를 사용해야 합니다. 도커 허브에서 tutum/ curl 이미지를 검색해서 사용할 수 있습니다(curl 바이너리를 포함하는 다른 기존 이미지를 사용하거나 직접 만들 수도 있습니다). 파드 정의는 다음 예제에 표시돼 있습니다.

• 예제 6) API 서버와 통신을 시도하는 파드: curl.yaml

apiVersion: v1
kind: Pod
metadata:
  name: curl
spec:
  containers:
    - name: main
      image: tutum/curl                        >  컨테이너에서 curl을 사용해야 하기 때문에 tutum/curl 이미지를 사용합니다.
      command: ["sleep", "9999999"]  >  컨테이너가 계속 실행되도록 하려고 지연 시간이 길게
                                                              sleep 커맨드 실행합니다.

파드를 만든 후 kubectl exec를 실행해 컨테이너 내부에서 bash 셸을 실행합니다.

$ kubectl exec -it curl bash
root@curl:/#

이제 API 서버와 통신할 준비가 됐습니다.

API 서버 주소 찾기

먼저 쿠버네티스 API 서버의 IP와 포트를 찾아야 합니다. kubernetes라는 서비스가 디폴트 네임스페이스에 자동으로 노출되고 API 서버를 가리키도록 구성되기 때문에 쉽습니다. kubectl get svc를 사용해 서비스를 조회할 수 있습니다.

$ kubectl get svc

그리고 각 서비스에 관해 환경변수가 구성돼 있습니다. API 서버의 IP 주소와 포트를 컨테이너 내부의 KUBERNETES_SERVICE_HOST와 KUBERNETES_SERVICE _PORT 변수에서 모두 얻을 수 있습니다.

root@curl:/#env | grep KUBERNETES_SERVICE
KUBERNETES_SERVICE_PORT-443
KUBERNETES_SERVICE_HOST=10.0.0.1
KUBERNETES_SERVICE_PORT_HTTPS-443

또한 각 서비스마다 DNS 엔트리가 있으므로 환경변수를 조회할 필요도 없이, 단순히 curl에서 https://kubernetes를 가리키기만 하면 됩니다. 서비스가 어느 포트에서 제공되는지 모를 경우 서비스의 실제 포트 번호를 얻기 위 해 환경변수를 조회하거나 DNS SRV 레코드 조회를 수행해 확인할 수 있습니다.

위 예제에 표시된 환경변수에 따르면 API 서버가 HTTPS의 기본 포트인 443에서 수 신 대기 중이므로 HTTPS로 서버에 접속할 수 있습니다.

root@curl:/# curl https://kubernetes
curl: (60) SSL certificate problem: unable to get local issuer certificate
...
If you'd like to turn off curl's verification of the certificate, use the-k (or --insecure) option.

 이 문제를 해결하는 가장 간단한 방법은 제안된 -K 옵션을 사용하는 것(그리고 이것이 API 서버를 수동으로 사용할 때 일반적으로 사용하는 방법)이지만, 좀 더 길어도 올바른 방법을 살펴보겠습니다. 연결하려는 서버가 인증된 API 서버라는 것을 맹목적으로 신뢰하는 대신 인증서를 curl로 검사해 인증서를 확인합니다.

실제 애플리케이션에서는 서버 인증서 확인을 절대로 건너뛰면 안 됩니다. 그렇게 하면 중간자 공격(man-in-the-middle attack)으로 애플리케이션의 인증 토큰을 공격자에게 노출시킬 수 있습니다.

• '중간자 공격'은 통신을 연결하는 두 사람 사이에 중간자가 침입해 두 사람은 상대방에게 연결했다고 생각하지만 실제로는 두 사 람은 중간자에게 연결돼 있으며 중간자가 한쪽에서 전달된 정보를 도청 및 조작한 후 다른 쪽으로 전달하는 것을 말합니다.

서버의 아이덴티티 검증

이전에 시크릿을 설명하면서 각 컨테이너의 /var/run/secrets/kubernetes.io/service account/에 마운트되는 자동으로 생성된 "default-token-cfee9"라는 이름의 시크릿을 살펴 봤습니다. 해당 디렉터리의 파일을 조회해 해당 시크릿의 내용을 다시 살펴보겠습니다. 시크릿에 대한 설명은 다음 페이지에서 다룬적 있으니 참고 바랍니다.

root@curl:/#1s/var/run/secrets/kubernetes.io/serviceaccount/
ca.crt namespace token

 시크릿에는 세 개의 항목이 있습니다(그래서 시크릿 볼륨에 세 개의 파일이 있다). 지금은 쿠버네 티스 API 서버의 인증서에 서명하는 데 사용되는 인증 기관(CA)의 인증서를 보유한 ca.crt 파일에 집중하려 합니다. API 서버와 통신 중인지 확인하려면 서버의 인증서가 CA로 서명 됐는지 확인해야 합니다. curl을 --cacert 옵션과 같이 사용하면 CA 인증서를 지정할 수 있으므로 API 서버를 다시 접속합니다.

root@curl:/# curl --cacert/var/run/secrets/kubernetes.io/serviceaccount/ca/crt https://kubernetes
Unauthorized

• 이 때 "Unauthorized"보다 더 긴 오류 설명이 표시될 수도 있습니다.

서버의 인증서를 신뢰할 수 있는 CA가 서명했기 때문에 curl이 서버의 ID를 확인했습니다. Unauthorized에서 알 수 있듯이 여전히 인증 처리가 필요합니다. 잠시 뒤 시도해보겠지만 먼저 CURL_CA_BUNDLE 환경변수를 설정해 편하게 할 수 있는 방법을 살펴보겠습니다. 이렇게 하면 curl을 실행할 때마다 --cacert를 지정할 필요가 없게 됩니다..

root@curl:/# export CURL_CA_BUNDLE=/var/run/secrets/kubernetes.io/serviceaccount/ca.

--cacert를 사용하지 않고 API 서버에 접속할 수 있다.

root@curl:/# curl https://kubernetes
Unauthorized

이제 독자의 클라이언트(curl)는 API 서버를 신뢰하지만 API 서버 자체는 여러분이 누구인지 모르기 때문에 액세스 권한이 없다고 표시할 것입니다.

API 서버로 인증

서버에서 인증을 통과해야 클러스터에 배포된 API 오브젝트를 읽고, 업데이트와 삭제를 할 수 있습니다. 인증하려면 인증 토큰이 필요합니다. 다행히 토큰은 전에 언급한 default- token 시크릿으로 제공되며 시크릿 볼륨의 token 파일에 저장됩니다. 시크릿 이름에서 알 수 있듯이, 시크릿의 주된 목적이 바로 이것입니다.

토큰을 사용해 API 서버에 액세스합니다. 먼저 토큰을 환경변수에 로드해야 합니다.

root@curl:/#TOKEN=$(cat/var/run/secrets/kubernetes.io/serviceaccount/token)

토큰은 이제 TOKEN 환경변수에 저장됩니다. 다음 예제와 같이 API 서버로 요청을 보낼 때 사용할 수 있습니다.

• 예제 7) API 서버로부터 적절한 응답 받기

root@curl:/# curl -H "Authorization: Bearer $TOKEN" https://kubernetes on
{
  "paths": [
    "/api",
    "/api/v1",
    "/apis",
    "/apis/apps",
    "/apis/apps/v1beta1",
    "/apis/authorization.k8s.io",
    // ...
    "/ui/",
    "/version"
  ]
}

보다시피 요청의 Authorization HTTP 헤더 내부에 토큰을 전달했습니다. API 서버는 토큰을 인증된 것으로 인식하고 적절한 응답을 반환했습니다. 이제 앞의 절들에서 수행한 방식으 로 클러스터의 모든 리소스를 탐색할 수 있습니다.

예를 들어 동일한 네임스페이스 내에 있는 모든 파드를 조회할 수 있습니다. 그러나 먼저 curl 파드가 어떤 네임스페이스에서 실행 중인지 알아야 합니다.

역할 기반 액세스 제어(RBAC) 비활성화

RBAC가 활성화된 쿠버네티스 클러스터를 사용하는 경우 서비스 어카운트가 API 서버에 액세스할 권한이 없을 수 있습니다. 서비스 어카운트와 RBAC에 대해서는 나중에 따로 다루겠지만 이 포스팅에서는 API 서버를 쿼리할 수 있는 가장 간단한 방법인 다음 명령을 실행해 RBAC를 우회하는 것에 대해 설명하겠습니다.

$ kubectl create clusterrolebinding permissive-binding\
--clusterrole=cluster-admin \
--group=system:serviceaccounts

 이렇게 하면 모든 서비스 어카운트(모든 파드라고도 말할 수 있다)에 클러스터 관리자 권한이 부여돼 원하는 대로 할 수 있습니다. 이렇게 하는 것은 분명히 위험하고 프로덕션 클러스터에서는 절대 해서는 안 됩니다. 단, 테스트 목적이라면 상관없습니다.

파드가 실행 중인 네임스페이스 얻기

바로 이전 포스팅인 Downward API 부분에서 해당 API로 네임스페이스를 파드에 전달하는 방법을 살펴봤습니다. 여기서 주의 깊게 봤다면 시크릿 볼륨에 네임스페이스라는 파일이 포함돼 있음을 보셨을 수도 있을 것 입니다. 이 파일에는 파드가 실행 중인 네임스페이스가 포함돼 있으므로, 환경변 수로 파드에 네임스페이스를 명시적으로 전달하는 대신 파일을 읽을 수 있습니다. 파일 내용을 NS 환경변수에 로드한 뒤 다음 예제와 같이 모든 파드를 나열해보겠습니다.

• 예제 8) 파드가 속한 네임스페스에 있는 파드 나열하기

root@curl:/#NS=$(cat/var/run/secrets/kubernetes.io/serviceaccount/namespace)
root@curl:/# curl -H "Authorization: Bearer $TOKEN" https://kubernetes/api/v1/namespaces/$NS/pods
{
"kind": "PodList",
"apiVersion": "v1",
...

 마운트된 시크릿 볼륨 디렉터리에 있는 3개의 파일을 사용해 파드와 동일한 네임스페 이스에서 실행 중인 모든 파드를 나열했습니다. 같은 방식으로 다른 API 오브젝트를 검색하고 간단한 GET 요청 대신 PUT 또는 PATCH를 전송해 업데이트할 수도 있습니다.

파드가 쿠버네티스와 통신하는 방법 정리

파드 내에서 실행 중인 애플리케이션이 쿠버네티스 API에 적절히 액세스할 수 있는 방법을 간단히 정리하면 다음과 같습니다.

• 애플리케이션은 API 서버의 인증서가 인증 기관으로부터 서명됐는지를 검증해야 하며, 인증 기관의 인증서는 ca.cart 파일에 있습니다.
• 애플리케이션은 token 파일의 내용을 Authorization HTTP 헤더에 Bearer 토큰으로 넣어 전송해서 자신을 인증해야 합니다.
• namespace 파일은 파드의 네임스페이스 안에 있는 API 오브젝트의 CRUD 작업을 수행할 때 네임스페이스를 API 서버로 전달하는 데 사용해야 합니다.
  • CRUD는 Create, Pead, Update, Delete를 나타냅니다. 해당 HTTP 메서드는 각각 POST. GET, PATCH/PUT, DELETE입니다.

downwardAPI 볼륨에 파일로 메타데이터 전달

환경변수 대신 파일로 메타데이터를 노출하려는 경우 downwardAPI 볼륨을 정의해 컨테이너에 마운트 할 수 있습니다. 환경변수로 파드의 레이블이나 어노테이션을 노출할 수 없기 때문에 downwardAPI 볼륨을 사용해야 합니다. 이유는 나중에 추가로 다뤄보겠습니다.

환경변수와 마찬가지로 메타데이터를 프로세스에 노출시키려면 각 메타데이터 필드를 명시적으로 지정해야 합니다. 다음 예제에서 환경변수 대신 볼륨을 사용하도록 이전 예제를 수정하는 방법을 살펴보겠습니다.

예제. 1) downwardAPI 볼륨을 갖는 파드: downward-api-volume.yaml

apiVersion: v1
kind: Pod
metadata:
  name: downward
  labels:          # 
    foo: bar       #
  annotations:     #
    key1: value1   # 이 레이블과 어노테이션은 downwardAPI 볼륨으로 노출됩니다.
    key2: |        #
      multi        #
      line         #
      value        #
spec:
  containers:
    - name: main
      image: busybox
      command: ["sleep", "9999999"]
      resources:
        requests:
          cpu: 15m
          memory: 100Ki
        limits:
          cpu: 100m
          memory: 4M1
      volumeMounts:                  #
        - name: downward             # dwonward 볼륨은 /etc/downward 아래에 마운트합니다.
          mountPath: /etc/downward   #
  volumes:
    - name: downward  # downwardAPI 볼륨을 downward라는 이름으로 정의합니다.
      downwardAPI:    #
        items:
          - path: "podName"               # 파드의 이름(매니페스트에 있는 metadata.name
            fieldRef:                     # 필드에서 확인할 수 있습니다.)은 podName 파일에
              fieldPath: metadata.name    # 기록됩니다.
          - path: "podNamespace"
            fieldRef:
              fieldPath: metadata.namespace
          - path: "labels"                    #
            fieldRef:                         # 파드의 레이블은 /etc.downward/labels 파일에 기록됩니다.
              fieldPath: metadata.labels      #
          - path: "annotations"                   #
            fieldRef:                             # 파드의 어노테이션을
              fieldPath: metadata.annotations     # /ect/downward/annotations 파일에 기록합니다.
          - path: "containerCpuRequestMilliCores"
            resourceFieldRef:
              containerName: main
              resource: requests.cpu
              divisor: 1m
          - path: "containerMemoryLimitBytes"
            resourceFieldRef:
              containerName: main
              resource: limits.memory
              divisor: 1

환경변수로 메타데이터를 전달하는 대신 downward라는 볼륨을 정의하고 컨테이너의 /etc/downward 아래에 마운트 합니다. 이 볼륨에 포함된 파일들은 볼륨 스펙의 downward API.items 속성 아래에 설정됩니다.

각 항목은 메타데이터를 기록할 경로(파일 이름)와 파일에 저장할 값의 파드 수준의 필 드나 컨테이너 리소스 필드에 대한 참조를 지정합니다.

이전에 만든 파드를 삭제하고 이전 예제의 매니페스트를 사용해 새로운 파드를 만듭니다. 그런 다음 마운트된 downwardAPI 볼륨 디렉터리의 내용을 살펴봅시다. /etc/downward/ 아래에 볼륨을 마운트 했으므로 다음 예제에 표시된 것처럼 파일을 나열할 수 있습니다. 또한 컨피그맵과 시크릿 볼륨과 마찬가지로 파드 스펙에서 downwardAPI 볼륨의 defaultMode 속성으로 파일 권한을 변경할 수 있습니다.

예제. 2) downwardAPI 볼륨 내의 파일들

$ kubectl exec downward -- 1s -1L /etc/downward
-rw-r--r-- 1 root root 134 May 25 10:23 annotations
-rw-r--r-- 1 root root 2 May 25 10:23 containerCpuRequestMilliCores
-rw-r--r-- 1 root root 7 May 25 10:23 containerMemoryLimitBytes
-rw-r--r-- 1 root root 9 May 25 10:23 labels
-rw-r--r-- 1 root root 8 May 25 10:23 podName
-rw-r--r-- 1 root root 7 May 25 10:23 podNamespace

각 파일은 볼륨 정의의 항목(item)에 해당합니다. 그러나 환경변수로는 레이블과 어노 테이션을 노출할 수 없었기 때문에 다음 예제로 노출하려는 내용이 두 파일에 저장돼 있는지 확인할 수 있습니다.

예제. 3) downwardAPI 볼륨의 레이블과 어노테이션 표시

$ kubectl exec downward cat /etc/downward/labels
foo="bar"
 
$ kubectl exec downward cat /etc/downward/annotations
key1="value1"
key2="multi\nline\nvalue\n"
kubernetes.io/config.seen="2016-11-28T14:27:45.6649242822"
kubernetes.io/config.source="api"

위에서 볼 수 있듯이 각 레이블/어노테이션은 별도의 줄에 키값 형식으로 저장됩니다. 값이 여러 줄인 경우 줄 바꾸기 문자가 \n으로 표시돼 한 줄로 기록됩니다.

레이블과 어노테이션 업데이트

파드가 실행되는 동안 레이블과 어노테이션을 수정할 수 있습니다. 레이블이나 어노테이션이 변경될 때 쿠버네티스가 이 값을 가지고 있는 파일을 업데이트해서 파드가 항상 최신 데이터를 볼 수 있도록 합니다. 이것은 레이블과 어노테이션 이 왜 환경변수로 노출될 수 없는지도 설명할 수도 있습니다. 환경변숫값은 나중에 업데이트할 수 없기 때문에 파드의 레이블 또는 어노테이션이 환경변수로 노출된 경우 변경이 발생한 다음에 새로운 값을 노출할 수 있는 방법이 없습니다.

볼륨 스펙에서 컨테이너 수준의 메타데이터 참조

이 내용을 마무리하기 전에 한 가지 짚어봐야 할 것은 컨테이너의 리소스 제한 또는 요청(resourceFieldRef를 사용해 수행)과 같은 컨테이너 수준의 메타데이터를 노출하는 경우 다음 예제에 표시된 것처럼 리소스 필드를 참조하는 컨테이너의 이름을 지정해야 합니다.

예제. 4) downwardAPI 볼륨에서 컨테이너 수준의 메타데이터 참조

spec:
  volumes:
    - name: downward
      downwardAPI:
        items:
          - path: "containerCpuRequestMilliCores"
            resourceFieldRef:
              containerName: main #컨테이너 이름이 반드시 지정돼야 합니다.
              resource: requests.cpu
              divisor: 1m

볼륨이 컨테이너가 아니라 파드 수준에서 정의됐다고 생각하면 그 이유가 분명해집니다. 볼륨 스펙 내에서 컨테이너의 리소스 필드를 참조할 때는 참조하는 컨테이너의 이름을 명시적으로 지정해야 합니다. 컨테이너가 하나인 파드에서도 마찬가지입니다.

볼륨을 사용해 컨테이너의 리소스 요청이나 제한을 노출하는 것은 환경변수를 사용하는 것보다 약간 더 복잡하지만 필요할 경우 한 컨테이너의 리소스 필드를 다른 컨테이너에 전달할 수 있는 장점이 있습니다(단, 두 컨테이너는 모두 같은 파드에 있어야 한다). 환경변수로는 컨테이너 자신의 리소스 제한과 요청만 전달할 수 있다.

Downward API 사용 시기 이해

앞에서 본 바와 같이 Downward API 사용은 그렇게 복잡하지는 않습니다. 이것은 애플리케이션을 쿠버네티스에 독립적 (Kubernetes-agnostic)으로 유지할 수 있게 합니다. 환경변수의 특정 데이터를 활용하는 기존 애플리케이션을 처리할 때 특히 유용합니다. Downward API를 사용하면 애플리케이션을 다시 짜거나 데이터를 가져와서 환경변수에 노출하는 Shell 스크립트를 사용하지 않고도 데이터를 애플리케이션에 노출할 수 있습니다.

그러나 Downward API로 사용 가능한 메타데이터는 상당히 제한적입니다. 더 많은 정 보가 필요한 경우 쿠버네티스 API 서버에서 직접 가져와야 한다. 다음 포스팅에서 그 방법에 대해 다뤄보도록 하겠습니다.

Downward API로 메타데이터 전달

오래간만에 다시 쿠버네티스로 돌아왔습니다. 이번 포스팅에서는 메타데이터를 전달하는 방법에 대해 다뤄보도록 하겠습니다. 이전에 저희는 환경변수 또는 컨피그맵과 시크릿 볼륨으로 설정 데이터를 애플리케이션에 전 달하는 방법을 살펴봤습니다. 이는 사용자가 데이터를 직접 설정하거나 파드가 노드에 스케줄링돼 실행되기 이전에 이미 알고 있는 데이터에는 적합합니다.

그러나 파드의 IP, 호스트 노드 이름 또는 파드 자체의 이름(파드의 이름이 생성되는 경우. 예를 들어 레플리카셋이나 그와 유사 한 컨트롤러에 의해 파드가 생성되는 경우)과 같이 실행 시점까지 알려지지 않은 데이터의 경우나 파드의 레이블이나 어노테이션과 같이 어딘가에 이미 설정된 데이터일 경우에 동일한 정보를 여러 곳에 반복해서 설정하고 싶지는 않을 것입니다.

이 두 가지 문제는 쿠버네티스의 Downward API로 해결할 수 있습니다. 환경변수 또는 (downwardAPI 볼륨 내에 있는) 파일로 파드와 해당 환경의 메타데이터를 전달할 수 있습니다. 이 때 이름 때문에 혼동 하지 말아야 합니다. Downward API는 애플리케이션이 호출해서 데이터를 가져오는 REST 엔드포인트와 다릅니다. 다음 그림과 같이 환경변수 또는 파일에 파드의 스펙 또는 상태값이 채워지 도록 하는 방식입니다.

사용 가능한 메타데이터 이해

Downward API를 사용하면 파드 자체의 메타데이터를 해당 파드 내에서 실행 중인 프로세스에 노출할 수 있다. 현재 다음 정보를 컨테이너에 전달할 수 있습니다.

• 파드의 이름
• 파드의 IP 주소
• 파드가 속한 네임스페이스
• 파드가 실행 중인 노드의 이름
• 파드가 실행 중인 서비스 어카운트 이름
• 각 컨테이너의 CPU와 메모리 요청
• 각 컨테이너의 CPU와 메모리 제한
• 파드의 레이블
• 파드의 어노테이션

서비스 어카운트(Service Account), CPU/메모리 요청 (request)과 제한(limit)을 제외하고는 목록에 있는 대부분의 항목은 별도의 설명 없이도 보는데 문제는 크게 없을 것입니다. 이에 대한 내용은 이후에 쿠버네티스를 진행하면서 천천히 다룰 여정이고 간단하게 설명하자면 다음과 같습니다.

• 서비스 어카운트: 파드가 API 서버와 통신할 때 인증하는 계정
• CPU/메모리 요청 및 제한: 컨테이너에 보장되는 CPU와 메모리의 양과 컨테이너가 얻을 수 있는 최대 양

목록에 있는 대부분의 항목은 환경변수 또는 downwardAPI 볼륨으로 컨테이너에 전 달될 수 있지만 레이블과 어노테이션은 볼륨으로만 노출될 수 있습니다. 일부 데이터는 다른 방법(이를테면 운영체제에서 직접)으로도 얻을 수 있지만, Downward API는 더 간단한 대안 을 제공합니다.

다음 항목에서 컨테이너 내부에 있는 프로세스에 메타데이터를 전달하는 예를 살펴보겠습니다.

환경변수로 메타데이터 노출하기

먼저 환경변수로 파드와 컨테이너의 메타데이터를 컨테이너에 전달하는 방법을 살펴보겠습니다. 다음 예제의 매니페스트를 이용해 컨테이너가 하나인 간단한 파드를 만들 수 있습니다.

예시) Downward API: downward-api-env.yaml

apiVersion: v1
kind: Pod
metadata:
  name: down
spec:
  containers:
  - name: main
    image: busybox
    command: ["sleep", "9999999"]
    resources:
      requests:
        cpu: 15m
        memory: 100Ki
      limits:
        cpu: 100m
        memory: 4Mi
    env:
    - name: POD_NAME
      valueFrom:              >  특정 값을 설정하는 대신 파드 매니페스트의 metadata.name을 참조한다.
        fieldRef:
          fieldPath: metadata.name
    - name: POD_NAMESPACE
      valueFrom:
        fieldRef:
          fieldPath: metadata.namespace
    - name: POD_IP
      valueFrom:
        fieldRef:
          fieldPath: status.podIP
    - name: NODE_NAME
      valueFrom:
        fieldRef:
          fieldPath: spec.nodeName
    - name: SERVICE_ACCOUNT
      valueFrom:
        fieldRef:
          fieldPath: spec.serviceAccountName
    - name: CONTAINER_CPU_REQUEST_MILLICORES
      valueFrom:    >  컨테이너의 CPU/메모리 요청과 제한은 fieldRef CHA resourceFieldRef  사용해 참조한다.
        resourceFieldRef:
          resource: requests.cpu
          divisor: 1m   >  리소스 필드의 경우 필요한 단위의 값을 얻으려면 제수(divisor)를 정의한다.
    - name: CONTAINER_MEMORY_LIMIT_KIBIBYTES
      valueFrom:
        resourceFieldRef:
          resource: limits.memory
          divisor: 1Ki

프로세스가 실행되면 파드 스펙에 정의한 모든 환경변수를 조회할 수 있습니다. 파드의 이름, IP와 네임스페이스는 각각 POD_NAME, POD_IP와 POD_NAMESPACE 환경변수로 노출됩니다. 컨테이너가 실행 중인 노드의 이름은 NODE_NAME 변수로 노출됩니다. 서비스 어카운트 이름은 SERVICE_ACCOUNT 환경변수 로 사용 가능합니다. 그리고 이 컨테이너에 요청된 CPU 양과 컨테이너가 사용할 수 있는 최대 메모리 양을 갖는 두 개의 환경변수를 작성합니다.

자원 제한(limits) 또는 요청(requests)을 노출시키는 환경변수의 경우 제수(divisor)를 지정할 수 있습니다. 제한 또는 요청의 실제 값은 제수로 나누고 결과값을 환경변수로 노출합니다. 이 예제에 서는 CPU 요청에 대한 제수를 1m(1밀리코어 또는 1000분의 1 CPU 코어)로 설정했습니다. CPU 요청을 15m로 설정했기 때문에 환경변수 CONTAINER_CPU_REQUEST_MILLICORES는 15로 설정 됩니다. 마찬가지로 메모리 제한을 4Mi(4 메비바이트, Mebibyte)로 설정하고 제수를 1Ki(1 키비바이트,Kibibyte)로 설정했으므로 CONTAINER_MEMORY_LIMIT_KIBIBYTES 환경변수는 4096으로 설정됩니다.

• 제수는 어떤 수를 나누는 수로, 여기서는 CPU나 메모리를 요청하거나 제한할 때 사용하는 단위 정도로 이해하면 됩니다

CPU 제한과 요청의 제수는 1(전체 코어 하나를 의미함) 또는 1m(1밀리코어)로 설정합니다. 메모리 제한/요청의 제수는 1바이트), 1k(킬로 바이트) 또는 1Ki(키비 바이트), 1M(메가 바이트) 또는 1Mi(메비 바이트) 등이 될 수 있습니다.

파드를 만든 후에는 kubectl exec를 사용해 다음 예제와 같이 컨테이너에 있는 모든 환경변수를 볼 수 있습니다.

예제2) downward 파드 내의 환경변수

$ kubectl exec downward env
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/biniyoole
HOSTNAME=downward
CONTAINER_MEMORY_LIMIT_KIBIBYTES-4096
POD_NAME=downward
POD_NAMESPACE=default
POD_IP=10.0.0.10
NODE_NAME=gke-kubia-default-pool-32a2cac8-sg17
SERVICE_ACCOUNT=default
CONTAINER_CPU_REQUEST_MILLICORES=15
KUBERNETES_SERVICE_HOST=10.3.240.1
KUBERNETES_SERVICE_PORT=443
...

컨테이너 내부에서 실행되는 모든 프로세스는 해당 변수를 읽을 수 있고, 필요한 대로 사용할 수 있습니다.

한국형 발사체 '누리호'가 우주로 보낸 '차세대 소형 위성 2호'가 임무를 시작하기 전에 완전한 양방향 교신에 성공했습니다. 위성은 근지구 궤도에서 근지구 입자 선량지도 작성과 태양활동에 따른 우주방사선 변화 등을 연구할 예정입니다. 초기 교신과 추가 교신을 통해 위성의 상태가 정상임을 확인했고, 7일 동안 상태 점검 후 본격적인 임무를 수행할 예정입니다. 이번 발사에는 차세대 소형 위성 2호 외에도 7개의 부탑재 위성이 함께 발사되었으며, 4개의 위성의 위치를 확인했습니다.

출처: https://n.news.naver.com/mnews/article/009/0005136069

목차로 이동

정부가 바이오 산업을 국가첨단전략기술로 신규 지정하였습니다. 이는 반도체, 디스플레이, 2차전지(배터리)에 이어 네 번째 국가첨단전략기술 산업으로 지정되었습니다. 글로벌 기술패권 경쟁에 대응하기 위해 정부는 10년 동안 4조6000억원을 투자하여 4대 산업의 연구개발(R&D)을 지원할 계획입니다. 

26일에 개최된 제2차 국가첨단전략산업위원회에서 이 결정이 내려졌으며, 바이오를 기존의 국가첨단전략기술에 추가하고 17개의 기술을 4개의 첨단산업에 대한 본격적인 지원 대상으로 지정하였습니다. 미래차, 로봇, 원전, 방산 등에 대해서도 관계부처와의 협의를 통해 첨단전략산업 범위를 확대할 계획입니다. 

위원회는 또한 제1차 국가첨단전략산업 육성 기본계획(2023~2027년)을 확정하였습니다. 이 계획에는 550조원 이상의 첨단산업 프로젝트에 인센티브를 제공하고 한국판 '섹터 딜(분야별 선도사업)'을 신설하는 내용이 포함되어 있습니다. 선도사업은 특화단지와 동일한 지원을 받으며, 7월 중에는 국가첨단전략산업 특화단지도 지정될 예정입니다. 현재 21개 지방자치단체가 반도체, 디스플레이, 2차전지 분야에 대해 신청서를 제출한 상태입니다. 

또한 '규제혁신 3종 세트' 도입도 추진될 예정입니다. 이에는 인허가 타임아웃제도(60일 이내에 인허가가 처리되지 않으면 처리된 것으로 간주), 상생벨트(인접 지자체 간 기업투자 수익 공유를 위한 신속한 인허가), 규제지수 및 첨단산업영향평가제 등이 포함됩니다. 반도체 특성화 대학원으로는 성균관대, 한국과학기술원(KAIST), 울산과학기술원(UNIST) 등이 선정되었으며, 이들 대학에는 5년간 총 450억원이 지원될 예정입니다. 이어서 정부는 규제혁신 3종 세트를 추진할 계획이며, 인허가 타임아웃제도, 상생벨트, 규제지수 및 첨단산업영향평가제 등이 포함됩니다. 이러한 노력을 통해 정부는 국가첨단전략기술 산업의 발전과 글로벌 기술패권 경쟁에 대응하고자 합니다. 

출처: https://n.news.naver.com/mnews/article/009/0005136124

목차로 이동

LG에너지솔루션과 현대자동차그룹은 미국에 합작공장을 설립하여 북미 전기차 시장을 공략하기로 결정했습니다. 이를 통해 LG에너지솔루션은 2026년까지 북미에서 가장 큰 생산 능력을 갖춘 배터리 업체로 성장할 계획입니다. 이번 협력으로 LG에너지솔루션의 북미 생산공장은 총 8개로 늘어나게 되며, 현대차그룹은 안정적인 배터리 공급 기반을 갖추어 북미 시장에서 경쟁력을 갖추게 되었습니다. 미국은 현지에서 생산된 배터리에 대해 보조금을 지급하는데, LG에너지솔루션은 2026년까지 약 13조원의 보조금을 받을 수 있다고 예상됩니다. 현대차그룹은 SK온과의 합작공장에 이어 LG에너지솔루션과의 합작공장을 통해 배터리 공급을 확보하여 북미 전기차 시장을 공략할 준비를 마쳤습니다. 이번 협력을 통해 현대차그룹은 IRA 보조금을 받게 되어 북미 시장에서의 판매량을 크게 늘릴 수 있을 것으로 예상됩니다.

출처: https://n.news.naver.com/mnews/article/009/0005136087

목차로 이동

현대자동차그룹과 LG에너지솔루션은 미국 조지아주 서배너에 연 30GWh 규모의 전기차 배터리 합작공장을 짓는다. 합작공장은 2025년 말에 가동될 예정이며, 연간 고성능 전기차 약 30만 대를 생산할 수 있다. 현대차그룹은 SK온과도 미국에 연 35GWh 규모의 합작공장을 짓고 있다. 이번 LG에너지솔루션과의 협력으로 현대차그룹은 보다 안정적인 현지 배터리 공급망을 구축하게 됐다. LG에너지솔루션은 북미 지역 최대 생산 능력을 확보하고 있는 만큼, 이번 합작공장 설립으로 일본 파나소닉, SK온 등과의 격차를 더 벌릴 것으로 전망된다.

출처: https://n.news.naver.com/mnews/article/015/0004849546

목차로 이동

삼성SDS는 공공 클라우드 도입을 준비 중인 지자체 및 정부부처를 위해 세미나를 개최했습니다. 세미나에서는 공공 클라우드 전환을 위한 전략, 도입 과정에서의 주의사항, 실제 성공 사례 등이 제공되었습니다. 클라우드의 효과적인 도입과 가치 창출에 대한 논의가 이루어졌으며, 클라우드 전환 과정에서 고려해야 할 사항에 대한 정보도 제공되었습니다. 또한 클라우드 도입으로 인한 생산성 향상과 업무 효율 개선, 보안 관련 주의사항 등에 대해서도 다루었습니다. 마지막으로, 삼성클라우드플랫폼(SCP)를 소개하고, 실제 클라우드 도입 사례도 소개되었습니다.

출처: https://n.news.naver.com/article/092/0002293568?sid=105 

목차로 이동

한전KDN과 레드햇이 클라우드 기반 기술 강화를 위한 업무협약을 진행했습니다. 협약식에서 양사는 업무에 대한 소개와 기술력 공유에 대한 약속을 확인했으며, 한전KDN은 클라우드 플랫폼 기반의 공공서비스를 제공하기 위해 레드햇과의 협력을 추진하고 있습니다. 두 기업은 에너지 및 전력 분야의 클라우드 컴퓨팅 서비스 수준 향상을 목표로 하고 있으며, 레드햇은 클라우드 네이티브 전환을 위한 오픈소스 기술과 컨설팅 서비스를 제공할 것이라고 밝혔습니다. 협약을 통해 한전KDN의 클라우드 솔루션과 다양한 서비스의 창출이 기대됩니다.

출처: http://www.todayenergy.kr/news/articleView.html?idxno=260902 

목차로 이동

마이크로소프트는 7월에 데브 박스를 정식 출시할 예정이라고 밝혔습니다. 데브 박스는 애저 클라우드에서 제공되는 소프트웨어 개발 워크스테이션 서비스로, 현재는 공개 프리뷰 단계에 있습니다. 이 서비스를 통해 개발자들은 사전 구성되고 중앙에서 관리되는 개발 워크스테이션을 프로젝트별로 이용할 수 있으며, 윈도우, 맥OS, iOS, 안드로이드 기기에서 접근할 수 있습니다. 데브 박스는 윈도우나 리눅스용 윈도우 서브시스템에서 실행되는 모든 개발 도구의 사용을 지원하며, 개발자들은 고성능 데브 박스 SKU를 구성하여 고성능, 컴퓨팅 집약적, 메모리 집약적인 워크로드를 개발하고 실행할 수 있습니다. 마이크로소프트는 이미 내부 개발자들에게 데브 박스를 배포하였으며, 애저 마켓 플레이스에서는 개발자용 윈도우 클라이언트 및 비주얼 스튜디오 등 여러 개발자 중심 스타터 이미지가 제공됩니다. 또한 개발자들은 비공개 미리 보기에 등록하여 YAML 구성 파일을 사용하여 기본 이미지를 사용자 지정할 수 있는 데브 박스 사용자 지정 기능을 이용할 수 있습니다.

출처: https://www.ciokorea.com/news/292171

목차로 이동

마이크로소프트(MS)는 영국 독점 규제 기관의 결정에 대해 법원에 항고하였습니다. 이 결정은 MS가 대형 게임업체 액티비전 블리자드를 인수할 경우 클라우드 게임 시장에서 경쟁이 약화되고 혁신이 위축되어 게임 이용자의 선택권이 줄어들 것으로 우려되어 인수를 불허한 것입니다. MS는 이러한 결정이 잘못되었다며 클라우드 게임 서비스의 시장 점유율 데이터를 계산하고 평가하는 데 오류가 있다고 주장하였습니다. 유럽연합(EU) 집행위원회는 이와 달리 MS의 제안을 받아들여 인수를 승인한 바 있습니다. MS의 블리자드 인수는 역대 최대 규모의 인수합병 거래 중 하나이지만, 아직 각국의 최종 승인을 받지 못한 상태입니다.

출처: https://n.news.naver.com/article/001/0013967338?sid=104 

목차로 이동

국가정보원이 최근 3년간 북한의 해킹 메일 공격에 관한 통계를 공개하면서, 이용자들은 주의가 필요하다고 경고하였습니다. 북한은 메일을 이용한 해킹공격이 전체의 74%를 차지해 압도적으로 높았으며, 이메일을 통한 공격은 대한민국 국민 전체를 대상으로 한 것으로 분석되었습니다. 북한은 메일 제목이 계정 보안 문제와 관련된 내용으로 위장되어 있으며, 메일 수신자를 속여 열람을 유도하는 사회 심리 공학적인 피싱 기법을 사용하였습니다. 메일 발신자명과 메일 제목을 교묘하게 바꾸어 일반적인 메일과 헷갈리도록 하였습니다. 국정원은 이와 관련하여 국내 주요 포털사이트 운영사와 정보 공유를 강화할 예정이라고 밝혔습니다. 이용자들은 메일 발신자명, 메일 주소, 링크 주소 등을 확인하고 이메일 보안을 강화하는 것이 중요합니다.

출처: https://n.news.naver.com/article/022/0003816808?sid=100 

목차로 이동

NHN(181710)은 고용노동부가 주관하는 K-디지털 트레이닝의 '디지털 선도기업 아카데미' 사업자로 선정되었다고 밝혔습니다. NHN아카데미는 'IoT/AI 기반 자바 백엔드 개발자 과정'을 운영하며, 국민내일배움카드를 통해 무료로 수강할 수 있습니다. 이번 과정은 NHN 아카데미 경남 캠퍼스에서 9월부터 내년 6월까지 진행되며, 비전공생 및 초급자도 지원 가능합니다. 교육은 NHN 아카데미와 한국표준협회의 현직자들에 의해 직접 진행되며, 우수 수료생에게는 NHN 그룹사 채용 기회가 주어집니다. 

출처: https://n.news.naver.com/article/018/0005494950?sid=105 

목차로 이동

마이크로소프트는 자사의 데이터 관련 제품과 서비스를 통합한 플랫폼인 '마이크로소프트 패브릭'을 발표했습니다. 이 플랫폼은 데이터 수집부터 분석, 시각화까지의 일련의 데이터 프로세스를 단일 소프트웨어 환경에서 수행할 수 있습니다. 이 플랫폼의 차별점은 '코파일럿'이라는 생성 AI 기반 기술을 제공한다는 점입니다. 마이크로소프트 패브릭은 데이터 수집, 처리, 저장, 통합, 분석, 시각화, 보안, 거버넌스 등 다양한 하위 시스템을 포함한 통합 데이터 분석 플랫폼으로서 서비스형 소프트웨어(SaaS) 형태로 제공됩니다. 이 플랫폼은 데이터 엔지니어, 데이터웨어하우스 담당자, 데이터 과학자, 분석가, 비즈니스 사용자 등이 함께 활용할 수 있는 자동화된 분석 프로세스를 제공합니다.

마이크로소프트 패브릭은 데이터저장소, 데이터팩토리, 시냅스 데이터 엔지니어링, 시냅스 데이터 애널리틱스, 시냅스 데이터웨어하우징, 시냅스 리얼타임 애널리틱스, 파워BI, 데이터 액티베이터 등 8가지 요소로 구성되어 있습니다. 이를 통해 사용자들은 데이터 수집부터 분석까지의 과정을 효율적으로 처리할 수 있습니다. 마이크로소프트 패브릭은 데이터 프로세스 자동화, 보안 및 거버넌스 등의 기능을 제공하며, 데이터 형식으로는 오픈소스 포맷인 '파케이(Parquet)'와 '델타(Delta)'를 사용합니다. 이를 통해 모든 사용자의 워크로드를 처리하며 데이터 보안도 통합적으로 관리할 수 있습니다. 

마이크로소프트 패브릭은 데이터 분석과 관련된 다양한 업무를 수행할 수 있는 생성 AI를 제공합니다. 이를 통해 데이터 흐름과 데이터 파이프라인을 생성하고, 코드와 전체 기능을 만들며, 머신러닝 모델을 구축하고 결과를 시각화할 수 있습니다. 아래는 생성 AI가 수행하는 데이터 분석 업무에 대한 몇 가지 예시입니다:

1. 데이터 탐색과 시각화: 생성 AI는 대화 형식으로 데이터를 탐색하고 시각화하는 기능을 제공합니다. 사용자는 자연어로 데이터를 설명하고, AI는 데이터를 자동으로 분석하고 시각화된 결과를 제공합니다. 이를 통해 데이터에 대한 통찰력을 얻고 의사결정을 지원할 수 있습니다.

2. 머신러닝 모델 구축: 생성 AI는 머신러닝 모델을 구축하는 데 도움을 줍니다. 사용자는 원하는 작업에 대한 명세를 제공하고, AI는 모델을 자동으로 생성하고 훈련시킵니다. 이를 통해 예측 모델, 분류 모델 등을 만들 수 있습니다.

3. 데이터 전처리: 생성 AI는 데이터 전처리 작업을 자동화하는 데 사용될 수 있습니다. 데이터를 가져오고 정제하며, 결측치 처리, 이상치 탐지 등의 작업을 자동으로 수행할 수 있습니다.

4. 질의 응답: 생성 AI는 사용자의 질문에 대한 답변을 제공하는 데 사용될 수 있습니다. 자연어로 질문을 제기하면 AI는 데이터를 검색하고 분석하여 해당 질문에 대한 답변을 제공합니다.

5. 데이터 예측과 추론: 생성 AI는 데이터를 기반으로 예측과 추론을 수행할 수 있습니다. 과거 데이터를 분석하고 트렌드를 파악하여 미래의 상황을 예측하거나, 주어진 데이터로부터 결론을 도출할 수 있습니다.

6. 보고서 작성: 생성 AI는 데이터 분석 결과를 요약하고 보고서를 작성하는 데 사용될 수 있습니다. 사용자는 보고서에 포함시킬 내용과 형식을 지정하고, AI는 해당 내용을 분석하여 보고서를 생성합니다.

출처: https://n.news.naver.com/article/092/0002293567?sid=105 

목차로 이동