Kubernetes v1.17
dokumentasi sudah tidak dirawat lagi. Versi yang kamu lihat ini hanyalah snapshot statis. Untuk dokumentasi terkini, lihat
versi terkini.
Standardized Glossary
This glossary is intended to be a comprehensive, standardized list of Kubernetes terminology. It includes technical terms that are specific to Kubernetes, as well as more general terms that provide useful context.
Filter terms according to their tags
.
The inner components of Kubernetes.
Related to Kubernetes open-source development.
A resource type that Kubernetes supports by default.
Supported customizations of Kubernetes.
Relevant for a first-time user of Kubernetes.
How Kubernetes components talk to each other (and to programs outside the cluster).
Starting and maintaining Kubernetes.
Keeping Kubernetes applications safe and secure.
How Kubernetes applications handle persistent data.
Software that makes Kubernetes easier or better to use.
Admission controllers are configurable for the Kubernetes API server and may be “validating”, “mutating”, or
both. Any admission controller may reject the request. Mutating controllers may modify the objects they admit;
validating controllers may not.
You can enable or disable each API group by changing the configuration of your API server. You can also disable or enable paths to specific resources. API group makes it easier to extend the Kubernetes API. The API group is specified in a REST path and in the apiVersion field of a serialized object.
An init container lets you separate initialization details that are important for the overall
workloadA workload is an application running on Kubernetes., and that don’t need to keep running
once the application container has started.
If a pod doesn’t have any init containers configured, all the containers in that pod are app containers.
An architect ensures that an app’s implementation allows it to interact with its surrounding components in a scalable, maintainable way. Surrounding components include databases, logging infrastructure, and other microservices.
While code review is focused on code quality and correctness, approval is focused on the holistic acceptance of a contribution. Holistic acceptance includes backwards/forwards compatibility, adhering to API and flag conventions, subtle performance and correctness issues, interactions with other parts of the system, and others. Approver status is scoped to a part of the codebase. Approvers were previously referred to as maintainers.
Certificates enable applications within a Kubernetes cluster to access the Kubernetes API securely. Certificates validate that clients are allowed to access the API.
cgroup is a Linux kernel feature that limits, accounts for, and isolates the resource usage (CPU, memory, disk I/O, network) for a collection of processes.
Kubernetes v1.6 contains a new binary called cloud-controller-manager. cloud-controller-manager is a daemon that embeds cloud-specific control loops. These cloud-specific control loops were originally in the kube-controller-manager. Since cloud providers develop and release at a different pace compared to the Kubernetes project, abstracting the provider-specific code to the cloud-controller-manager binary allows cloud vendors to evolve independently from the core Kubernetes code.
The Cloud Native Computing Foundation (CNCF) builds sustainable ecosystems and
fosters a community around projects that
orchestrate containers as part of a microservices architecture.
Cloud providers, sometimes called Cloud Service Providers (CSPs), offer
cloud computing platforms or services.
Many cloud providers offer managed infrastructure (also called
Infrastructure as a Service or IaaS).
With managed infrastructure the cloud provider is responsible for
servers, storage, and networking while you manage layers on top of that
such as running a Kubernetes cluster.
You can also find Kubernetes as a managed service; sometimes called
Platform as a Service, or PaaS. With managed Kubernetes, your
cloud provider is responsible for the Kubernetes control plane as well
as the nodesA node is a worker machine in Kubernetes. and the
infrastructure they rely on: networking, storage, and possibly other
elements such as load balancers.
Examples of cluster operations work include: deploying new Nodes to
scale the cluster; performing software upgrades; implementing security
controls; adding or removing storage; configuring cluster networking;
managing cluster-wide observability; and responding to events.
Containers decouple applications from underlying host infrastructure to make deployment easier in different cloud or OS environments, and for easier scaling.
Two hooks are exposed to Containers: PostStart which executes immediately after a container is created and PreStop which is blocking and is called immediately before a container is terminated.
Some controllers also run inside the control plane, providing control loops that
are core to Kubernetes’ operations. For example: the deployment controller, the
daemonset controller, the namespace controller, and the persistent volume
controller (and others) all run within the
kube-controller-managerControl Plane component that runs controller processes..
If you, as cluster operator, destroy a Pod that belongs to an application,
Kubernetes terms that a voluntary disruption. If a Pod goes offline
because of a Node failure, or an outage affecting a wider failure zone,
Kubernetes terms that an involuntary disruption.
Docker uses the resource isolation features of the Linux kernel such as cgroups and kernel namespaces, and a union-capable file system such as OverlayFS and others to allow independent containers to run within a single Linux instance, avoiding the overhead of starting and maintaining virtual machines (VMs).
In the Kubernetes Community: Conversations often use downstream to mean the ecosystem, code, or third-party tools that rely on the core Kubernetes codebase. For example, a new feature in Kubernetes may be adopted by applications downstream to improve their functionality.
In GitHub or git: The convention is to refer to a forked repo as downstream, whereas the source repo is considered upstream.
If you want to investigate a Pod that’s running with problems, you can add an ephemeral container to that Pod and carry out diagnostics. Ephemeral containers have no resource or scheduling guarantees, and you should not use them to run any part of the workload itself.
Selalu perhatikan mekanisme untuk mem-backup data etcd pada klaster Kubernetes kamu. Untuk informasi lebih lanjut tentang etcd, lihat dokumentasi etcd.
Most cluster administrators will use a hosted or distribution instance of Kubernetes. As a result, most Kubernetes users will need to install extensions and fewer will need to author new ones.
Charts provide a reproducible way of creating and sharing Kubernetes applications.
A single chart can be used to deploy something simple, like a memcached Pod, or something complex, like a full web app stack with HTTP servers, databases, caches, and so on.
HostAliases is an optional list of hostnames and IP addresses that will be injected into the Pod’s hosts file if specified. This is only valid for non-hostNetwork Pods.
A way of packaging software that allows it to be stored in a container registry, pulled to a local system, and run as an application. Meta data is included in the image that can indicate what executable to run, who built it, and other information.
Initialization (init) containers are like regular app containers, with one difference: init containers must run to completion before any app containers can start. Init containers run in series: each init container must run to completion before the next init container begins.
An open platform (not Kubernetes-specific) that provides a uniform way to integrate microservices, manage traffic flow, enforce policies, and aggregate telemetry data.
Adding Istio does not require changing application code. It is a layer of infrastructure between a service and the network, which when combined with service deployments, is commonly referred to as a service mesh. Istio’s control plane abstracts away the underlying cluster management platform, which may be Kubernetes, Mesosphere, etc.
Sebuah ekstensi API yang memungkinkan aplikasi berjalan pada klaster Kubernetes untuk
mempermudah penggunaan perangkat lunak yang dikelola eksternal, seperti servis penyimpanan
data yang ditawarkan oleh penyedia layanan komputasi awan.
Secara logis, setiap kontroler adalah sebuah proses yang berbeda, tetapi untuk mengurangi kompleksitas, kontroler-kontroler ini dikompilasi menjadi sebuah binary yang dijalankan sebagai satu proses.
kube-proxy
maintains network rules on nodes. These network rules allow network
communication to your Pods from network sessions inside or outside of
your cluster.
kube-proxy uses the operating system packet filtering layer if there is one
and it’s available. Otherwise, kube-proxy forwards the traffic itself.
Komponen di master yang bertugas mengamati pod yang baru dibuat dan belum di-assign ke suatu node dan kemudian akan memilih sebuah node dimana pod baru tersebut akan dijalankan.
Faktor-faktor yang diperhatikan dalam proses ini adalah kebutuhan resource secara individual dan kolektif, konstrain perangkat keras/perangkat lunak/peraturan, spesifikasi afinitas dan non-afinitas, lokalisasi data, interferensi inter-workload dan deadlines.
Kubernetes resources and “records of intent” are all stored as API objects, and modified via RESTful calls to the API. The API allows configuration to be managed in a declarative way. Users can interact with the Kubernetes API directly, or via tools like kubectl. The core Kubernetes API is flexible and can also be extended to support custom resources.
Application and systems logs can help you understand what is happening inside your cluster. The logs are particularly useful for debugging problems and monitoring cluster activity.
A manifest specifies the desired state of an object that Kubernetes will maintain when you apply the manifest. Each configuration file can contain multiple manifests.
When the kubelet finds a static pod in its configuration, it automatically tries to
create a Pod object on the Kubernetes API server for it. This means that the pod
will be visible on the API server, but cannot be controlled from there.
(For example, removing a mirror pod will not stop the kubelet daemon from running it).
Sebuah objek dengan kind yang sama tidak boleh memiliki nama yang sama pada suatu waktu tertentu. Meskipun begitu, apabila kamu menghapus sebuah objek, kamu membuat sebuah objek baru (yang memiliki kind yang sama) dengan nama yang sama dengan objek yang kamu hapus sebelumnya.
Namespaces are used to organize objects in a cluster and provide a way to divide cluster resources. Names of resources need to be unique within a namespace, but not across namespaces.
Network Policies help you declaratively configure which Pods are allowed to connect to each other, which namespaces are allowed to communicate, and more specifically which port numbers to enforce each policy on. NetworkPolicy resources use labels to select Pods and define rules which specify what traffic is allowed to the selected Pods. Network Policies are implemented by a supported network plugin provided by a network provider. Be aware that creating a network resource without a controller to implement it will have no effect.
You can extend Kubernetes by adding controllers to your cluster, beyond the built-in
controllers that come as part of Kubernetes itself.
If a running application acts as a controller and has API access to carry out tasks
against a custom resource that’s defined in the control plane, that’s an example of
the Operator pattern.
PersistentVolumes (PVs) provide an API that abstracts details of how storage is provided from how it is consumed.
PVs are used directly in scenarios where storage can be created ahead of time (static provisioning).
For scenarios that require on-demand storage (dynamic provisioning), PersistentVolumeClaims (PVCs) are used instead.
Specifies the amount of storage, how the storage will be accessed (read-only, read-write and/or exclusive) and how it is reclaimed (retained, recycled or deleted). Details of the storage itself are described in the PersistentVolume object.
Also known as:PDB A Pod Disruption Budget allows an application owner to create an object for a replicated application, that ensures a certain number or percentage of Pods with an assigned label will not be voluntarily evicted at any point in time. PDBs cannot prevent an involuntary disruption, but will count against the budget. [+]
A Pod Disruption Budget allows an application owner to create an object for a replicated application, that ensures a certain number or percentage of Pods with an assigned label will not be voluntarily evicted at any point in time. PDBs cannot prevent an involuntary disruption, but will count against the budget.
The Pod Lifecycle is defined by the states or phases of a Pod. There are five possible Pod phases: Pending, Running, Succeeded, Failed, and Unknown. A high-level description of the Pod state is summarized in the PodStatusphase field.
Pod Priority gives the ability to set scheduling priority of a Pod to be higher and lower than other Pods — an important feature for production clusters workload.
A cluster-level resource that controls security sensitive aspects of the Pod specification. The PodSecurityPolicy objects define a set of conditions that a Pod must run with in order to be accepted into the system, as well as defaults for the related fields. Pod Security Policy control is implemented as an optional admission controller.
This object chooses the Pods to inject information into using standard selectors. This allows the podspec definitions to be nonspecific, decoupling the podspec from environment specific configuration.
A client interacts with the proxy; the proxy copies the client’s data to the
actual server; the actual server replies to the proxy; the proxy sends the
actual server’s reply to the client.
You can run kube-proxy as a plain userland proxy service. If your operating
system supports it, you can instead run kube-proxy in a hybrid mode that
achieves the same overall effect using less system resources.
QoS Class (Quality of Service Class) provides a way for Kubernetes to classify Pods within the cluster into several classes and make decisions about scheduling and eviction.
QoS Class of a Pod is set at creation time based on its compute resources requests and limits settings. QoS classes are used to make decisions about Pods scheduling and eviction.
Kubernetes can assign one of the following QoS classes to a Pod: Guaranteed, Burstable or BestEffort.
Quantities are representations of small or large numbers using a compact,
whole-number notation with SI suffixes. Fractional numbers are represented
using milli units, while large numbers can be represented using kilo,
mega, or giga units.
For instance, the number 1.5 is represented as 1500m, while the number 1000
can be represented as 1k, and 1000000 as 1M. You can also specify
binary-notation suffixes; the number 2048 can be written as 2Ki.
The accepted decimal (power-of-10) units are m (milli), k (kilo,
intentionally lowercase), M (mega), G (giga), T (tera), P (peta),
E (exa).
The accepted binary (power-of-2) units are Ki (kibi), Mi (mebi), Gi (gibi),
Ti (tebi), Pi (pebi), Ei (exbi).
Will automatically add or remove running instances of a pod, based on a set value for that pod. Allows the pod to return to the defined number of instances if pods are deleted or if too many are started by mistake.
Limits the quantity of objects that can be created in a namespace by type, as well as the total amount of compute resources that may be consumed by resources in that project.
In a securityContext, you can define: the user that processes run as,
the group that processes run as, and privilege settings.
You can also configure security policies (for example: SELinux, AppArmor or seccomp).
The PodSpec.securityContext setting applies to all containers in a Pod.
The set of Pods targeted by a Service is (usually) determined by a selectorAllows users to filter a list of resources based on labels.. If more Pods are added or removed, the set of Pods matching the selector will change. The Service makes sure that network traffic can be directed to the current set of Pods for the workload.
Members within a SIG have a shared interest in advancing a specific area, such as architecture, API machinery, or documentation.
SIGs must follow the SIG governance guidelines, but can have their own contribution policy and channels of communication.
Seperti halnya DeploymentAn API object that manages a replicated application., sebuah StatefulSet akan melakukan proses manajemen Pod yang didasarkan pada spec container identik. Meskipun begitu tidak seperti sebuah Deployment, sebuah StatefulSet akan menjamin identitas setiap Pod yang ada. Pod ini akan dibuat berdasarkan spec yang sama, tetapi tidak dapat digantikan satu sama lainnya: setiap Pod memiliki identifier persisten yang akan di-maintain meskipun pod tersebut di (re)schedule.
Sebuah StatefulSet beroperasi dengan pola yang sama dengan Kontroler lainnya. Kamu dapat mendefinisikan state yang diinginkan pada objek StatefulSet, dan kontroler StatefulSet akan membuat update yang dibutuhkan dari state saat ini.
On Unix-like systems, sysctl is both the name of the tool that administrators
use to view and modify these settings, and also the system call that the tool
uses.
Setiap objek yang ada pada klaster Kubernetes memiliki UID yang unik. Hal ini dilakukan untuk membedakan keberadaan historis suatu entitas dengan kind dan nama yang serupa.
In the Kubernetes Community: Conversations often use upstream to mean the core Kubernetes codebase, which the general ecosystem, other code, or third-party tools rely upon. For example, community members may suggest that a feature is moved upstream so that it is in the core codebase instead of in a plugin or third-party tool.
In GitHub or git: The convention is to refer to a source repo as upstream, whereas the forked repo is considered downstream.
A Kubernetes volume lives as long as the Pod that encloses it. Consequently, a volume outlives any containers that run within the Pod, and data in the volume is preserved across container restarts.
Various core objects that represent different types or parts of a workload
include the DaemonSet, Deployment, Job, ReplicaSet, and StatefulSet objects.