KCNA 공부용

Cloud Native Architecture

학습한 영어단어

Contrary : 반대되는
viable : 생존가능한
in contrast: 대조적으로
emphasis : 중요성
synonymously : 같은 의미로
explicit : 명백한
implicit : 절대적인
rebate : 환불
impose : 부과하다
substantial : 상당한
due diligence : 실사 (조사)
emeritus : 명예교수
predecessors : 선임자 (앞서나간 사람)
tampered : 조작된
malicious : 악의있는
pitfalls : 함정

Open Standards

image-spec : how to build and package container images
runtime-spec : specifies the configuration, execution environment, lifecycle of containers
distribution-spec : provides a standard for distribution content, including container images

OCI Spec : image, runtime, and distribution specification on how to run, build, and distribute containers
Container Network Interface (CNI) : A specification on how to implement networking for Containers.
Container Runtime Interface (CRI) : A specification on how to implement container runtimes in container orrchestration systems.
Container Storage Interface (CSI) : A specification on now to implement storage in container orchestration systems.
Service Mesh Interface (SMI) : A specification on how to implement Service Meshes in container orchestration systems with a focus on Kubernetes.

Cloud Native Roles

Cloud Architect : Responsible for the adoption of cloud technologies, designing application landscape and infrastructure, with a focus on security, scalability, and deployment mechanisms.

DevOps Engineer : simple commbiniation of developer and administrator, use tools and processes that balance out software development and operations, starting with approaches to writing, building, and testing software throughout the deployment lifecycle

Security Engineer : Cloud technologies have created new attack vectors, and these days the role has to be lived much more inclusively and as an integral part of team.

DevSecOps Engineer : Combines the roles of the previous two (DevOps, Security). This role is often used to build bridges between more traditional development and security teams.

Site Reliability Engineer (SRE) : The overaching goal of SRE is to create and maintain software that is reliable and scalable. To achieve this, software engineering approaches are used to solve operational problems and automate operational tasks.

SREs use three main metrics

Service Level Objectives (SLO) : Specify a target level for the reliability of your service. - A goal that is set, for example, reaching a service latency of less than 100ms.

Service Level Indicators (SLI) : A carefully defined quantitivave neasure of some aspect of the level of service that is provided - For example, how long a request actually needs to be answered.

Service Level Agreement (SLA) : An explicit or implicit contract with your users that includes consequences of meeting (or missing) the SLOs they contain. The consequences are most easily recognized when they are finalcial - a rebate or a penalty - but they can take other forms. - Answers the question of what happens if SLOs are not met.

Community and Governance

Projects are categorized according to maturity and go through a sandbaox and incubation stage before graduation.

Technical Oversight Committee (TOC) : Responsible for defining and maintaining the technical vision, approving new projects, accepting feedback from the end-user committee, and establishing standards practices for CNCF projects.

CNCF Graduation Criteria

Sandbox Stage : entry-level stage in the CNCF project maturity model. designed for early-stage or experimental cloud native projects.

Incubating Stage : mid-level tier in the CNCF project maturity model. To be accpted into Incubating, a project must first satisfy all Sandbox requirements and then complete a comprehensive technical due to diligence review by the Technocal Oversight Committee. Key criteria include.

• Documented successful production use by at least three independent end-user organizations
• A health, diverse committer base
• Demonstarte a substantial ongoing flow of commits and merged contributions.
• Sustained and substantial commit activity with regular merged contributions from multiple organizations.
• A clear and adopted versioning scheme
• Publicly documented security processes that explain how to report vulnerabilities and how the project delivers fixes or security releases.
• At least one publicly available reference implementation for any specifications the project defines

Graduation Stage : highest maturity level in the CNCF project model. It designated projects that have achieved widespread adoption, demonstrated long-term sustainability, and have exemplary open source governance. A project must first satisfy all Incubating-stage requirements and then meet the following additional criteria:

• Committers from at least two distinct organizations.
• Achevement and ongoing maintenance of the CNCF Best PRactices Badge at the passing or higher level.
• Completion of an independent, third-party security audit with publicly published results of comparable scope and quailty to other CNCF graduated projects
• Explicity documented project governance and committer promotion process, preferably in a GOVERNANCE.md file
• Clearly defined criteria, process, and emeritus/offboarding conditions for project maintainers and representative interacting with the CNCF on the project's behalf
• A public list of productuon adopters for the primary repository
• A supermajority approval vote from the Technical Oversight Committee

Container Orchestration

Container Basics

Eight namespaces that The Linux Kernel 5.6 provides

• pid : process ID provides a process with its own set of process IDs.
• net : network allows the processes to have their own network stack, including the IP address.
• mnt : mount abstracts the filesystem view and manages mount points.
• ipc : Inter-Process Communication provides separation of named shared memory segments.
• user : provides process with their own set of user IDs and group IDs.
• uts : Unix time sharing allows processed to have their own hostname and domain name.
• cgroup : a newer namespace that allows a process to have their own hostname and domain name.
• time : the newest namespace can be used to virtualize the clock of the system.

Running Containers

To run industry-standard containers, you don't need to use Docker. you followe the OCI runtime-spec standard instead.

runC : Open Container Initiative maintains a container runtime. (low-level runtime)

Podman : provides a similiar API to Docker and can be used as a drop-in replacement, Moreover, it includes additional features, such as running containners without root privileges and using the Pod concept, which we'll discover later.