容器、Docker与Kubernetes——Kubernetes的配置入门

Kubernetes的集群管理是通过kubectl命令进行的，如果你使用Google Cloud，则会在SDK中自动安装kubectl命令行工具。虽然你可以完全使用这个命令行工具来配置、控制Kubernetes集群，但是我还是十分推荐你使用单独的配置文件来配置集群，因为你可以使用版本控制工具来追踪每次对集群配置的修改而且保证配置的统一，后面会着重介绍如何去做。

kubectl命令集合包含了非常多的子命令来帮助你控制Kubernetes集群的方方面面，如窥探当前集群的工作状态等等。下面是我觉得非常常用的几个命令，并将其分类说明。

管理类（Management）

kubectl apply -f service-file.yml

kubectl rollout

所有通过apply命令触发的指令都会生成一个新的Rollout（http://t.cn/RKc1xry）对象。通过使用kubectl rollout status命令可以查看最近的更新状态、终止一个rollout或者回滚到上一个资源对象（Deployment，Pod，Service等）的版本。

窥探类（Introspection）

kubectl describe [pod,service,...] [resource]

kubectl logs [resource]

kubectl get [pods,deployments,services,...]

kubectl exec

当前还没有命令能够让一个Deployment自动将配置的Pod下的容器更新到最新的版本；但是为Kubernetes集群更新容器版本又是一个非常常见的操作，这时你就必须想清楚更新容器的步骤了，我列出以下几种方法：

我需要的方案是即能够在Kubernetes中留下更改历史，也不想因为老是去提交配置文件的更改导致陷入版本混乱的泥沼。所以，我个人选择第三种方案，我是这么操作的：

根据以上几点，我可以获得一些好处：

1. 用set image 命令来更新Pods的镜像非常的优雅，因为可以使用kubectl rollout status来跟踪所有Deployment的Pods的更新状态；

   


2. 当Pod因为某些原因被杀掉或者新的Pod上线，都会确保运行拥有最新代码的镜像；

   


3. 我可以在minikube中使用跟Kubernetes集群中相同的docker registry而不用担心会影响到生产环境的Pods；我一直到上线前都不会使用:latest tag的镜像（注：在测试环境或者非生产环境使用git commit hash号来启动容器，但是在生产时使用:latest，因为作者在push镜像时同时打了两个tag）。


搭建本地开发环境

minikube service [service name] --url

minikube dashboard

这会跳转到一个web-based的集群看板页面，帮助你通过可视化的方式了解集群运行的状况。

minikube config set cpus 4
minikube config set memory 8192
minikube start --vm-driver vmwarefusion

kubectl config get-contexts
kubectl config use-context [cluster context name from above] 

当然，如果要重新连接到本地的minikube，只需要使用这条命令：

kubectl config use-context minikube

Service的配置文件支持JSON（http://www.json.org/）与YAML（http://yaml.org/），但是我推荐使用YAML，因为它比较容易读写，而且支持注释，这对那些复杂的结构非常管用。

对于集群的配置，Service往往是最先配置的，这就是所谓的Service-first配置法。具体的做法是，为每个要创建的服务分配一个单独的文件夹，这个文件夹中包含了所有启动这个服务的配置文件。为了搜索方面，我建议为每个Kubernetes的Service资源创建一个yaml配置文件，可以这样命名：[service name]-k8s.yml，这个配置文件中写入所有这个Service在Kubernetes环境启动的配置项。

services/
redis-cache/
        Dockerfile
        redis.conf
        redis-cache-k8s.yml

    
apiVersion: v1
kind: Service
metadata:
name: redis-cache
labels:
role: cache
spec:
type: NodePort
ports:
- port: 6379
targetPort: 6379
selector:
role: cache

---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: redis-cache
spec:
# https://github.com/kubernetes/kubernetes/issues/23597
revisionHistoryLimit: 3
replicas: 1
template:
metadata:
  labels:
    role: cache
spec:
  containers:
  - name: redis
    image: redis:3
    resources:
      requests:
        cpu: 100m
        memory: 1Gi
    ports:
      - containerPort: 6379

然后通过运行apply -f service/redis-cache/redis-cache-k8s.yml 命令就能让redis-cache服务在整个Deployment中跑起来。

如何为容器打Tag

我现在为每个容器都打两个tag分别是：:latest与对应代码git库中的HEAD指针Commit的hash值如：:9c713a。很多人强烈推荐不要使用:latest tag，原因在这里（http://t.cn/RKcrEo2）（注：内容大概讲docker registry并不会主动判断一个镜像是否是最新的，而是可以人为的随意为一个老的镜像打上latest tag的，所以很多人认为latest标签的镜像其实并不一定是最新的），但是我觉得这些都是讲给那些只用latest标签的人听的。我为什么这么做的原因在上面“部署新镜像”一节已经阐述。

确保Minikube能访问GKE的Registry

我早期使用minikube遇到的问题是如何让我的Pod有权限从我的Google私有镜像仓库（https://cloud.google.com/container-registry/）中拉取Docker镜像。当然，当我在GKE中使用Kubernetes集群拉取镜像是没有问题的，因为当使用GKE时，所有的服务器都自动被赋予了访问Google私有镜像仓库的的权限，但是作为本地运行的minikube就没有权限了。

解决方法是在Pod的spec节中使用imagePullSecrets值。首先，登录Google Cloud，然后前往IAM并创建一个新的Service Account 并赋予Storage -> Storage Object Viewer权限，确保勾选“Furnish a new private key”选项，完事后会给你一个JSON文件，这个文件你需要本地保存，是用于授权的；所有这些准备就绪后运行这段脚本生成一个新的Secret资源：

#!/usr/bin/env sh

SPATH="$(cd $(dirname "$0") && pwd -P)"
SECRET_NAME=${1:-docker-registry-secret}
CONFIG_PATH=${2:-$SPATH/localkube.json}
if [[ ! -f $CONFIG_PATH ]]; then
echo "Unable to locate service account config JSON: $CONFIG_PATH";
exit 1;
fi

kubectl create secret docker-registry $SECRET_NAME  \
--docker-server "https://gcr.io" \
--docker-username _json_key \
--docker-email [service account email address] \
--docker-password="`cat $CONFIG_PATH`" ${@:3}

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: redis-cache
spec:
...
template:
spec:
  imagePullSecrets:
  - name: docker-registry-secret
  ...
  containers:
  - name: redis
    image: gcr.io/[google account id]/redis-cache:latest
...

Secrets资源

敏感的数据比如：密码，认证码与各种key，这些都是要做特殊处理并很容易出错的数据。首先，如果将这些数据不加密的保存在代码管理仓库中，不管这个仓库多么机密，并不是一个保险的做法；但同时，你又必须把这些数据加密并保存在某个安全的地方，并使用一个跟踪系统对其做版本记录与权限控制。我使用了很多不同的加密、保存方式，发现StackExchange的BlackBox（https://github.com/StackExchange/blackbox）非常好用。

BlackBox使用PGP/GPG（非对称加密）加密方式对文件进行加密，确保只有特定的用户才能访问加密的文件。对一个用户授权访问某个资源只需这个用户提供自己的GPG公钥，而移除一个用户的授权只需要在一些配置文件中将其名字去掉即可；然后你要做的事就是告诉BlackBox哪些文件需要加密，而其余的工作交给BlackBox即可，被加密的配置文件可以放心的放入git仓库了。

将这些加密的信息提供给Kubernetes需要一些额外的本地脚本，因为Kubernetes将配置信息以明文的方式存储在etcd中。比如：我会对两类文件进行加密：1、YAML配置文件，内部包含很多key-value形式保存的敏感信息（如：数据库密码等）；2、一些公钥文件如：SSL Certificate或者其他秘钥。然后，我使用rake（https://github.com/ruby/rake）来解密这些文件，然后将解密的文件应用到Kubernetes集群中，使用命令：apply -f -（注意：'-'表示STDIN）。

比如，我有个加密的YAML文件，如下：

---
rails:
secret_key_base: "..."
service_api_key: "..."
database:
username: "..."
password: "..."

raw_secrets = `blackbox_cat secrets/my-secrets.yml.gpg`

secrets = YAML.load(raw_secrets)

secrets.each do |name, values|
k8s_secret = {
"apiVersion" => "v1",
"kind" => "Secret",
"type" => "Opaque",
"metadata" => { "name" => name },
"data" => {},
}

values.each do |key, value|
k8s_secret["data"][key] = Base64.strict_encode64(value)
end

stdout, status = Open3.capture2("kubectl apply -f -", stdin_data: k8s_secret.to_yaml)
end 

...
env:
- name: RAILS_SECRET_KEY_BASE
valueFrom:
  secretKeyRef:
    name: rails
    key: secret_key_base
- name: RAILS_SERVICE_API_KEY
valueFrom:
  secretKeyRef:
    name: rails
    key: service_api_key
- name: DATABASE_USERNAME
valueFrom:
  secretKeyRef:
    name: database
    key: username
- name: DATABASE_PASSWORD
valueFrom:
  secretKeyRef:
    name: database
    key: password

原文链接：https://www.collectiveidea.com/blog/archives/2017/04/26/containers-docker-and-kubernetes-part-3