OpenStack 운영을 통해 얻은 교훈을 공유합니다.
목차
1. TOAST 클라우드 지금의 모습
2. OpenStack 선택의 이유
3. 구성의 어려움과 극복 사례
4. 활용 사례
5. 풀어야 할 문제들
대상
- TOAST 클라우드를 사용하고 싶은 분
- WMI를 처음 들어보시는 분
PostgreSQL is a very popular and feature-rich DBMS. At the same time, PostgreSQL has a set of annoying wicked problems, which haven't been resolved in decades. Miraculously, with just a small patch to PostgreSQL core extending this API, it appears possible to solve wicked PostgreSQL problems in a new engine made within an extension.
This document provides an overview of Kubernetes including:
1) Kubernetes is an open-source platform for automating deployment, scaling, and operations of containerized applications. It provides container-centric infrastructure and allows for quickly deploying and scaling applications.
2) The main components of Kubernetes include Pods (groups of containers), Services (abstract access to pods), ReplicationControllers (maintain pod replicas), and a master node running key components like etcd, API server, scheduler, and controller manager.
3) The document demonstrates getting started with Kubernetes by enabling the master on one node and a worker on another node, then deploying and exposing a sample nginx application across the cluster.
Optimizing Kubernetes Resource Requests/Limits for Cost-Efficiency and Latenc...Henning Jacobs
Kubernetes has the concept of resource requests and limits. Pods get scheduled on the nodes based on their requests and optionally limited in how much of the resource they can consume. Understanding and optimizing resource requests/limits is crucial both for reducing resource "slack" and ensuring application performance/low-latency. This talk shows our approach to monitoring and optimizing Kubernetes resources for 80+ clusters to achieve cost-efficiency and reducing impact for latency-critical applications. All shown tools are Open Source and can be applied to most Kubernetes deployments.
2021년 11월 18일(목)
- 14:00 ~ 15:00 MySQL Operator for Kubernetes
: Kubernetes 환경에서 MySQL에 대한 더 쉬운 운영
- 15:00 ~ 15:15 MySQL HA and Auto-Failover
: MySQL replication과 오픈소스 MHA를 통한 고가용성 확보
OpenStack 운영을 통해 얻은 교훈을 공유합니다.
목차
1. TOAST 클라우드 지금의 모습
2. OpenStack 선택의 이유
3. 구성의 어려움과 극복 사례
4. 활용 사례
5. 풀어야 할 문제들
대상
- TOAST 클라우드를 사용하고 싶은 분
- WMI를 처음 들어보시는 분
PostgreSQL is a very popular and feature-rich DBMS. At the same time, PostgreSQL has a set of annoying wicked problems, which haven't been resolved in decades. Miraculously, with just a small patch to PostgreSQL core extending this API, it appears possible to solve wicked PostgreSQL problems in a new engine made within an extension.
This document provides an overview of Kubernetes including:
1) Kubernetes is an open-source platform for automating deployment, scaling, and operations of containerized applications. It provides container-centric infrastructure and allows for quickly deploying and scaling applications.
2) The main components of Kubernetes include Pods (groups of containers), Services (abstract access to pods), ReplicationControllers (maintain pod replicas), and a master node running key components like etcd, API server, scheduler, and controller manager.
3) The document demonstrates getting started with Kubernetes by enabling the master on one node and a worker on another node, then deploying and exposing a sample nginx application across the cluster.
The document discusses different Docker networking drivers including null, host, bridge, overlay, and macvlan/ipvlan networks. It provides examples of creating networks with each driver and how containers on different networks will connect and obtain IPs. Specifically, it shows how the bridge driver sets up a private Docker bridge network (docker0 by default) and how overlay networks use VXLAN tunnels to connect containers across multiple Docker daemons.
source : http://www.opennaru.com/opensource/kubernetes/
Kubernetes는 컨테이너화된 애플리케이션(Containerized Application)의 배포, 확장 그리고 관리를 할 수 있는 오픈 소스 컨테이너 오케스트레이션 시스템입니다.
쿠버네티스는 구글 엔지니어들이 개발하고 설계한 플랫폼으로서 사내에서 이용하던 컨테이너 클러스터 관리 도구인 “Borg”의 아이디어를 바탕으로 만들어진 오픈소스 소프트웨어입니다.
구글은 쿠버네티스의 원천이 되는 Borg를 수년 동안 개발하고 운영하면서 축적된 경험을 바탕으로 쿠버네티스를 오픈소스 프로젝트로 만들어 었습니다.
[오픈소스컨설팅] Open Stack Ceph, Neutron, HA, Multi-RegionJi-Woong Choi
OpenStack Ceph & Neutron에 대한 설명을 담고 있습니다.
1. OpenStack
2. How to create instance
3. Ceph
- Ceph
- OpenStack with Ceph
4. Neutron
- Neutron
- How neutron works
5. OpenStack HA- controller- l3 agent
6. OpenStack multi-region
Hands-On Introduction to Kubernetes at LISA17Ryan Jarvinen
This document provides an agenda and instructions for a hands-on introduction to Kubernetes tutorial. The tutorial will cover Kubernetes basics like pods, services, deployments and replica sets. It includes steps for setting up a local Kubernetes environment using Minikube and demonstrates features like rolling updates, rollbacks and self-healing. Attendees will learn how to develop container-based applications locally with Kubernetes and deploy changes to preview them before promoting to production.
Kubernetes currently has two load balancing mode: userspace and IPTables. They both have limitation on scalability and performance. We introduced IPVS as third kube-proxy mode which scales kubernetes load balancer to support 50,000 services. Beyond that, control plane needs to be optimized in order to deploy 50,000 services. We will introduce alternative solutions and our prototypes with detailed performance data.
Kubernetes: A Short Introduction (2019)Megan O'Keefe
Kubernetes is an open-source system for automating deployment, scaling, and management of containerized applications. It groups containers that make up an application into logical units for easy management and discovery called pods. Kubernetes can manage pods across a cluster of machines, providing scheduling, deployment, scaling, load balancing, volume mounting and networking. It is widely used by companies like Google, CERN and in large projects like processing images and analyzing particle interactions. Kubernetes is portable, can span multiple cloud providers, and continues growing to support new workloads and use cases.
Confd, systemd, fleet을 이용한 어플리케이션 배포 in CoreOS충섭 김
Confd, systemd, fleet을 이용한 어플리케이션 배포 in CoreOS
Docker Seoul Meetup #2에서 발표한 자료입니다.
CoreOS에서 confd와 sidekick service를 이용한 서비스 배포에 대한 내용입니다.
http://www.youtube.com/watch?v=5ixJCM6pAcg
영상과 함께 보시면 더 좋습니다 :)
Hyperledger Fabric practice material for Korea Polytechnics students
- Build Your First Network
- Chaincode Development
- Chaincode Devolopment via IBM Blockchain Platform
- Balance Transfer
- Vote system example using 'Balance Transfer' tutorial
[오픈소스컨설팅] Docker를 활용한 Gitlab CI/CD 구성 테스트Ji-Woong Choi
Docker를 활용하여 Gitlab CI/CD 설치 구성 및 샘플 테스트를 위한 가이드 문서이며, Docker 및 Gitlab에 대한 개요 및 사용법에 대해서는 다루지 않습니다. Docker image를 이용 Gitlab 및 Gitlab CI/CD 설치 및 구성 후 Sample Spring boot web application을 이용하여 소스 변경에 따른 commit이 발생 했을 때 Gitlab CI/CD 기능을 통해 application 테스트, 빌드, 배포까지의 일련의 과정이 자동으로 진행��는지를 테스트 하는 내용입니다.
Helm was used to deploy Prometheus and the Prometheus stack on an EKS cluster for monitoring purposes. This included deploying Prometheus, Grafana, Alertmanager and associated pods and services. Some key steps taken were adding the Prometheus chart repository, configuring storage classes, and accessing the deployed applications. Potential issues with default storage configurations were also discussed.
The document provides instructions for deploying Prometheus and the Kube Prometheus Stack on NKS. Key steps include:
1. Deploying Prometheus using Helm with custom storage class and service type settings.
2. Verifying successful deployment by checking pods, services, and accessing the Prometheus UI.
3. Deploying the Kube Prometheus Stack using Helm, again with custom storage class and service type settings.
4. Verifying successful deployment including checking pods, services, and accessing the Grafana UI with default credentials to view pre-configured dashboards importing from Prometheus data.
The document provides instructions for deploying and managing an EKS (Elastic Kubernetes Service) cluster on AWS using eksctl. It outlines the steps to install eksctl and kubectl, deploy an EKS cluster called "eks-122" using eksctl with default settings, verify the cluster is active with 2 nodes, and finally delete the cluster when it is no longer needed.
네트워크 엔지니어에게 왜 쿠버네티스가 필요한지 설명하는 내용입니다.
영상은 아래의 링크에서 제공됩니다. https://www.inflearn.com/course/%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4-%EC%89%BD%EA%B2%8C%EC%8B%9C%EC%9E%91/lecture/97562
The document discusses how to set up a CDN on Google Kubernetes Engine (GKE). It involves:
1. Creating a deployment and exposing it via a LoadBalancer to test performance without CDN. Tests from Japan and Oregon VMs show response times from Japan are higher.
2. Creating an Ingress resource and exposing it, then enabling Cloud CDN on the Ingress backend.
3. Testing performance from the Oregon VM to the Ingress IP, which now benefits from the CDN, shows improved response times compared to testing the LoadBalancer without CDN.
This document discusses using Ansible to configure Dell EMC networking devices running OS10. It includes examples of using Ansible ad-hoc commands to ping devices and retrieve information using the dellos10_command module. It also provides a YAML playbook that creates VLAN 11 on different devices and interfaces and configures BFD between spine switches and the access switch.
1. 왜 쿠버네티스는 systemd로 cgroup을 관리하려고 할까요?
This document provides who want to know about cgroupfs in k8s.
- Email: pagaia@hotmail.com, geunwoo.j.shim@gmail.com
- Github: https://github.com/sysnet4admin, https://github.com/gnu-gnu
Permission is hereby granted, free of charge, to any person obtaining a copy of this
software and associated documentation files (the "Software"), to deal in the Software
without restriction, including without limitation the rights to use, copy, modify, merge,
publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons
to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or
substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE. Copyright <2021>
2. 1. 배경 지식
프로세스에 할당하는 CPU, 메모리, 네트워크 대역폭 등과 같은 자원을 개별적으로 제한하기
위한 시스템 커널의 기능을 cgroup 이라고 합니다. 컨테이너 런타임은 이 기술을 사용하에
컨테이너에 자원을 할당합니다. cgroup을 관리하기 위한 기술은 크게 cgroupfs와
systemd가 있습니다. cgroup이 관리할 수 있는 자원의 컨트롤러는파일 시스템의 형태로
관리되고 있습니다.
[그림 1] /sys/fs/cgroup 정보
[root@m-k8s ~]# ll /sys/fs/cgroup
total 0
drwxr-xr-x. 5 root root 0 Aug 24 13:19 blkio
lrwxrwxrwx. 1 root root 11 Aug 24 13:19 cpu -> cpu,cpuacct
lrwxrwxrwx. 1 root root 11 Aug 24 13:19 cpuacct -> cpu,cpuacct
drwxr-xr-x. 5 root root 0 Aug 24 13:19 cpu,cpuacct
drwxr-xr-x. 3 root root 0 Aug 24 13:19 cpuset
drwxr-xr-x. 5 root root 0 Aug 24 13:19 devices
drwxr-xr-x. 3 root root 0 Aug 24 13:19 freezer
drwxr-xr-x. 3 root root 0 Aug 24 13:19 hugetlb
drwxr-xr-x. 5 root root 0 Aug 24 13:19 memory
lrwxrwxrwx. 1 root root 16 Aug 24 13:19 net_cls -> net_cls,net_prio
drwxr-xr-x. 3 root root 0 Aug 24 13:19 net_cls,net_prio
lrwxrwxrwx. 1 root root 16 Aug 24 13:19 net_prio -> net_cls,net_prio
drwxr-xr-x. 3 root root 0 Aug 24 13:19 perf_event
drwxr-xr-x. 5 root root 0 Aug 24 13:19 pids
drwxr-xr-x. 5 root root 0 Aug 24 13:19 systemd
이 때 이와 관련된 정보를 파일 시스템의 형태로 변환시켜 주는 매니저가 cgroupfs 입니다.
cgroupfs는 /sys/fs/cgroup 경로의 하위에 이 정보를 마운트하여 관리하고 있습니다.
컨테이너에서 어떤 매니저를 사용하고 있는지는 다음의 명령으로 확인할 수 있습니다.
[그림 2] k8s 1.22 버전에서 cgroup 정보를 확인
[root@m-k8s ~]# kubelet --version
Kubernetes v1.22.0
[root@m-k8s ~]# docker info | grep Cgroup -F2
userxattr: false
Logging Driver: json-file
Cgroup Driver: systemd
Cgroup Version: 1
Plugins:
Volume: local
3. 2. systemd와 cgroupfs의 차이점
systemd와 cgroupfs는 모두 cgroup을 관리하기 위해 동작할 수 있지만 관리에 대한
접근법에는 다소 차이가 있습니다.
cgroupfs 가 cgroup(v1) 디렉터리 하위에서 리소스를 직접 매핑하는 구조를 가집니다.
[그림 3] tree 명령어로 확인한 cgroup 디렉터리 구조
[root@m-k8s ~]# tree /sys/fs/cgroup
/sys/fs/cgroup
|-- blkio
| |-- blkio.io_merged
| |-- blkio.io_merged_recursive
| |-- blkio.io_queued
[중략]
| |-- cgroup.procs
| |-- cgroup.sane_behavior
| |-- kubepods.slice
| | |-- blkio.io_merged
[생략]
반면 systemd는 프로세스가 사용하는 자원을 관리하기 위해 slice > scope > service
단위의 계층 구조를 만들어 각 단위에 자원을 할당합니다. 이러한 계층 구조는 systemd-
cgls 명령어가 표현해주는 구조 혹은 /sys/fs/cgroup/systemd 하위의 파일 시스템의 계층
구조를 통해서 확인할 수 있습니다. 이 때 systemd에 의해서 관리되는 cgroup과 관련된
정보는 /sys/fs/cgroup 하위의 자원의 컨트롤러(cpu, memory)등의 하위에서 slice의
이름으로 된 파일 시스템으로 표현됩니다.
[그림 4] systemd-cgls 명령어로 확인된 systemd의 계층적 구조
[root@m-k8s ~]# systemd-cgls
├─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 22
├─kubepods.slice
│ ├─kubepods-besteffort.slice
│ │ ├─kubepods-besteffort-podcad84c68_0c85_491a_8fe9_8a3d0e6220be.slice
│ │ │ ├─docker-
37d280b0f630ed9be113f365000a25c5c8dddec549bee9f193906ff751e6cdc8.scope
│ │ │ │ └─3197 /speaker --port=7472 --config=metallb
│ │ │ └─docker-
5c3eec595a326e26ae03e10261232b3fd6a9c80cc05a953f8a9f86d342f50f23.scope
│ │ │ └─2961 /pause
│ │ ├─kubepods-besteffort-podf028c909_cb9b_400e_9590_a3b2dec495f4.slice
│ │ │ ├─docker-
[생략]
4. 3. cgroup에 대한 쿠버네티스와 도커 선호도 차이는 왜?
이론적으로는 직접 cgroup을 마운트해서 사용하는 cgroupfs를 이용하거나 systemd와 같이
계층적인 구조로 만들어 접근하거나 결과적으로는 동일해야 합니다.
그럼에도 쿠버네티스에서는 systemd를 선호하고 도커에서는 cgroupfs를 왜 선호하는지
알아보았지만, 정확한 결론을 도출하진 못했습니다.
다만 쿠버네티스 공식 문서에서는 도커 18.03 + 커널 4.17.17 이하의 RHEL 에서는 cgroupfs
에서 메모리 leaking issue가 발생하여 systemd로 변경하라고 권고하는 것이 있으며,
도커에서는 cgroupfs를 cgroup v1에서만 사용하고 cgroup v2에서는 systemd로 변경할
계획이 있음을 밝히고 있습니다. 그리고 카카오 엔터프라이즈에서는 2개의 차이는 경로
관리 정책의 차이 일뿐 지금 당장은 시스템 성능에 영향을 주는 것은 아니라고 판단하여
cgroupfs 으로 진행하기로 하였다고 밝힌바 있습니다.
이를 종합적으로 본다면, 결과적으로는 cgroup을 구조화 하는 방법론적인 차이가 있는
수준으로 추정해 볼 수 있습니다.
4. 그런데 왜 쿠버네티스 v1.22에는 영향이 있을까?
쿠버네티스 v1.22로 올라가면서 기존에는 경고 수준으로 처리하던 cgroup driver를 특별히
정해진 설정 없다면, default를 systemd로 설정하도록 코드를 변경하였습니다.
Note: In v1.22, if the user is not setting the cgroupDriver field
under KubeletConfiguration, kubeadm will default it to systemd.
이에 따라 Docker에서 기본 값으로 가지고 있던 cgroupfs와 일치하지 않는 문제가
발생하게 되었습니다.
[코드 1] kubernetes/pkg/kubelet/dockershim/docker_service.go
76 // The expiration time of version cache.
77 versionCacheTTL = 60 * time.Second
78
79 defaultCgroupDriver = "cgroupfs" # 기본 값
80
81 // TODO: https://github.com/kubernetes/kubernetes/pull/31169 provides
experimental
82 // defaulting of host user namespace that may be enabled when the docker daemon
83 // is using remapped UIDs.
5. 84 // Dockershim should provide detection support for a remapping environment .
85 // This should be included in the feature proposal. Defaulting may still occur
according
86 // to kubelet behavior and system settings in addition to any API flags that may be
introduced.
v1.22에서 문제가 발생하는 이유는 다음과 같이 v1.22 이전에는 기본 값에 대해서 경고만
처리하는 수준에 그쳤다면, v1.22부터는 기본 값이 없는 경우(null) systemd로 넣도록
코드를 수정했기 때문입니다.
[코드 2] v1.22 버전의 kubernetes/cmd/kubeadm/app/componentconfigs/kubelet.go
198 // We cannot show a warning for RotateCertificates==false and we must hardcode it
to true.
199 // There is no way to determine if the user has set this or not, given the field is a
non-pointer.
200 kc.config.RotateCertificates = kubeletRotateCertificates
201
202 if len(kc.config.CgroupDriver) == 0 {
203 klog.V(1).Infof("the value of KubeletConfiguration.cgroupDriver is empty;
setting it to %q", constants.CgroupDriverSystemd)
204 kc.config.CgroupDriver = constants.CgroupDriverSystemd
205 }
[코드 3] v1.21 버전의 kubernetes/cmd/kubeadm/app/componentconfigs/kubelet.go
202 // We cannot show a warning for RotateCertificates==false and we must hardcode it
to true.
203 // There is no way to determine if the user has set this or not, given the field is a
non-pointer.
204 kc.config.RotateCertificates = kubeletRotateCertificates
205
206 // TODO: Conditionally set CgroupDriver to either `systemd` or `cgroupfs` for CRI
other than Docker
207 if nodeRegOpts.CRISocket == constants.DefaultDockerCRISocket {
208 driver, err := kubeadmutil.GetCgroupDriverDocker(utilsexec.New())
209 if err != nil {
210 klog.Warningf("cannot automatically set CgroupDriver when starting the
Kubelet: %v", err)
211 } else {
212 // if we can parse the right cgroup driver from docker info,
213 // we should always override CgroupDriver here no matter user
specifies this value explicitly or not
214 if kc.config.CgroupDriver != "" && kc.config.CgroupDriver != driver {
215 klog.Warningf("detected %q as the Docker cgroup driver, the
provided value %q in %q will be overrided", driver, kc.config.CgroupDriver, kind)
216 }
6. 217 kc.config.CgroupDriver = driver
218 }
219 }
5. 결론(TL; DR)
쿠버네티스 v1.22부터는 systemd를 사용하도록 설정 변경하는 것이 필요해 보이지만, 이전
버전의 사용자들은 현재 상태를 유지하고, 추후 업그레이드 시에 systemd로 이전을 고려해
보는 것이 좋을 것 같습니다. 이는 cgroup v2에서는 docker 마저도 systemd를 사용하도록
권고하기 때문에 업계에서 이미 cgroup에 대한 관리를 systemd로 맞추려고 하는 경향에
따른 것입니다. 쿠버네티스 또한 이런 흐름에 따라 systemd를 v1.22부터 기본 값으로 정한
것으로 보여집니다.
Note: 이는 개인들의 의견이며, 회사 및 기관을 대표하는 의견이 아님을 밝힙니다.
7. 참고 자료:
1) 테스트 환경
현재 환경의 CentOS 릴리즈 버전과 커널 버전은 다음과 같습니다.
[root@m-k8s ~]# cat /etc/redhat-release
CentOS Linux release 7.8.2003 (Core)
[root@m-k8s ~]# uname -r
3.10.0-1127.19.1.el7.x86_64
2) cgroup v1과 v2의 주요 차이
cgroup v2에서는 하나의 통일된 리소스 하위로 마운트하는 구조로 변경되었습니다.
출처: https://medium.com/some-tldrs/tldr-understanding-the-new-control-groups-api-by-rami-rosen-980df476f633
8. Reference:
1. Cgroup Driver 선택하기
https://tech.kakao.com/2020/06/29/cgroup-driver/
2. Changing the cgroup driver to systemd on Red Hat Enterprise Linux
https://www.ibm.com/support/knowledgecenter/SSBS6K_3.1.1/troubleshoot/docker
_cgroup.html
3. Options for the runtime
https://docs.docker.com/engine/reference/commandline/dockerd/#options-for-
the-runtime
4. Configuring a cgroup driver
https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/configure-cgroup-
driver/
5. Managing cgroups with systemd
https://www.redhat.com/sysadmin/cgroups-part-four
6. default the "cgroupDriver" setting of the kubelet to "systemd"
https://github.com/kubernetes/kubeadm/issues/2376