Kubernetes

in blog on K8s, kubernetes

쿠버네티스

  1. 쿠버네티스 (Kubernetes)
    1. Kubernetes Documentation
    2. Getting started
    3. Concepts
    4. Tasks
    5. Tutorials
    6. Reference
    7. Contribute to Kubernetes

쿠버네티스 (Kubernetes)

Kubernetes Documentation

  • Understand Kubernetes

    Learn about Kubernetes and its fundamental concepts.

    • Why Kubernetes?
    • Components of a cluster
    • The Kubernetes API
    • Objects In Kubernetes
    • Containers
    • Workloads and Pods

  • Try Kubernetes

    Follow tutorials to learn how to deploy applications in Kubernetes.

    • Hello Minikube
    • Walkthrough the basics
    • Stateless Example: PHP Guestbook with Redis
    • Stateful Example: Wordpress with Persistent Volumes

  • Set up a K8s cluster

    Get Kubernetes running based on your resources and needs.

    • Learning environment
    • Production environment
    • Install the kubeadm setup tool
    • Securing a cluster
    • kubeadm command reference

  • Learn how to use Kubernetes

    Look up common tasks and how to perform them using a short sequence of steps.

    • kubectl Quick Reference
    • Install kubectl
    • Configure access to clusters
    • Use the Web UI Dashboard
    • Configure a Pod to Use a ConfigMap
    • Getting help

  • Look up reference information

    Browse terminology, command line syntax, API resource types, and setup tool documentation.

    • Glossary
    • kubectl command line tool
    • Labels, annotations and taints
    • Kubernetes API reference
    • Overview of API
    • Feature Gates

  • Contribute to Kubernetes

    Find out how you can help make Kubernetes better.

    • Contribute to Kubernetes
    • Contribute to documentation
    • Suggest content improvements
    • Opening a pull request
    • Documenting a feature for a release
    • Localizing the docs
    • Participating in SIG Docs
    • Viewing Site Analytics

  • Training

    Get certified in Kubernetes and make your cloud native projects successful!

  • Download Kubernetes

    Install Kubernetes or upgrade to the newest version.

  • About the documentation

    This website contains documentation for the current and previous 4 versions of Kubernetes.

Getting started

Concepts

  • Overview

    Kubernetes is a portable, extensible, open source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available.

    Why you need Kubernetes and what it can do.

    FeaturesDescriptions
    Service discovery and load balancingKubernetes can expose a container using the DNS name or using their own IP address. If traffic to a container is high, Kubernetes is able to load balance and distribute the network traffic so that the deployment is stable.
    Storage orchestrationKubernetes allows you to automatically mount a storage system of your choice, such as local storages, public cloud providers, and more.
    Automated rollouts and rollbacksYou can describe the desired state for your deployed containers using Kubernetes, and it can change the actual state to the desired state at a controlled rate. For example, you can automate Kubernetes to create new containers for your deployment, remove existing containers and adopt all their resources to the new container.
    Automatic bin packingYou provide Kubernetes with a cluster of nodes that it can use to run containerized tasks. You tell Kubernetes how much CPU and memory (RAM) each container needs. Kubernetes can fit containers onto your nodes to make the best use of your resources.
    Self-healingKubernetes restarts containers that fail, replaces containers, kills containers that don’t respond to your user-defined health check, and doesn’t advertise them to clients until they are ready to serve.
    Secret and configuration managementKubernetes lets you store and manage sensitive information, such as passwords, OAuth tokens, and SSH keys. You can deploy and update secrets and application configuration without rebuilding your container images, and without exposing secrets in your stack configuration.
    Batch executionIn addition to services, Kubernetes can manage your batch and CI workloads, replacing containers that fail, if desired.
    Horizontal scalingScale your application up and down with a simple command, with a UI, or automatically based on CPU usage.
    IPv4/IPv6 dual-stackAllocation of IPv4 and IPv6 addresses to Pods and Services
    Designed for extensibilityAdd features to your Kubernetes cluster without changing upstream source code.

    What Kubernetes is not

    #Kubernetes:
    1Does not limit the types of applications supported. Kubernetes aims to support an extremely diverse variety of workloads, including stateless, stateful, and data-processing workloads. If an application can run in a container, it should run great on Kubernetes.
    2Does not deploy source code and does not build your application. Continuous Integration, Delivery, and Deployment (CI/CD) workflows are determined by organization cultures and preferences as well as technical requirements.
    3Does not provide application-level services, such as middleware (for example, message buses), data-processing frameworks (for example, Spark), databases (for example, MySQL), caches, nor cluster storage systems (for example, Ceph) as built-in services. Such components can run on Kubernetes, and/or can be accessed by applications running on Kubernetes through portable mechanisms, such as the Open Service Broker.
    4Does not dictate logging, monitoring, or alerting solutions. It provides some integrations as proof of concept, and mechanisms to collect and export metrics.
    5Does not provide nor mandate a configuration language/system (for example, Jsonnet). It provides a declarative API that may be targeted by arbitrary forms of declarative specifications.
    6Does not provide nor adopt any comprehensive machine configuration, maintenance, management, or self-healing systems.
    7Additionally, Kubernetes is not a mere orchestration system. In fact, it eliminates the need for orchestration. The technical definition of orchestration is execution of a defined workflow: first do A, then B, then C. In contrast, Kubernetes comprises a set of independent, composable control processes that continuously drive the current state towards the provided desired state. It shouldn’t matter how you get from A to C. Centralized control is also not required. This results in a system that is easier to use and more powerful, robust, resilient, and extensible.

    Historical context for Kubernetes

    historyhescriptions
    Traditional deploymentEarly on, organizations ran applications on physical servers. There was no way to define resource boundaries for applications in a physical server, and this caused resource allocation issues. For example, if multiple applications run on a physical server, there can be instances where one application would take up most of the resources, and as a result, the other applications would underperform. A solution for this would be to run each application on a different physical server. But this did not scale as resources were underutilized, and it was expensive for organizations to maintain many physical servers.
    Virtualized deploymentAs a solution, virtualization was introduced. It allows you to run multiple Virtual Machines (VMs) on a single physical server’s CPU. Virtualization allows applications to be isolated between VMs and provides a level of security as the information of one application cannot be freely accessed by another application.</br></br>Virtualization allows better utilization of resources in a physical server and allows better scalability because an application can be added or updated easily, reduces hardware costs, and much more. With virtualization you can present a set of physical resources as a cluster of disposable virtual machines.</br></br>Each VM is a full machine running all the components, including its own operating system, on top of the virtualized hardware.
    Container deploymentContainers are similar to VMs, but they have relaxed isolation properties to share the Operating System (OS) among the applications. Therefore, containers are considered lightweight. Similar to a VM, a container has its own filesystem, share of CPU, memory, process space, and more. As they are decoupled from the underlying infrastructure, they are portable across clouds and OS distributions.</br></br>Containers have become popular because they provide extra benefits, such as:</br></br>- Agile application creation and deployment: increased ease and efficiency of container image creation compared to VM image use.</br>- Continuous development, integration, and deployment: provides for reliable and frequent container image build and deployment with quick and efficient rollbacks (due to image immutability).</br>- Dev and Ops separation of concerns: create application container images at build/release time rather than deployment time, thereby decoupling applications from infrastructure.</br>- Observability: not only surfaces OS-level information and metrics, but also application health and other signals.</br>- Environmental consistency across development, testing, and production: runs the same on a laptop as it does in the cloud.</br>- Cloud and OS distribution portability: runs on Ubuntu, RHEL, CoreOS, on-premises, on major public clouds, and anywhere else.</br>- Application-centric management: raises the level of abstraction from running an OS on virtual hardware to running an application on an OS using logical resources.</br>- Loosely coupled, distributed, elastic, liberated micro-services: applications are broken into smaller, independent pieces and can be deployed and managed dynamically – not a monolithic stack running on one big single-purpose machine.</br>- Resource isolation: predictable application performance.</br>- Resource utilization: high efficiency and density

    • Kubernetes Components

      An overview of the key components that make up a Kubernetes cluster.

      Core Components

      A Kubernetes cluster consists of a control plane and one or more worker nodes. Here’s a brief overview of the main components:

      • Control Plane Components

        Manage the overall state of the cluster:

        componentsdescriptions
        kube-apiserverThe core component server that exposes the Kubernetes HTTP API
        etcdConsistent and highly-available key value store for all API server data
        kube-schedulerLooks for Pods not yet bound to a node, and assigns each Pod to a suitable node.
        kube-controller-managerRuns controllers to implement Kubernetes API behavior.
        cloud-controller-manager (optional)Integrates with underlying cloud provider(s)

      • Node Components

        Run on every node, maintaining running pods and providing the Kubernetes runtime environment:

        componentsdescriptions
        kubeletEnsures that Pods are running, including their containers.
        kube-proxy (optional)Maintains network rules on nodes to implement Services.
        Container runtimeSoftware responsible for running containers. Read Container Runtimes to learn more.

      • Addons

        Addons extend the functionality of Kubernetes. A few important examples include:

        componentsdescriptions
        DNSFor cluster-wide DNS resolution
        Web UI (Dashboard)For cluster management via a web interface
        Container Resource MonitoringFor collecting and storing container metrics
        Cluster-level LoggingFor saving container logs to a central log store

    • Objects In Kubernetes

      Kubernetes objects are persistent entities in the Kubernetes system. Kubernetes uses these entities to represent the state of your cluster. Learn about the Kubernetes object model and how to work with these objects.
      This page explains how Kubernetes objects are represented in the Kubernetes API, and how you can express them in .yaml format.

      Understanding Kubernetes objects

      Kubernetes objects are persistent entities in the Kubernetes system. Kubernetes uses these entities to represent the state of your cluster. Specifically, they can describe:

      - What containerized applications are running (and on which nodes)
- The resources available to those applications
- The policies around how those applications behave, such as restart policies, upgrades, and fault-tolerance

      Object spec and status

      Almost every Kubernetes object includes two nested object fields that govern the object's configuration: the object `spec` and the object `status`. For objects that have a `spec`, you have to set this when you create the object, providing a description of the characteristics you want the resource to have: its desired `state`.

      Describing a Kubernetes object

      When you create an object in Kubernetes, you must provide the object spec that describes its desired state, as well as some basic information about the object (such as a name). When you use the Kubernetes API to create the object (either directly or via kubectl), that API request must include that information as JSON in the request body.

Here's an example manifest that shows the required fields and object spec for a Kubernetes Deployment:

        apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: nginx-deployment
  spec:
    selector:
      matchLabels:
        app: nginx
    replicas: 2 # tells deployment to run 2 pods matching the template
    template:
      metadata:
        labels:
          app: nginx
      spec:
        containers:
        - name: nginx
          image: nginx:1.14.2
          ports:
          - containerPort: 80

        kubectl apply -f https://k8s.io/examples/application/deployment.yaml

  deployment.apps/nginx-deployment created

      Required fields

      In the manifest (YAML or JSON file) for the Kubernetes object you want to create, you’ll need to set values for the following fields:

      fieldsdescriptions
      apiVersionWhich version of the Kubernetes API you’re using to create this object
      kindWhat kind of object you want to create
      metadataData that helps uniquely identify the object, including a name string, UID, and optional namespace
      specWhat state you desire for the object

      Server side field validation

      Starting with Kubernetes v1.25, the API server offers server side field validation that detects unrecognized or duplicate fields in an object. It provides all the functionality of kubectl --validate on the server side.

      fieldsdescriptions
      StrictStrict field validation, errors on validation failure
      WarnField validation is performed, but errors are exposed as warnings rather than failing the request
      IgnoreNo server side field validation is performed
      • Kubernetes Object Management
        • Imperative object configuration: In imperative object configuration, the kubectl command specifies the operation (create, replace, etc.), optional flags and at least one file name. The file specified must contain a full definition of the object in YAML or JSON format. API reference
        object configurationdescriptions
        Create the objects defined in a configuration filekubectl create -f nginx.yaml
        Delete the objects defined in two configuration fileskubectl delete -f nginx.yaml -f redis.yaml
        Update the objects defined in a configuration file by overwriting the live configurationkubectl replace -f nginx.yaml
        • Declarative object configuration: When using declarative object configuration, a user operates on object configuration files stored locally, however the user does not define the operations to be taken on the files. Create, update, and delete operations are automatically detected per-object by kubectl. This enables working on directories, where different operations might be needed for different objects.

        Examples

        Process all object configuration files in the configs directory, and create or patch the live objects. You can first diff to see what changes are going to be made, and then apply:

          kubectl diff -f configs/
  kubectl apply -f configs/

        Recursively process directories:

          kubectl diff -R -f configs/
  kubectl apply -R -f configs/

      • Object Names and IDs

        Each object in your cluster has a Name that is unique for that type of resource. Every Kubernetes object also has a UID that is unique across your whole cluster.

        For example, you can only have one Pod named myapp-1234 within the same namespace, but you can have one Pod and one Deployment that are each named myapp-1234.

        • Names

          A client-provided string that refers to an object in a resource URL, such as /api/v1/pods/some-name.
          Only one object of a given kind can have a given name at a time. However, if you delete the object, you can make a new object with the same name.

          Names must be unique across all API versions of the same resource. API resources are distinguished by their API group, resource type, namespace (for namespaced resources), and name. In other words, API version is irrelevant in this context.

          • DNS Subdomain Names

            Most resource types require a name that can be used as a DNS subdomain name as defined in RFC 1123. This means the name must:

            • contain no more than 253 characters
            • contain only lowercase alphanumeric characters, ‘-‘ or ‘.’
            • start with an alphanumeric character
            • end with an alphanumeric character

          • RFC 1123 Label Names

            Some resource types require their names to follow the DNS label standard as defined in RFC 1123. This means the name must:

            • contain at most 63 characters
            • contain only lowercase alphanumeric characters or ‘-‘
            • start with an alphanumeric character
            • end with an alphanumeric character

          • RFC 1035 Label Names

            Some resource types require their names to follow the DNS label standard as defined in RFC 1035. This means the name must:

            • contain at most 63 characters
            • contain only lowercase alphanumeric characters or ‘-‘
            • start with an alphabetic character
            • end with an alphanumeric character

          • Path Segment Names

            Some resource types require their names to be able to be safely encoded as a path segment. In other words, the name may not be “.” or “..” and the name may not contain “/” or “%”.

            apiVersion: v1
kind: Pod
metadata:
  name: nginx-demo
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

        • UIDs

          A Kubernetes systems-generated string to uniquely identify objects.
          Every object created over the whole lifetime of a Kubernetes cluster has a distinct UID. It is intended to distinguish between historical occurrences of similar entities.
          Kubernetes UIDs are universally unique identifiers (also known as UUIDs). UUIDs are standardized as ISO/IEC 9834-8 and as ITU-T X.667.

      • Labels and Selectors
      • Namespaces
      • Annotations
      • Field Selectors
      • Finalizers
      • Owners and Dependents
      • Recommended Labels

    • The Kubernetes API

  • Cluster Architecture
    • Nodes
    • Communication between Nodes and the Control Plane
    • Controllers
    • Leases
    • Cloud Controller Manager
    • About cgroup v2
    • Container Runtime Interface (CRI)
    • Garbage Collection
    • Mixed Version Proxy
  • Containers
    • Images
    • Container Environment
    • Runtime Class
    • Container Lifecycle Hooks
  • Workloads
    • Pods
      • Pod Lifecycle
      • Init Containers
      • Sidecar Containers
      • Ephemeral Containers
      • Disruptions
      • Pod Quality of Service Classes
      • User Namespaces
      • Downward API
    • Workload Management
      • Deployments
      • ReplicaSet
      • StatefulSets
      • DaemonSetJobs
      • Automatic Cleanup for Finished Jobs
      • CronJob
      • ReplicationController
    • Autoscaling Workloads
    • Managing Workloads
  • Services, Load Balancing, and Networking
    • Service
    • Ingress
    • Ingress Controllers
    • Gateway API
    • EndpointSlices
    • Network Policies
    • DNS for Services and Pods
    • IPv4/IPv6 dual-stack
    • Topology Aware Routing
    • Networking on Windows
    • Service ClusterIP allocation
    • Service Internal Traffic Policy
  • Storage
    • Volumes
    • Persistent Volumes
    • Projected Volumes
    • Ephemeral Volumes
    • Storage Classes
    • Volume Attributes Classes
    • Dynamic Volume Provisioning
    • Volume Snapshots
    • Volume Snapshot Classes
    • CSI Volume Cloning
    • Storage Capacity
    • Node-specific Volume Limits
    • Volume Health Monitoring
    • Windows Storage
  • Configuration
    • Configuration Best Practices
    • ConfigMaps
    • Secrets
    • Liveness, Readiness, and Startup Probes
    • Resource Management for Pods and Containers
    • Organizing Cluster Access Using kubeconfig Files
    • Resource Management for Windows nodes
  • Security
    • Cloud Native Security and Kubernetes
    • Pod Security Standards
    • Pod Security Admission
    • Service Accounts
    • Pod Security Policies
    • Security For Windows Nodes
    • Controlling Access to the Kubernetes API
    • Role Based Access Control Good Practices
    • Good practices for Kubernetes Secrets
    • Multi-tenancy
    • Hardening Guide - Authentication Mechanisms
    • Kubernetes API Server Bypass Risks
    • Linux kernel security constraints for Pods and containers
    • Security Checklist
    • Application Security Checklist
  • Policies
    • Limit Ranges
    • Resource Quotas
    • Process ID Limits And Reservations
    • Node Resource Managers
  • Scheduling, Preemption and Eviction
    • Kubernetes Scheduler
    • Assigning Pods to Nodes
    • Pod Overhead
    • Pod Topology Spread Constraints
    • Taints and Tolerations
    • Scheduling Framework
    • Dynamic Resource Allocation
    • Scheduler Performance Tuning
    • Resource Bin Packing for Extended Resources
    • Pod Priority and Preemption
    • Node-pressure Eviction
    • API-initiated Eviction
  • Cluster Administration
    • Node Shutdowns
    • Certificates
    • Cluster Networking
    • Logging Architecture
    • Metrics For Kubernetes System Components
    • Metrics for Kubernetes Object States
    • System Logs
    • Traces For Kubernetes System Components
    • Proxies in Kubernetes
    • API Priority and Fairness
    • Cluster Autoscaling
    • Installing Addons
    • Coordinated Leader Election
  • Windows in Kubernetes
    • Windows containers in Kubernetes
    • Guide for Running Windows Containers in Kubernetes
  • Extending Kubernetes
    • Compute, Storage, and Networking Extensions
    • Extending the Kubernetes API
    • Operator pattern

Tasks

Tutorials

  • Hello Minikube
  • Learn Kubernetes Basics
    • Create a Cluster
    • Deploy an App
    • Explore Your App
    • Expose Your App Publicly
    • Scale Your App
    • Update Your App
  • Configuration
    • Updating Configuration via a ConfigMap
    • Configuring Redis using a ConfigMap
    • Adopting Sidecar Containers
  • Security
    • Apply Pod Security Standards at the Cluster Level
    • Apply Pod Security Standards at the Namespace Level
    • Restrict a Container’s Access to Resources with AppArmor
    • Restrict a Container’s Syscalls with seccomp
  • Stateless Applications
    • Exposing an External IP Address to Access an Application in a Cluster
    • Example: Deploying PHP Guestbook application with Redis
  • Stateful Applications
    • StatefulSet Basics
    • Example: Deploying WordPress and MySQL with Persistent Volumes
    • Example: Deploying Cassandra with a StatefulSet
    • Running ZooKeeper, A Distributed System Coordinator
  • Cluster Management
    • Running Kubelet in Standalone Mode
  • Services
    • Connecting Applications with Services
    • Using Source IP
    • Explore Termination Behavior for Pods And Their Endpoints

Reference

  • Glossary
  • API Overview
  • API Access Control
  • Well-Known Labels, Annotations and Taints
  • Kubernetes API
  • Instrumentation
  • Kubernetes Issues and Security
  • Node Reference Information
  • Networking Reference
  • Setup tools
  • Command line tool (kubectl)
  • Component tools
  • Debug cluster
  • Configuration APIs
  • External APIs
  • Scheduling
  • Other Tools

Contribute to Kubernetes

  • Contribute to Kubernetes Documentation
  • Suggesting content improvements
  • Contributing new content
    • Opening a pull request
    • Documenting for a release
    • Blogs and case studies
  • Reviewing changes
    • Reviewing pull requests
    • For approvers and reviewers
  • Localizing Kubernetes documentation
  • Participating in SIG Docs
    • Roles and responsibilities
    • Issue Wranglers
    • PR wranglers
  • Documentation style overview
    • Content guide
    • Style guide
    • Diagram guide
    • Writing a new topic
    • Page content types
    • Content organization
    • Custom Hugo Shortcodes
  • Updating Reference Documentation
    • Quickstart
    • Contributing to the Upstream Kubernetes Code
    • Generating Reference Documentation for the Kubernetes API
    • Generating Reference Documentation for kubectl Commands
    • Generating Reference Documentation for Metrics
    • Generating Reference Pages for Kubernetes Components and Tools
  • Advanced contributing
  • Viewing Site Analytics

© 2018. All rights reserved.

Powered by Hydejack v8.4.0