Rony's Blog

K8S基础概念

  • Dec 08, 2021

摘要

K8S基础概念包括：Pod，Replication Controler, Deployment, Service, Ingress, StatefulSet, Job, CornJob, Namespace, ConfigMap, Persistent Volume

Pod

一个Pod（就像一群鲸鱼，或者一个豌豆夹）相当于一个共享context的配置组，在同一个context下，应用可能还会有独立的cgroup隔离机制，一个Pod是一个容器环境下的“逻辑主机”，它可能包含一个或者多个紧密相连的应用，这些应用可能是在同一个物理主机或虚拟机上。
Pod 的context可以理解成多个linux命名空间的联合

  • PID 命名空间（同一个Pod中应用可以看到其它进程）
  • 网络 命名空间（同一个Pod的中的应用对相同的IP地址和端口有权限）
  • IPC 命名空间（同一个Pod中的应用可以通过VPC或者POSIX进行通信）
  • UTS 命名空间（同一个Pod中的应用共享一个主机名称）

Namespace

Namespace是对一组资源和对象的抽象集合，比如可以用来将系统内部的对象划分为不同的项目组或用户组。常见的pods, services, replication controllers和deployments等都是属于某一个namespace的（默认是default），而node, persistentVolumes等则不属于任何namespace。
Namespace常用来隔离不同的用户，比如Kubernetes自带的服务一般运行在kube-system namespace中。

Namespace常用来隔离不同的用户，比如Kubernetes自带的服务一般运行在kube-system namespace中。 命令行：kubectl get namespaces

Workload Resources

Replication Controller

Replication Controller 保证了在所有时间内，都有特定数量的Pod副本正在运行，如果太多了，Replication Controller就杀死几个，如果太少了，Replication Controller会新建几个。

  • 通过RC可以更方便的Scaling，只需要修改replicas的值，就能扩展或缩小pod副本的数量。
  • Rolling updates，当更新一个服务时，可以一个一个的替换pod
  • ReplicaSet是下一代副本控制器，ReplicaSet与Replication Controller之间的唯一区别是新的选择器支持

ReplicateSet

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
  labels:
    app: guestbook
    tier: frontend
spec:
  # modify replicas according to your case
  replicas: 3
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: php-redis
        image: gcr.io/google_samples/gb-frontend:v3

StatefulSets

StatefulSets是管理有状态应用的workload API object，Manages the deployment and scaling of a set of Pods StatefulSet是为了解决有状态服务的问题（对应Deployments和ReplicaSets是为无状态服务而设计），其应用场景包括：

  • 稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现
  • 稳定的网络标志，即Pod重新调度后其PodName和HostName不变，基于Headless Service（即没有Cluster IP的Service）来实现
  • 有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次依次进行（即从0到N-1，在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态），基于init containers来实现
  • 有序收缩，有序删除（即从N-1到0）

Deployment

Deployment为Pods和ReplicaSet提供声明定义（declarative）方法替代RelicationControler，典型应用场景：

  • 定义Deployment来创建Pods和ReplicaSet
  • 滚动升级和回滚应用
  • 扩容和缩容
  • 暂停和继续Deployment

example：创建一个ReplicateSet bring up 3个nginx Pods

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

Service，LB and Networking

Service

Service可以为一组Pods对外暴露抽象的网络服务，并且可以对负载进行负载均衡，负载均衡是通过每个Node上的kube-proxy实现的。 在Service的整个生命周期里，Service的ClusterIP都不会产生变化 Service默认为RoundRobin方式负载均衡，可通过设置service.spec.sessionAffinity=ClusterIP启用SessionAffinity策略

  • 多端口Service：有时容器应用也可能提供多端口服务，在Sevice中可以设置多个端口号，且支持不通的4层协议。
  • Headless Service：Headless Service 不具备特定的ClusterIP，仅通过Label Selector将后端的Pod列表返回给调用的客户端

Ingress

Service的表现形式为IP:Port，即工作在TCP/IP层，而对于基于HTTP的服务来说，不通的URL经常对应不通的后端服务，这些应用层的转发机制无法通过Service机制实现，于是从Kubernetes 1.1版本开始新增了Ingress资源对象，将不通的URL访问转发到后端不通的service，实现HTTP层的业务路由机制。

Storage

Persistent Volumes

Managing storage is a distinct problem from managing compute instances. The PersistentVolume subsystem provides an API for users and administrators that abstracts details of how storage is provided from how it is consumed. To do this, we introduce two new API resources: PersistentVolume and PersistentVolumeClaim.

Configuration

ConfigMaps

A ConfigMap is an API object used to store non-confidential data in key-value pairs. Pods can consume ConfigMaps as environment variables, command-line arguments, or as configuration files in a volume.

A ConfigMap allows you to decouple environment-specific configuration from your container images, so that your applications are easily portable.

Search