Jonathanliu92251.github.io

study memo

Project maintained by Jonathanliu92251 Hosted on GitHub Pages — Theme by mattgraham

LinuxFoundationX: LFS158x
Introduction to Kubernetes

Table of Contents
Chapter 1. Container Orchestration
Chapter 2. Kubernetes
Chapter 3. Kubernetes Architecture - Overview
Chapter 4. Installing Kubernetes
Chapter 5. Setting Up a Single-Node Kubernetes Cluster with Minikube
Chapter 6. Accessing Minikube
Chapter 7. Kubernetes Building Blocks
Chapter 8. Authentication, Authorization, Admission Control
Chapter 9. Services
Chapter 10. Deploying a Stand-Alone Application
Chapter 11. Kubernetes Volume Management
Chapter 12. Deploying a Multi-Tier Application
Chapter 13. ConfigMaps and Secrets
Chapter 14. Ingress
Chapter 15. Advanced Topics - Overview
Chapter 16. Kubernetes Community

Chapter 1. Container Orchestration

Objectives:

1. What Are Containers?
an application-centric way to deliver high-performing, scalable applications on the infrastructure of your choice.
With a container image, we bundle the application along with its runtime and dependencies. We use that image to create an isolated executable environment, also known as container. We can deploy containers from a given image on the platform of our choice, such as desktops, VMs, cloud, etc.

2. What Is Container Orchestration?
Container orchestrators are the tools which group hosts together to form a cluster, and help us fulfill the requirements:

Nowadays, there are many container orchestrators available, such as:

Container orchestrators can make things easy for operators:

Chapter 2. Kubernetes

Objectives:

  1. Define Kubernetes.
  2. Explain the reasons for using Kubernetes.
  3. Discuss the features of Kubernetes.
  4. Discuss the evolution of Kubernetes from Borg.
  5. Explain what the Cloud Native Computing Foundation does.

1. Background

2. Kubernetes features

Chapter 3. Kubernetes Architecture - Overview

Objectives:

  1. Discuss the Kubernetes architecture.
  2. Explain the different components for master and worker nodes.
  3. Discuss about cluster state management with etcd.
  4. Review the Kubernetes network setup requirements.

#Chapter 4. Installing Kubernetes Objectives:

  1. Discuss about the different Kubernetes configuration options.
  2. Discuss infrastructure considerations before installing Kubernetes.
  3. Discuss infrastructure choices for a Kubernetes deployment.
  4. Review Kubernetes installation tools and resources.

1. Installation

Chapter 5. Setting Up a Single-Node Kubernetes Cluster with Minikube

Objectives:

  1. Discuss Minikube.
  2. Install Minikube on Linux, Mac, and Windows.
  3. Verify the installation.

Chapter 6. Accessing Minikube

Objectives:

  1. Review methods to access any Kubernetes cluster.
  2. Configure kubectl for Linux, macOS, and Windows.
  3. Access the Minikube dashboard.
  4. Access Minikube via APIs.

Chapter 7. Kubernetes Building Blocks

Objectives:

  1. Review the Kubernetes object model.
  2. Discuss Kubernetes building blocks, e.g. Pods, ReplicaSets, Deployments, Namespaces.
  3. Discuss Labels and Selectors.

1. Pod

2. Label

3. ReplicationController

4. ReplicaSet

5. Deployment

6. Namespaces

Chapter 8. Authentication, Authorization, Admission Control

Objectives:

  1. Discuss authentication, authorization, and access control stages of the Kubernetes API access.
  2. Understand the different kinds of Kubernetes users.
  3. Explore the different modules for authentication and authorization.

1. Concepts

2. Kubernetes Users

  1. Normal Users.
    They are managed outside of the Kubernetes cluster via independent services like User/Client Certificates, a file listing usernames/passwords, Google accounts, etc.
  2. Service Accounts.
    With Service Account users, in-cluster processes communicate with the API server to perform different operations. Most of the Service Account users are created automatically via the API server, but they can also be created manually. The Service Account users are tied to a given Namespace and mount the respective credentials to communicate with the API server as Secrets.
  3. Anonymous.
    If properly configured, Kubernetes can also support anonymous requests, along with requests from Normal Users and Service Accounts.

3. Authentication Methods

  1. Client Certificates.
    To enable client certificate authentication, we need to reference a file containing one or more certificate authorities by passing the –client-ca-file=SOMEFILE option to the API server. The certificate authorities mentioned in the file would validate the client certificates presented to the API server. A demonstration video covering this topic is also available at the end of this chapter.
  2. Static Token File.
    We can pass a file containing pre-defined bearer tokens with the –token-auth-file=SOMEFILE option to the API server. Currently, these tokens would last indefinitely, and they cannot be changed without restarting the API server.
  3. Bootstrap Tokens.
    This feature is currently in an alpha status, and is mostly used for bootstrapping a new Kubernetes cluster.
  4. Static Password File.
    It is similar to Static Token File. We can pass a file containing basic authentication details with the –basic-auth-file=SOMEFILE option. These credentials would last indefinitely, and passwords cannot be changed without restarting the API server.
  5. Service Account Tokens.
    This is an automatically enabled authenticator that uses signed bearer tokens to verify the requests. These tokens get attached to Pods using the ServiceAccount Admission Controller, which allows in-cluster processes to talk to the API server.
  6. OpenID Connect Tokens.
    OpenID Connect helps us connect with OAuth 2 providers, such as Azure Active Directory, Salesforce, Google, etc., to offload the authentication to external services.
  7. Webhook Token Authentication.
    With Webhook-based authentication, verification of bearer tokens can be offloaded to a remote service.
  8. Keystone Password.
    Keystone authentication can be enabled by passing the –experimental-keystone-url= option to the API server, where AuthURL is the Keystone server endpoint.
  9. Authenticating Proxy.
    If we want to program additional authentication logic, we can use an authenticating proxy.

Chapter 9. Services

Objectives:

  1. Discuss the benefits of grouping Pods into Services to access an application.
  2. Explain the role of the kube-proxy daemon running on each worker node.
  3. Explore the Service discovery options available in Kubernetes.
  4. Discuss different Service types.

1. Service
p{ white-space:pre-wrap;} Kubernetes provides a higher-level abstraction called Service, which logically groups Pods and a policy to access them. This grouping is achieved via Labels and Selectors, which we talked about in the previous chapter. Grouping of Pods using Labels and Selectors 2. kube-proxy
All of the worker nodes run a daemon called kube-proxy, which watches the API server on the master node for the addition and removal of Services and endpoints. For each new Service, on each node, kube-proxy configures the iptables rules to capture the traffic for its ClusterIP and forwards it to one of the endpoints. When the service is removed, kube-proxy removes the iptables rules on all nodes as well. kube-proxy, Services, and Endpoints

3. Service Discovery

4. ServiceType

  1. ClusterIP
    is the default ServiceType. A Service gets its Virtual IP address using the ClusterIP.
  2. NodePort
    in addition to creating a ClusterIP, a port from the range 30000-32767 is mapped to the respective Service, from all the worker nodes. The end-user connects to the worker nodes on the specified port, which forwards the traffic to the applications running inside the cluster.
  3. LoadBalancer （specific vendor support)
    • NodePort and ClusterIP Services are automatically created, and the external load balancer will route to them
    • The Services are exposed at a static port on each worker node
    • The Service is exposed externally using the underlying cloud provider’s load balancer feature.
  4. ExternalIP （specific vendor support) Traffic that is ingressed into the cluster with the ExternalIP (as destination IP) on the Service port, gets routed to one of the the Service endpoints.
  5. ExternalName （specific vendor support)
    configured Services like my-database.example.com available inside the cluster, using just the name, like my-database, to other Services inside the same Namespace.

Chapter 10. Deploying a Stand-Alone Application

Objectives:

  1. Deploy an application from the dashboard.
  2. Deploy an application from a YAML file using kubectl.
  3. Expose a service using NodePort.
  4. Access the application from the external world.

1. Deploy Application

  1. Deploying an Application Using the Minikube GUI

  2. Deploying the Application Using the CLI

Step 1. Create a YAML file with Deployment details

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webserver
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:alpine
        ports:
        - containerPort: 80

Step 2. Creating a Service and Exposing It to the External World with NodePort

Step 3. Create a webserver-svc.yaml file with the following content:

apiVersion: v1
kind: Service
metadata:
  name: web-service
  labels:
    run: web-service
spec:
  type: NodePort
  ports:
  - port: 80
    protocol: TCP
  selector:
    app: nginx

** 2. Liveness and Readiness Probes **

Liveness probe checks on an application’s health, and, if for some reason, the health check fails, it restarts the affected container automatically.
Sometimes, applications have to meet certain conditions before they can serve traffic. These conditions include ensuring that the depending service is ready, or acknowledging that a large dataset needs to be loaded, etc. In such cases, we use Readiness Probes and wait for a certain condition to occur. Only then, the application can serve traffic.

Chapter 11. Kubernetes Volume Management

Objectives:

  1. Explain the need for persistent data management.
  2. Discuss Kubernetes Volume and its types.
  3. Discuss PersistentVolumes and PersistentVolumeClaims.

1. Volume Types

2. PersistentVolumes
A Persistent Volume is a network-attached storage in the cluster, which is provisioned by the administrator.
PersistentVolumes can be dynamically provisioned based on the StorageClass resource. A StorageClass contains pre-defined provisioners and parameters to create a PersistentVolume. Using PersistentVolumeClaims, a user sends the request for dynamic PV creation, which gets wired to the StorageClass resource. PersistentVolume

3. PersistentVolumeClaims
A PersistentVolumeClaim (PVC) is a request for storage by a user. Users request for PersistentVolume resources based on size, access modes, etc. Once a suitable PersistentVolume is found, it is bound to a PersistentVolumeClaim. PersistentVolumeClaim Used In a Pod Once a user finishes its work, the attached PersistentVolumes can be released. The underlying PersistentVolumes can then be reclaimed and recycled for future usage.

4. Container Storage Interface (CSI)
third-party storage providers can develop solutions without the need to add them into the core Kubernetes codebase.

Chapter 12. Deploying a Multi-Tier Application

Objectives:

  1. Analyze a sample multi-tier application.
  2. Deploy a multi-tier application.
  3. Scale an application.

# Chapter 13. ConfigMaps and Secrets Objectives:

  1. Discuss configuration management for applications in Kubernetes using ConfigMaps.
  2. Share sensitive data (such as passwords) using Secrets.

1. ConfigMaps
ConfigMap, pass such runtime parameters like configuration details. Secret, when we want to pass sensitive information. Decouple the configuration details from the container image. Using ConfigMaps, we can pass configuration details as key-value pairs, which can be later consumed by Pods, or any other system components, such as controllers.
A ConfigMap can be created with the kubectl create command, and we can get the values using the kubectl get command.

$ kubectl create configmap my-config --from-literal=key1=value1 --from-literal=key2=value2
$ kubectl get configmaps my-config -o yaml

As a Volume We can mount a ConfigMap as a Volume inside a Pod. For each key, we will see a file in the mount path and the content of that file becomes the respective key’s value

2. Secrets
we can share sensitive information like passwords, tokens, or keys in the form of key-value pairs, similar to ConfigMaps; In Deployments or other system components, the Secret object is referenced, without exposing its content. the Secret data is stored as plain text inside etcd.

$ kubectl create secret generic my-password --from-literal=password=mysqlpassword  
$ kubectl get secret my-password
$ kubectl describe secret my-password

Chapter 14. Ingress

Objectives:

  1. Explain what Ingress and Ingress Controllers are.
  2. Learn when to use Ingress.
  3. Access an application from the external world using Ingress.

1. Concepts
“An Ingress is a collection of rules that allow inbound connections to reach the cluster Services.”
Ingress configures a Layer 7 HTTP load balancer for Services and provides the following:

2. Example
An Ingress Controller is an application which watches the Master Node’s API server for changes in the Ingress resources and updates the Layer 7 Load Balancer accordingly.

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: web-ingress
  namespace: default
spec:
  rules:
  - host: blue.example.com
    http:
      paths:
      - backend:
          serviceName: webserver-blue-svc
          servicePort: 80
  - host: green.example.com
    http:
      paths:
      - backend:
          serviceName: webserver-green-svc
          servicePort: 80
          
$ kubectl create -f webserver-ingress.yaml   
$ cat /etc/hosts
127.0.0.1        localhost
::1              localhost
192.168.99.100   blue.example.com green.example.com

Ingress URL Mapping

# Chapter 15. Advanced Topics 1. Annotations
In contrast to Labels, annotations are not used to identify and select objects. With Annotations, we can attach arbitrary non-identifying metadata to any objects, in a key-value format:Annotations can be used to:

2. Deployment Features

3. Jobs
Such as cron jobs. A Job creates one or more Pods to perform a given task. The Job object takes the responsibility of Pod failures. It makes sure that the given task is completed successfully. Once the task is over, all the Pods are terminated automatically.

4. Quota Management
quotas per Namespace

5. DaemonSets
6. StatefulSets
7. Kubernetes Federation
8. Custom Resources
9. Helm

10. Monitoring and Logging

Chapter 16. Kubernetes Community

Kubernetes 常用命令

命令 | 解释 —-|—– Kubernetes命令行 – 集群状态 | kubectl cluster-info | 查看集群信息 kubectl version | 显示kubectl命令行及kube服务端的版本 kubectl api-version | 显示支持的API版本集合 kubectl config view | 显示当前kubectl配置 kubectl get no | 查看集群中节点 Kubernetes命令行 – 创建新资源 | kubectl create -f | 按照yaml文件创建资源 kubectl run --image= | 使用某镜像创建Deployment Kubernetes命令行 – 检查与调试 | kubectl get | 查看某种类型资源 kubectl describe | 检查某特定资源实例 kubectl logs | 检查某POD的日志(标准输出) kubectl exec | 在容器内执行命令 Kubernetes命令行 – 部署管理 | kubectl scale | 实现水平扩展或收缩 kubectl rollout status | 部署状态变更状态检查 kubectl rollout history | 部署的历史 kubectl rollout undo | 回滚部署到最近或者某个版本 Kubernetes命令行 – 删除资源 | kubectl delete |