tnblog
首页
视频
资源
登录
原

Kubernetes 应用配置管理

5037人阅读 2021/3/9 21:51 总访问：3478571 评论：0 收藏：0 手机
分类: 容器编排

Kubernetes

Kubernetes 应用配置管理

需求来源

背景问题


除了依托容器镜像来定义运行的Container,Pod还需要解决如下问题：

1. 不可变基础设施（容器）的可变配置
2. 敏感信息的存储与使用（如密码、Token等）
3. 集群中Pod自我的身份认证
4. 容器运行的资源配置的管理
6. 容器启动前置条件校验等

在Kubernetes里面，我们可以参考下图来解释它是如何做这些配置管理

ConfigMap

ConfigMap介绍


主要管理容器配置内所需要的配置文件，环境变量，命令行参数等可变配置。用于解耦容器镜像和可变配置，从而保障工作负载（Pod）的可移植性。（简单示例如下）


这是 ConfigMap 本身的一个定义，它包括两个部分：一个是 ConfigMap 元信息，我们关注 name 和 namespace 这两个信息。接下来这个 data 里面，可以看到它管理了两个配置文件。它的结构其实是这样的：从名字看ConfigMap中包含Map单词，Map 其实就是 key:value，key 是一个文件名，value 是这个文件的内容。

ConfigMap创建


创建的命令: kubectl create configmap [NAME][DATA]

其中[DATA]有两个参数：

—from-file 指定目录或者文件
—from-literal 指定键值对

  1. cd /home
  2. echo "{ "name":"k1" }" > myjson1.json
  3. kubectl create configmap kube-myjson-config --from-file=/home/myjson1.json -n default
  4. kubectl get configmap kube-myjson-config -o yaml -n default


创建的命令所生成的ConfigMap如下所示：

  1. apiVersion: v1
  2. data:
  3.   myjson1.json: |
  4.     { name:k1 }
  5. kind: ConfigMap
  6. metadata:
  7.   creationTimestamp: "2021-03-09T06:29:22Z"
  8.   managedFields:
  9.   - apiVersion: v1
  10.     fieldsType: FieldsV1
  11.     fieldsV1:
  12.       f:data:
  13.         .: {}
  14.         f:myjson1.json: {}
  15.     manager: kubectl
  16.     operation: Update
  17.     time: "2021-03-09T06:29:22Z"
  18.   name: kube-myjson-config
  19.   namespace: default
  20.   resourceVersion: "10750078"
  21.   selfLink: /api/v1/namespaces/default/configmaps/kube-myjson-config
  22.   uid: a878eba6-d69d-46d2-ace3-7cbd341534d6


接着我们通过键值对的方式对其进行创建：

  1. kubectl create configmap mykv-configmap --from-literal=bob.foo=foo --from-literal=bob.boo=boo
  2. kubectl get configmap mykv-configmap -o yaml
  1. apiVersion: v1
  2. data:
  3.   bob.boo: boo
  4.   bob.foo: foo
  5. kind: ConfigMap
  6. metadata:
  7.   creationTimestamp: "2021-03-09T07:09:23Z"
  8.   managedFields:
  9.   - apiVersion: v1
  10.     fieldsType: FieldsV1
  11.     fieldsV1:
  12.       f:data:
  13.         .: {}
  14.         f:bob.boo: {}
  15.         f:bob.foo: {}
  16.     manager: kubectl
  17.     operation: Update
  18.     time: "2021-03-09T07:09:23Z"
  19.   name: mykv-configmap
  20.   namespace: rabbitmq-test
  21.   resourceVersion: "10754107"
  22.   selfLink: /api/v1/namespaces/rabbitmq-test/configmaps/mykv-configmap
  23.   uid: 196d0930-d3b2-415a-95ac-b8a3e283f647

ConfigMap使用


ConfigMap主要被Pod使用，一般用于挂载Pod用的配置文件，环境变量，命令行参数等。
(下面代码举例)

  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4.   name: cm-env-test
  5. spec:
  6.   containers:
  7.     - name: test-container
  8.       image: docker.io/busybox
  9.       command: [ "/bin/sh","-c","env" ]
  10.       env:
  11.       # 用mykv-configmap中的bob.foo定义环境变量
  12.       - name: MYKV
  13.         valueFrom:
  14.           configMapKeyRef:
  15.             name: mykv-configmap
  16.             key: bob.foo
  17.   restartPolicy: Never
  1. ### 查看一下日志情况
  2. # kubectl logs pods/cm-env-test
  3. KUBERNETES_SERVICE_PORT=443
  4. KUBERNETES_PORT=tcp://10.43.0.1:443
  5. HOSTNAME=cm-env-test
  6. SHLVL=1
  7. HOME=/root
  8. KUBERNETES_PORT_443_TCP_ADDR=10.43.0.1
  9. PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
  10. KUBERNETES_PORT_443_TCP_PORT=443
  11. KUBERNETES_PORT_443_TCP_PROTO=tcp
  12. KUBERNETES_PORT_443_TCP=tcp://10.43.0.1:443
  13. KUBERNETES_SERVICE_PORT_HTTPS=443
  14. KUBERNETES_SERVICE_HOST=10.43.0.1
  15. PWD=/
  16. MYKV=foo


也可以直接在命令行中使用ConfigMap定义的环境变量，例如我们稍作修改
(大家自己尝试一下啊)

  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4.   name: cm-env-test
  5. spec:
  6.   containers:
  7.     - name: test-container
  8.       image: docker.io/busybox
  9.       command: [ "/bin/sh","-c","echo $(MYKV)" ]
  10.       env:
  11.       - name: MYKV
  12.         valueFrom:
  13.           configMapKeyRef:
  14.             name: mykv-configmap
  15.             key: bob.foo
  16.   restartPolicy: Never


还可以用ConfigMap挂载配置文件

  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4.   name: cm-env-test
  5. spec:
  6.   containers:
  7.     - name: test-container
  8.       image: docker.io/busybox
  9.       command: [ "/bin/sh","-c","ls -al /etc/config" ]
  10.       # ConfigMap中指定的内容以文件形式挂载在容器中的/etc/config目录下
  11.       volumeMounts:
  12.       - name: config-volume
  13.         mountPath: /etc/config
  14.   volumes:
  15.     - name: config-volume
  16.       configMap:
  17.          name: mykv-configmap
  18.   restartPolicy: Never
  1. # kubectl logs pods/cm-env-test
  2. total 12
  3. drwxrwxrwx    3 root     root          4096 Mar  9 08:06 .
  4. drwxr-xr-x    1 root     root          4096 Mar  9 08:07 ..
  5. drwxr-xr-x    2 root     root          4096 Mar  9 08:06 ..2021_03_09_08_06_58.974275824
  6. lrwxrwxrwx    1 root     root            31 Mar  9 08:06 ..data -> ..2021_03_09_08_06_58.974275824
  7. lrwxrwxrwx    1 root     root            14 Mar  9 08:06 bob.boo -> ..data/bob.boo
  8. lrwxrwxrwx    1 root     root            14 Mar  9 08:06 bob.foo -> ..data/bob.foo

不可变更的 ConfigMap


当集群中Pod的状态很多的时候我们想保证ConfigMap只能删除不能修改可以通过ImmutableEphemeralVolumes特性来控制，我们可以通过在Yaml中0级添加immutable: true来进行设定

ConfigMap使用注意点


1. ConfigMap文件大小限制：1MB（ETCD要求）
2. Pod只能引用相同Namespace中的ConfigMap
3. Pod引用的ConfigMap不存在时，Pod无法创建成功。即Pod创建前需要先创建好ConfigMap
4. 使用envFrom从ConfigMap来配置环境变量时，如果ConfigMap中的某些key被认为无效（比如key名称中带有数字），该环境变量将不会注入容器，但是Pod可以正常创建。
5. 只有通过k8s api创建的pod才能使用ConfigMap，其他方式创建的pod（如manifest创建的static pod）不能使用ConfigMap

以往关于ConfigMap的文章

https://www.tnblog.net/hb/article/details/3565

Secret

Secret介绍


Secret是在集群中用于存储密码，token等敏感信息用的资源对象。其中敏感信息采用base-64编码保存，相比存储在明文的ConfigMap中更规范，更安全。


关于 Secret 的类型，它的通过不同的类型应用于不同的场景，下面我将列一下

Secret 的类型
Opaque 用户定义的任意数据
kubernetes.io/service-account-token 服务账号令牌
kubernetes.io/dockercfg ~/.dockercfg 文件的序列化形式
kubernetes.io/dockerconfigjson ~/.docker/config.json 文件的序列化形式
kubernetes.io/basic-auth 用于基本身份认证的凭据
kubernetes.io/ssh-auth 用于 SSH 身份认证的凭据
kubernetes.io/tls 用于 TLS 客户端或者服务器端的数据
bootstrap.kubernetes.io/token 启动引导令牌数据

Secret创建


Secret创建可以是用户自己创建，也有Secret是系统自动创建
- 比如： K8s为每个namespace的默认用户（default ServiceAccount）创建的Secret

手动创建命令：kubectl create secret generic [NAME] [DATA] [TYPE]
其中Data：可以指定文件/键值对
另外TYPE：默认为Opaque

  1. # 创建数据库账号和密码的Secret
  2. kubectl create secret generic mysql-auth --from-literal=username=root --from-literal=password=ikubernetes
  1. # 查看secrets的情况
  2. # kubectl get secrets mysql-auth -o yaml
  3. apiVersion: v1
  4. data:
  5.   password: aWt1YmVybmV0ZXM=
  6.   username: cm9vdA==
  7. kind: Secret
  8. metadata:
  9.   creationTimestamp: "2021-03-10T02:39:38Z"
  10.   managedFields:
  11.   - apiVersion: v1
  12.     fieldsType: FieldsV1
  13.     fieldsV1:
  14.       f:data:
  15.         .: {}
  16.         f:password: {}
  17.         f:username: {}
  18.       f:type: {}
  19.     manager: kubectl
  20.     operation: Update
  21.     time: "2021-03-10T02:39:38Z"
  22.   name: mysql-auth
  23.   namespace: rabbitmq-test
  24.   resourceVersion: "10872072"
  25.   selfLink: /api/v1/namespaces/rabbitmq-test/secrets/mysql-auth
  26.   uid: e71db921-5082-480d-af94-3e8d0037d515
  27. type: Opaque
  29. # 如果想解码可以执行: echo aWt1YmVybmV0ZXM= | base64 -d


Docker 配置 Secret可以使用如下命令

  1. kubectl create secret docker-registry secret-tiger-docker \
  2.   --docker-username=tiger \
  3.   --docker-password=pass113 \
  4.   --docker-email=tiger@acme.com


TLS 配置 Secret可以使用如下命令

  1. kubectl create secret tls my-tls-secret \
  2.   --cert=path/to/cert/file \
  3.   --key=path/to/key/file

Secret使用


Secret 主要被Pod使用，一般通过volume挂载到指定的容器目录，供容器中业务使用。另外在需要访问私有镜像仓库时，也可以引用Secret来实现

使用私有镜像库


私有镜像仓库的信息可以通过Secret存储在集群中，Pod如果需要使用私有镜像仓库，可以通过如下两种方式来配置：
1. Pod.spec.imagePullSecrets来指定secret
2. ServiceAccount中设置imagesPullSecrets，然后自动为使用该SA的Pod注入imagePullSecrets信息

Secret使用的注意点


1. Secret 文件大小限制：1MB
2. Secret虽然采用base-64编码，但是可以简单解码查看原始信息。因此机密信息采用Secret存储仍需要慎重考虑或者Secret访问者进行控制。对Secret加密有较强需求，可以考虑结合Kubernetes + Vault来解决敏感信息的加密和权限管理。
3. Secret最佳实践：因为list/watch方式获取Secret信息。而推荐使用GET来获取需要的Secret,从而减少更多Secret暴露的可能性。

ServiceAccount介绍


ServiceAccount主要用于解决Pod在集群中的身份认证问题。其中认证使用的授权信息，则利用前面讲到Secret（type=kubernetes.io/service-account-token）进行管理

  1. # kubectl get serviceaccount -o yaml
  2. apiVersion: v1
  3. items:
  4. - apiVersion: v1
  5.   kind: ServiceAccount
  6.   metadata:
  7.     creationTimestamp: "2021-02-06T08:45:14Z"
  8.     name: default
  9.     namespace: rabbitmq-test
  10.     resourceVersion: "6264276"
  11.     selfLink: /api/v1/namespaces/rabbitmq-test/serviceaccounts/default
  12.     uid: 67618b0b-2819-402f-bd31-d7dbd8448eaf
  13.   secrets:
  14.   - name: default-token-mf7gv
  15. kind: List
  16. metadata:
  17.   resourceVersion: ""
  18.   selfLink: ""


我们发现每一个AccountService它都有一个用于访问API的Secret对象，它所对应的Secret又包含重要的crt，token，namespace的信息用于访问API的时候确认身份信息，但具体如何确认身份是通过RBAC的方式进行管理的。

  1. # kubectl get secret/default-token-mf7gv -o yaml
  2. apiVersion: v1
  3. data:
  4.   ca.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUJWakNCL3FBREFnRUNBZ0VBTUFvR0NDcUdTTTQ5QkFNQ01DTXhJVEFmQmdOVkJBTU1HR3N6Y3kxelpYSjIKWlhJdFkyRkFNVFl3TkRZek5UWXpOekFlRncweU1ERXhNRFl3TkRBM01UZGFGdzB6TURFeE1EUXdOREEzTVRkYQpNQ014SVRBZkJnTlZCQU1NR0dzemN5MXpaWEoyWlhJdFkyRkFNVFl3TkRZek5UWXpOekJaTUJNR0J5cUdTTTQ5CkFnRUdDQ3FHU000OUF3RUhBMElBQkhqM1QzZWVWNEtkeEx5bHp0V1NUUGVpZDA4blJybzkzOVQvSDZLVW9jcEQKMVZDN2x2elpJSUdqbXl5RFYybWFzY0RtV3JZT1JtVDMyUFJMVnpQbEd1R2pJekFoTUE0R0ExVWREd0VCL3dRRQpBd0lDcERBUEJnTlZIUk1CQWY4RUJUQURBUUgvTUFvR0NDcUdTTTQ5QkFNQ0EwY0FNRVFDSUdxeFF1ZVp1SkZECmU4M3JDVWoyTEYrUnRqWUhhTVR3VkRoVHQ1Y2NhMGRCQWlCM0RiZXNNQ21aNTd5aVBBd1Rhdm5nZXNzV1V6T1EKbTdndE9scTd1TVlOV0E9PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
  5.   namespace: cmFiYml0bXEtdGVzdA==
  6.   token: ZXlKaGJHY2lPaUpTVXpJMU5pSXNJbXRwWkNJNklrMWljVFZ0YjBSQ09FVTFWbUZRUVcxVGJHbFZOemRxY2treWJubGpjamd0Y25JeE9EQlhSVGQ2T0dzaWZRLmV5SnBjM01pT2lKcmRXSmxjbTVsZEdWekwzTmxjblpwWTJWaFkyTnZkVzUwSWl3aWEzVmlaWEp1WlhSbGN5NXBieTl6WlhKMmFXTmxZV05qYjNWdWRDOXVZVzFsYzNCaFkyVWlPaUp5WVdKaWFYUnRjUzEwWlhOMElpd2lhM1ZpWlhKdVpYUmxjeTVwYnk5elpYSjJhV05sWVdOamIzVnVkQzl6WldOeVpYUXVibUZ0WlNJNkltUmxabUYxYkhRdGRHOXJaVzR0YldZM1ozWWlMQ0pyZFdKbGNtNWxkR1Z6TG1sdkwzTmxjblpwWTJWaFkyTnZkVzUwTDNObGNuWnBZMlV0WVdOamIzVnVkQzV1WVcxbElqb2laR1ZtWVhWc2RDSXNJbXQxWW1WeWJtVjBaWE11YVc4dmMyVnlkbWxqWldGalkyOTFiblF2YzJWeWRtbGpaUzFoWTJOdmRXNTBMblZwWkNJNklqWTNOakU0WWpCaUxUSTRNVGt0TkRBeVppMWlaRE14TFdRM1pHSmtPRFEwT0dWaFppSXNJbk4xWWlJNkluTjVjM1JsYlRwelpYSjJhV05sWVdOamIzVnVkRHB5WVdKaWFYUnRjUzEwWlhOME9tUmxabUYxYkhRaWZRLk1mbElISFg1SDVzbjk0cWgxeko1dlpzYThDa09ZTndCVVRPc2xMZUQtM2ZTRlM1cTYtbWhrY2RWRHRNTzdrdVV6QnI3aTRZZEt5QV93UU1fQVhoWDBpcUxXTDdCS21fQjIweDNiYnA0MldMZlVqVmctMndFd0N6cGY0MjBtMXk0VkJ3TTgyajRzbkRLMHdxSWdPUjlaOEpIbHVVZXVMaGd0Z1pIdmNGNl90cVZ3Um1EWFNrdUFWcE91WUNtU21EdzdMTkpGOUZrUHZpUzBmRG9jcnBrNGtyYlZkQnpsUFVTbzBtZ1ZCQ1N6Sks2OVVuUUd3X2E0cmhteWs5eWpGZ0RzSHByNHFrelZsckxXRWNoWU5ITUJlc29CdWRqa2YzTllhX2ZydlIzZ3YxdE1WMkExYmpyS09tUkt5dmNSYl9KY3NZazU3blktbE83cDNOVW82RzlrQQ==
  7. kind: Secret
  8. metadata:
  9.   annotations:
  10.     kubernetes.io/service-account.name: default
  11.     kubernetes.io/service-account.uid: 67618b0b-2819-402f-bd31-d7dbd8448eaf
  12.   creationTimestamp: "2021-02-06T08:45:14Z"
  13.   managedFields:
  14.   - apiVersion: v1
  15.     fieldsType: FieldsV1
  16.     fieldsV1:
  17.       f:data:
  18.         .: {}
  19.         f:ca.crt: {}
  20.         f:namespace: {}
  21.         f:token: {}
  22.       f:metadata:
  23.         f:annotations:
  24.           .: {}
  25.           f:kubernetes.io/service-account.name: {}
  26.           f:kubernetes.io/service-account.uid: {}
  27.       f:type: {}
  28.     manager: k3s
  29.     operation: Update
  30.     time: "2021-02-06T08:45:14Z"
  31.   name: default-token-mf7gv
  32.   namespace: rabbitmq-test
  33.   resourceVersion: "6264275"
  34.   selfLink: /api/v1/namespaces/rabbitmq-test/secrets/default-token-mf7gv
  35.   uid: 01af3784-5106-42aa-874a-a901f8ac3134
  36. type: kubernetes.io/service-account-token


当在Pod中使用指定私有的镜像仓库（imagePullSecret）的时候也可以添加对应的Secret,可以进行CA认证

Resource（容器资源配置管理）

当您指定一个Pod，您可以选择指定每个资源的数量容器需求。指定的最常见资源是CPU和内存（RAM）。

支持资源类型


- CPU: 单位 millicore(1 Core = 1000 millicore)
- Memory: 单位 Byte
- ephemeral storage（临时存储）：单位 Byte
- 自定义资源：配置时必须为整数

配置方法


资源配置分为request/limit两种类型

- CPU
Pod.spec.containers[].resources.limits.cpu
Pod.spec.containers[].resources.requests.cpu

- Memory
Pod.spec.containers[].resources.limits.memory
Pod.spec.containers[].resources.requests.memory

- ephemeral storage(临时存储)
Pod.spec.containers[].resources.limits.ephemeral-storage
Pod.spec.containers[].resources.requests.ephemeral-storage

想了解更多详细的细节可以通过kubectl explain Pod.spec.containers.resources.limits.cpu的方式进行获取信息

举个例子

以下 Pod 有两个 Container。每个 Container 的请求为 0.25 cpu 和 64MiB（226 字节）内存， 每个容器的资源约束为 0.5 cpu 和 128MiB 内存。 你可以认为该 Pod 的资源请求为 0.5 cpu 和 128 MiB 内存，资源限制为 1 cpu 和 256MiB 内存。

  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4.   name: frontend
  5. spec:
  6.   containers:
  7.   - name: app
  8.     image: images.my-company.example/app:v4
  9.     env:
  10.     - name: MYSQL_ROOT_PASSWORD
  11.       value: "password"
  12.     resources:
  13.       requests:
  14.         memory: "64Mi"
  15.         cpu: "250m"
  16.       limits:
  17.         memory: "128Mi"
  18.         cpu: "500m"
  19.   - name: log-aggregator
  20.     image: images.my-company.example/log-aggregator:v6
  21.     resources:
  22.       requests:
  23.         memory: "64Mi"
  24.         cpu: "250m"
  25.       limits:
  26.         memory: "128Mi"
  27.         cpu: "500m"

关于QOS

请参考：https://kubernetes.io/zh/docs/tasks/administer-cluster/out-of-resource/

Security Context

Security Context介绍


安全上下文（Security Context）定义 Pod 或 Container 的特权与访问控制设置。
1. 容器级别的Security Context：仅对指定容器生效
2. Pod级别的Security Context：对指定Pod中的所有容器生效
3. Pod Security Policies（PSP）：对集群内所有的Pod生效

权限和访问控制设置项


1. 自主访问控制（Discretionary Access Control）：基于用户 ID（UID）和组 ID（GID）. 来判定对对象（例如文件）的访问权限。
2. SELinux：通过SELinux的策略配置控制用户，进程等对文件等访问控制。
3. privileged：容器是否为特权模式。
4. Linux Capabilities：给特定进程配置privileged能力
5. AppArmor：控制可执行文件的访问控制权限（读写文件/目录，网络端口读写等）。
6. Seccomp：控制进程可以操作的系统调用。
7. AllowPrivilegeEscalation：控制进程是否可以获得超出其父进程的特权。 此布尔值直接控制是否为容器进程设置 no_new_privs标志。 当容器以特权模式运行或者具有 CAP_SYS_ADMIN 权能时，AllowPrivilegeEscalation 总是为 true。
8. readOnlyRootFilesystem：以只读方式加载容器的根文件系统。

请参考：https://kubernetes.io/zh/docs/tasks/configure-pod-container/security-context/

InitContainer

InitContainer和普通Container的区别


1. InitContainer会先于普通Container启动执行，直到所以InitContainer执行成功后，普通Container才会被启动
2. Pod中多个InitContainer之间是按次序依次启动执行，而Pod中多个普通Container是并行启动
3. InitContainer执行成功后就结束退出了，而普通容器可能会一直执行或者重启（restartPolicy!=Never）

InitContainer用途


基于InitContainer和普通Container的区别，一般InitContainer用于普通Container启动钱的初始化（如配置文件准备）或者普通Container启动的前置条件检验（如网络连通检验）如下图所示：


欢迎加群讨论技术，1群：677373950(满了，可以加，但通过不了)，2群：656732739

评价

阿里云 Kubernetes
https://help.aliyun.com/document_detail/86759.html 可以有三种计费方式https://ecs-buy.aliyun.com/wizard?spm=5176.13...

Kubernetes Job讲解
kubernetes Job讲解[TOC] 需求来源Job 背景问题我们可以通过Pod来直接运行任务进程吗？这样做将会产生以下几种问题：1. 我...

Kubernetes DaemonSet讲解
Kubernetes DaemonSet讲解[TOC] 需求来源背景问题我们可以让每个集群内的节点都运行一个相同的Pod吗？如果这样做，以下的...

Kubernetes Pod中断预算【PDB】
Kubernetes Pod中断预算【PDB】[TOC] 尽管Deployment或ReplicaSet一类的控制器能够确保相应Pod对象的副本数量不断逼近期...

Kubernetes Velero 备份的运用
Velero 的运用[TOC] Velero简介Velero是一个开源工具，可以安全地备份，恢复和迁移Kubernetes集群和持久卷。它既可以在本...

Kubernetes 应用存储和持久化数据卷
Kubernetes 应用配置管理[TOC] Volumes介绍Pod Volumes1. 如果一个Pod中某一个容器异常退出，被kubelet拉起如何保证之前的...

Kubernetes 应用存储和持久化数据卷：存储快照与拓扑调度
Kubernetes 应用存储和持久化数据卷：存储快照与拓扑调度[TOC] 基本知识存储快照产生背景1. 如何保证重要数据在误操作之后...

Kubernetes网络（IPVLAN与MACVLAN）
Kubernetes网络模型[TOC] 三种网络模型 在k8s中一般常见的网络模型支持三种，虚拟网桥、多路复用和硬件交换。 虚拟网...

Kubernetes IP Address
Kubernetes IP Address[TOC] IP AddressIP地址是在计算机网络中被用来唯一标识设备的一组数字。IPv4地址由32位二进制数值...

Dapr 官方教程第二章(Hello World Kubernetes)
Dapr 官方教程第二章(Hello World Kubernetes)[TOC] 本教程将帮助您在 Kubernetes 集群中使用 Dapr。您将从Hello World部...

Kubernetes 搭建RabbitMq集群环境
Kubernetes 搭建RabbitMq集群环境[TOC] 由于Kubectl RabbitMQ 插件在官方是基于krew进行安装的所以我们首先需要安装krew插...

Kubernetes 删除命名空间
Kubernetes 删除命名空间[TOC] 可以直接通过如下命令删除k8s中命名空间下的所有资源。kubectl delete ns [namespace] ...

Kubernetes top之安装metrics-server
Kubernetes top之安装metrics-server[TOC] 一般我们需要知道kubernetes的pod与node的cpu与内存使用情况时，我们可以通过ku...

Kubernetes ExternalName Service
Kubernetes ExternalName Service[TOC] ExternalName 的服务与普通服务的区别在于：将服务映射到 DNS 名称。如下图所示： ...

Kubernetes 自定义Endpoint资源
Kubernetes 自定义Endpoint资源[TOC] 当pod需要服务发布出去的时候中间所关联的还有一个Endpoint这个资源，它能确定服务关...
这一世以无限游戏为使命！
博主信息
排名
2
文章
636
粉丝
44
评论
93
文章类别
最新文章
最新评价
docker中Sware集群与service
尘叶心繁 : 想学呀！我教你呀
一个bug让程序员走上法庭 索赔金额达400亿日元
叼着奶瓶逛酒吧 : 所以说做程序员也要懂点法律知识
.net core 塑形资源
剑轩 : 收藏收藏
映射AutoMapper
剑轩 : 好是好，这个对效率影响大不大哇,效率高不高
ASP.NET Core 服务注册生命周期
剑轩 : http://www.tnblog.net/aojiancc2/article/details/167
关于我们
ICP备案 ：渝ICP备18016597号-1
网站信息：2018-2025TNBLOG.NET
技术交流：群号656732739
联系我们：contact@tnblog.net
公网安备：50010702506256
欢迎加群
欢迎加群交流技术