Kubernetes简要入门教程

还提到了Kubernetes的动态性，以及与Rolling Updates、Self-Healing、Service Discovery、Load Balancing、Ingress、ConfigMaps和Secrets Management相关的内容。

最后指出了Kubernetes管理复杂性，以及使用IDE和其他工具来简化Kubernetes文件管理的重要性。

要点：

• Kubernetes是一个用于管理大规模容器部署的工具，适用于需要运行数百甚至数千个容器的情况。
• Kubernetes通过节点（Nodes）、Pods和控制平面（Control Plane）来管理容器部署和运行，并支持集群和多云部署。
• 使用YAML文件描述所需的集群状态，并结合kubectl工具将其提交给Kubernetes API服务器，实现对集群状态的管理和控制。

基础概念
1、pod 与节点
Kubernetes 有一个所谓的调度器（Scheduler）。每当调度器发现要调度的新 pod（==容器），它就会尝试为 pod 找到最佳节点。这意味着很可能出现多个 pod 运行在同一节点或不同节点上的情况。

2、控制平面
认识一下控制平面。为了简单起见，让我们把它看作是控制节点的一个组件（而不是由大约 9472 个组件组成）。控制平面有很多功能...
让您对应用程序进行运行调度，即让您将 pod 放在节点上。
检查所有 pod 是否都处于所需的状态，例如，它们是否响应，或者其中是否有一个需要重启？
满足每个工程师的幻想："我们终于需要扩展 10 倍了，让我们快速启动 n 个更多的 pod 吧！"

在哪里可以获得 kubectl？
您可以在这里下载，kubectl它本质上是一个CLI 工具，可以完成您想要对 Kubernetes 集群执行的所有操作。该页面列出了为您的特定操作系统安装 kubectl 的各种方法。

kubectl 被发音为“Kube Control”。

kubectl 需要什么才能工作？
您需要一个配置文件，即所谓的kubeconfig file，它可以让您访问 Kubernetes 集群。
默认情况下，该文件位于~/.kube/config.还需要注意的是，您最喜欢的 IDE（例如IntelliJ IDEA）也会读取此配置文件，以正确设置其 Kubernetes 功能。

从哪里获取 kubeconfig 文件？

• 选项 1：如果您使用托管 Kubernetes 安装（EKS、GKE、AKS），请查看相应的文档页面。是的，只需单击链接，我就完成了链接到正确页面的所有工作。简而言之，您将使用他们的 CLI 工具为您生成/下载文件。
• 选项 2：如果您在本地安装了Minikube，它会自动为您创建一个 kubeconfig 文件。
• 选项 3：如果您碰巧知道您的 Kubernetes 主节点并且可以通过 ssh 访问它，请运行：cat /etc/kubernetes/admin.conf或猫~/.kube/config

关于 kubeconfig 文件我还需要了解什么吗？
kubeconfig 文件由良好的旧 YAML 组成，它可以包含很多内容（集群、用户、上下文）。
现在，我们可以忽略用户和上下文，并接受 kubeconfig 文件包含您可以连接到的集群的简化，例如development或test。

apiVersion: v1
clusters:
- cluster:
    certificate-authority: fake-ca-file
    server: https://1.2.3.4
  name: development
- cluster:
    insecure-skip-tls-verify: true
    server: https://5.6.7.8
  name: test
contexts:
- context:
    cluster: development
    namespace: frontend
    user: developer
  name: dev-frontend
- context:
    cluster: development
    namespace: storage
    user: developer
  name: dev-storage
- context:
    cluster: test
    namespace: default
    user: experimenter
  name: exp-test
current-context: ""
kind: Config
preferences: {}
users:
- name: developer
  user:
    client-certificate: fake-cert-file
    client-key: fake-key-file
- name: experimenter
  user:
    # Documentation note (this comment is NOT part of the command output).
    # Storing passwords in Kubernetes client config is risky.
    # A better alternative would be to use a credential plugin
    # and store the credentials separately.
    # See https://kubernetes.io/docs/reference/access-authn-authz/authentication/#client-go-credential-plugins
    password: some-password
    username: exp

 Kubectl 做什么?
一开始我们说过您的目标是拥有一个 pod（n+ 个容器），并将其调度（运行它们）在节点（服务器）上。
方法是将具有集群所需状态的 yaml 文件 (yay) 馈送到 kubectl 中，它会很乐意将集群设置为所需状态。

Pod 清单
例如，您可以创建一个名为的文件marcocodes-pod.yaml，如下所示...

apiVersion: v1
kind: Pod
metadata:
  name: marcocodes-web
spec:
  containers:
    - image: gcr.io/marco/marcocodes:1.4
      name: marcocodes-web
      ports:
        - containerPort: 8080
          name: http
          protocol: TCP

…​并使用以下 kubectl 命令将其输入到您的 Kubernetes 集群中：

 kubectl apply -f marcocodes-pod.yaml

在本例中：

我们为 pod 赋予name值为marcocodes_web。
这个元数据有什么用？
简而言之，Kubernetes 需要以某种方式唯一地标识集群中的资源：我是否已经有一个marcocodes_web正在运行的同名 pod，还是必须启动一个新的 pod？这就是元数据的用途。

您需要告诉 Kubernetes您的 pod 应该是什么样子。请记住，它可以是 n+ 个容器，因此您可以在 YAML 文件中指定容器列表，即使您通常只指定一个容器。

您将指定一个特定的 Docker 镜像，包括其版本，并通过 http 公开该容器上的端口 8080。

这个 yaml 文件到底发生了什么？
当您运行 时kubectl apply，您的 yaml 文件将被提交到Kubernetes API 服务器，最终我们的 Kubernetes 系统将安排一个 pod（带有 marcocodes 1.4 容器）在集群中健康、可行的节点上运行。

从技术上讲，Kubernetes 有一个 "调和循环"（conciliation loop）的概念：

"这里是我当前的 Kubernetes 集群状态，这里是用户的 yaml 文件，让我来调和这两个文件。用户想要一个新 pod？我来创建。用户想要存储空间？我会把它附加到容器上，等等。

资源和数量
您能做的不仅仅是指定容器映像。首先，您可能需要注意容器的资源消耗：

# ....
spec:
  containers:
    - image: gcr.io/marco/marcocodes:1.4
      resources:
        requests:
          cpu: "500m"
          memory: "128Mi"
# ....

这可确保您的容器至少获得 500m（又名 0,5）的 CPU 和 128 MB 的内存。

此外，当 Pod 被删除或容器简单重启时，容器文件系统中的数据也会被删除。为了避免这种情况，您可能希望将数据存储在persistent volume.

# ....
spec:
  volumes:
    - name: "marcocodes-data"
      hostPath:
        path: "/var/lib/marcocodes"
  containers:
    - image: gcr.io/marco/marcocodes:1.4
      name: marcocodes
      volumeMounts:
        - mountPath: "/data"
          name: "marcocodes-data"
      ports:
        - containerPort: 8080
          name: http
          protocol: TCP
# ....

Kubernetes 的ReplicaSets
如果能够拥有应用程序的冗余实例和一些负载平衡，这样我们的部署就更加专业.

让我们看一下marcocodes-replica.yaml定义这样一个最小 ReplicaSet 的文件。

apiVersion: apps/v1
kind: ReplicaSet
# metadata:
# ...
spec:
  replicas: 2
  selector: "you will learn this later"
  # ...
  template:
    metadata: "you will learn this later"
      # ...
    spec:
      containers:
        - name: marcocodes-web
          image: "gcr.io/marco/marcocodes:3.85"

这个 .yaml 现在描述的是  ReplicaSet，不再是 Pod。

重点是：我们希望在任何给定时间都有 2 个副本 == pod 运行。如果我们在这里输入 10 个，Kubernetes 将确保有 10 个 Pod 同时运行。

spec:
  replicas: 2

当我们现在应用这个 .yaml 文件时......​。

kubectl apply -f marcocodes-rs.yaml

ReplicaSets几乎是您想要的，但它们有一个问题：它们与容器镜像的特定版本（在我们上面的例子中为 3.85）相关联，并且实际上预计不会改变。而且 ReplicaSet 也无法帮助您完成软件的部署过程（想想，零停机时间）。

因此我们需要一个新的概念来帮助我们管理新版本的发布。

部署
注意：使用kind: Deployment

apiVersion: apps/v1
kind: Deployment
metadata: "ignore for now"
  # ...
spec:
  progressDeadlineSeconds: 600
  replicas: 2
  revisionHistoryLimit: 10
  selector: "ignore for now"
    # ...
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
     "ignore for now"
    # ...

您还需要学习 92387 个 YAML 键值对来进行部署。要点是：Kubernetes 允许您拥有不同的软件部署策略（rollingUpdate或recreate）。

• recreate：重新创建将杀死旧版本的所有 pod，并使用新版本重新创建它们：您的用户将经历停机
• RollingUpdate：将执行更新，同时仍然通过旧 Pod 提供流量，因此通常是首选。

K8s 的静态特性
请注意，到目前为止您所看到的一切本质上都是静态的。您有 YAML 文件，即使使用上面的Deployment对象，如果您有新版本的容器，您也需要编辑 .yaml 文件，保存并应用它 - 这涉及大量的手动工作。
如果您希望事情变得更加动态，您将需要其他工具，例如https://helm.sh/，