Terminology

We have learned that Kubernetes is an orchestration system to deploy and manage containers. Containers are not managed individually; instead, they are part of a larger object called a Pod. A Pod consists of one or more containers which share an IP address, access to storage and namespace. Typically, one container in a Pod runs an application, while other containers support the primary application.

Kubernetes uses namespaces to keep objects distinct from each other, for resource control and multi-tenant considerations. Some objects are cluster-scoped, others are scoped to one namespace at a time. As the namespace is a segregation of resources, pods would need to leverage services to communicate.

Orchestration is managed through a series of watch-loops, also called controllers or operators. Each controller interrogates the kube-apiserver for a particular object state, then modifying the object until the declared state matches the current state. These controllers are compiled into the kube-controller-manager, but others can be added using custom resource definitions. The default and feature-filled operator for containers is a Deployment. A Deployment does not directly work with pods. Instead it manages ReplicaSets. The ReplicaSet is an operator which will create or terminate pods by sending out a podSpec. The podSpec is sent to the kubelet, which then interacts with the container engine, Docker by default, to spawn or terminate a container until the requested number is running.

The service operator requests existing IP addresses and endpoints and will manage the network connectivity based on labels. These are used to communicate between pods, namespaces, and outside the cluster. There are also Jobs and CronJobs to handle single or recurring tasks, among others.

To easily manage thousands of Pods across hundreds of nodes can be a difficult task. To make management easier, we can use labels, arbitrary strings which become part of the object metadata. These can then be used when checking or changing the state of objects without having to know individual names or UIDs. Nodes can have taints to discourage Pod assignments, unless the Pod has a toleration in its metadata.

There is also space in metadata for annotations which remain with the object but cannot be used by Kubernetes commands. This information could be used by third-party agents or other tools.

Daftar Materi
  • Introduction
  • Container Orchestration?
  • What Is Kubernetes?
  • Components of Kubernetes
  • Challenges
  • Kubernetes Architecture
  • User Community
  • Tools
  • Cloud Native Computing Foundation
  • Kubernetes Architecture
  • Main Components
  • Master Node
  • Worker Nodes
  • Kubelet
  • Services
  • Controllers
  • Pods
  • Containers
  • Init Containers
  • Component Review
  • Node
  • Container to Outside Path
  • Single IP per Pod
  • Networking Setup
  • CNI Network Configuration File
  • Lab 2.1 Lab Environment
  • Kubernetes installation and Configuration
  • Installation Tools
  • Installing kubectl
  • Using Minikube
  • Installing with kubeadm
  • kubeadm-upgrade
  • Installing a Pod Network
  • Installation Considerations
  • Main Deployment Configurations
  • systemd Unit File for Kubernetes
  • Compiling from Source
  • Lab 3.1 Kubernetes Cluster Provisioning
  • Lab 3.2 Deploy Microservices Demo
  • Lab 3.3 Kubernetes Dashboard
  • Quiz 1
  • Kubernetes APIs and Access
  • API Access
  • RESTful
  • Checking Access
  • Using Annotations
  • Simple Pod
  • Manage API Resources with kubectl
  • Access from Outside the Cluster
  • introduction ~/.kube/config
  • Namespaces
  • Working with Namespaces
  • API Resources with kubectl
  • Lab 4.1 API with Proxy & API without Proxy
  • API Objects
  • Overview
  • v1 API Group
  • Discovering API Groups
  • Deploying an Application
  • DaemonSets
  • StatefulSets
  • Autoscaling
  • Jobs
  • RBAC
  • Managing State With Deployments
  • Overview
  • Deployments
  • Object Relationship
  • Deployment Details
  • Deployment Configuration Metadata
  • Deployment Configuration Spec
  • Deployment Configuration Pod Template
  • Deployment Configuration Status
  • Scaling and Rolling Updates
  • Deployment Rollbacks
  • Using DaemonSets
  • Labels
  • Volumes and Data
  • Introducing Volumes
  • Volume Spec
  • Volume Types
  • Shared Volume Example
  • Persistent Volumes and Claims
  • Persistent Volume
  • Persistent Volume Claim
  • Dynamic Provisioning
  • Secrets
  • Using Secrets via Environment Variables
  • Mounting Secrets as Volumes
  • Tugas 6.1 PV & PVC
  • Tugas 6.2 Multi-Tier Application
  • Kubernetes Service
  • Accessing an Application with a Service
  • Service Types : Cluster IP
  • Service Types : Load Balancer
  • Services Diagram
  • Local Proxy for Development
  • DNS
  • Verifying DNS Registration
  • Tugas 7.1 Deploying Stand-Alone Application
  • Quiz 2
  • Ingress
  • Ingress Controller
  • Ingress API Resources
  • Deploying the Ingress Controller
  • Creating an Ingress Rule
  • Multiple Rules
  • Tugas 8.1 Ingress
  • Quiz 3
  • Scheduling
  • kube-scheduler
  • Predicates
  • Priorities
  • Scheduling Policies
  • Pod Specification
  • Specifying the Node Label
  • Pod Affinity Rules
  • podAffinity Example
  • podAntiAffinity Example
  • Node Affinity Rules
  • Node Affinity Example
  • Taints
  • Tolerations
  • Custom Scheduler
  • Helm
  • Deploying Complex Applications
  • Helm v2 and Tiller
  • Helm v3
  • Chart Contents
  • Templates
  • Initializing Helm v2
  • Chart Repositories
  • Deploying a Chart
  • Comprehensive
  • Summary
  • Lab Test Comprehensive 1
  • Lab Test Comprehensive 2