k8s 学习

1、工作负载

Deployment 和 ReplicaSet :
  （替换原来的资源 ReplicationController）。 Deployment 很适合用来管理你的集群上的无状态应用，Deployment 中的所有 Pod 都是相互等价的，并且在需要的时候被替换。
StatefulSet：
   让你能够运行一个或者多个以某种方式跟踪应用状态的 Pod。 例如，如果你的负载会将数据作持久存储，你可以运行一个 StatefulSet，将每个 Pod 与某个 PersistentVolume 对应起来。
   你在 StatefulSet 中各个 Pod 内运行的代码可以将数据复制到同一 StatefulSet 中的其它 Pod 中以提高整体的服务可靠性。
DaemonSet:
   定义提供节点本地支撑设施的 Pod。这些 Pod 可能对于你的集群的运维是非常重要的， 例如作为网络链接的辅助工具或者作为网络插件的一部分等等。 每次你向集群中添加一个新节点时，如果该节点与某 DaemonSet 的规约匹配，
   则控制平面会为该 DaemonSet 调度一个 Pod 到该新节点上运行。
Job 和 CronJob:
   提供不同的方式来定义一些一直运行到结束并停止的任务。 你可以使用 Job 来定义只需要执行一次并且执行后即视为完成的任务。你可以使用 CronJob 来根据某个排期表来多次运行同一个 Job。

2、组织资源配置

一些应用需要创建多个资源，例如 Deployment 和 Service。 将多个资源归入同一个文件（在 YAML 中使用 --- 分隔）可以简化对多个资源的管理。例如：application/nginx-app.yaml

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
  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，这样可以确保调度器能在控制器（如 Deployment）创建 Pod 时对 Service 相关的 Pod 作分布。

kubectl apply -f https://k8s.io/examples/application/nginx-app.yaml

##kubectl 中的批量操作

kubectl delete -f https://k8s.io/examples/application/nginx-app.yaml
kubectl delete deployments/my-nginx services/my-nginx-svc
kubectl delete deployment,services -l app=nginx
kubectl apply -f project/k8s/development --recursive

##无中断更新应用

 kubectl create deployment my-nginx --image=nginx:1.14.2
 kubectl scale --replicas 1 deployments/my-nginx --subresource='scale' --type='merge' -p '{"spec":{"replicas": 1}}'
 kubectl patch --type='merge' -p '{"spec":{"strategy":{"rollingUpdate":{"maxSurge": "100%" }}}}'
 kubectl edit deployment/my-nginx

##更新注解：有时候你想要为资源附加注解。 注解是任意的非标识性元数据，供 API 客户端例如工具或库检索。 这可以通过 kubectl annotate 来完成。

kubectl annotate pods my-nginx-v4-9gw19 description='my frontend running nginx'
kubectl get pods my-nginx-v4-9gw19 -o yaml

## 扩缩应用

kubectl scale deployment/my-nginx --replicas=1
kubectl get pods -l app=my-nginx
kubectl autoscale deployment/my-nginx --min=1 --max=3

##就地更新资源

这个命令会将你推送的配置的版本和之前的版本进行比较，并应用你所作的更改， 而不会覆盖任何你没有指定的属性。
 kubectl apply -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml
也可以使用 kubectl edit 来更新资源
 kubectl edit deployment/my-nginx
 kubectl patch
破坏性更新
 kubectl replace -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml --force

2.定义 Service ：

Kubernetes 中 Service 是 将运行在一个或一组 Pod 上的网络应用程序公开为网络服务的方法
Service API 是 Kubernetes 的组成部分，它是一种抽象，帮助你将 Pod 集合在网络上公开出去。 每个 Service 对象定义端点的一个逻辑集合（通常这些端点就是 Pod）以及如何访问到这些 Pod 的策略

假定有一组 Pod，每个 Pod 都在侦听 TCP 端口 9376，并且它们还被打上 app.kubernetes.io/name=MyApp 标签。你可以定义一个 Service 来发布该 TCP 侦听器:service/simple-service.yaml

apiVersion: v1
  kind: Service
  metadata:
    name: my-service
  spec:
    selector:
      app.kubernetes.io/name: MyApp
    ports:
      - protocol: TCP
        port: 80
        targetPort: 9376

应用上述清单时，系统将创建一个名为 "my-service" 的、 服务类型默认为 ClusterIP 的 Service。 该 Service 指向带有标签 app.kubernetes.io/name: MyApp 的所有 Pod 的 TCP 端口 9376

如果Service 没有选择算符，因此不会自动创建对应的 EndpointSlice 对象。 你可以通过手动添加 EndpointSlice 对象，将 Service 映射到该服务运行位置的网络地址和端口：

apiVersion: v1
  kind: Service
    metadata:
      name: my-service
   spec:
      ports:
        - protocol: TCP
        port: 80
        targetPort: 9376
        
  apiVersion: discovery.k8s.io/v1
  kind: EndpointSlice
    metadata:
      name: my-service-1 # 按惯例将 Service 的名称用作 EndpointSlice 名称的前缀
      labels:
        # 你应设置 "kubernetes.io/service-name" 标签。
        # 设置其值以匹配 Service 的名称
        kubernetes.io/service-name: my-service
    addressType: IPv4
      ports:
        - name: '' # 应与上面定义的 Service 端口的名称匹配
        appProtocol: http
        protocol: TCP
        port: 9376
    endpoints:  # 此列表中的 IP 地址可以按任何顺序显示
      - addresses:
        - "10.4.5.6"
      - addresses:
        - "10.1.2.3"

##Service 类型 

 ClusterIP
    通过集群的内部 IP 公开 Service，选择该值时 Service 只能够在集群内部访问。 这也是你没有为 Service 显式指定 type 时使用的默认值。 你可以使用 Ingress 或者 Gateway API 向公共互联网公开服务。
  NodePort
    通过每个节点上的 IP 和静态端口（NodePort）公开 Service。 为了让 Service 可通过节点端口访问，Kubernetes 会为 Service 配置集群 IP 地址， 相当于你请求了 type: ClusterIP 的 Service。
  LoadBalancer
    使用云平台的负载均衡器向外部公开 Service。Kubernetes 不直接提供负载均衡组件； 你必须提供一个，或者将你的 Kubernetes 集群与某个云平台集成。
  ExternalName
    将服务映射到 externalName 字段的内容（例如，映射到主机名 api.foo.bar.example）。 该映射将集群的 DNS 服务器配置为返回具有该外部主机名值的 CNAME 记录。 集群不会为之创建任何类型代理。