13篇 k8s related articles
Kubernetes中Service Account的作用是什么
Kubernetes中的Service Account是一个用于访问集群API服务器的虚拟帐户，它允许应用程序和服务在没有访问集群证书或令牌的情况下进行认证和授权。Service Account的作用主要包括：
1. 身份验证（Authentication）
Service Account在创建时会自动生成一个私钥和公钥对，私钥存储在Service Account的Secret中，公钥则存储在Service Account的YAML文件中。当一个Pod或服务尝试访问集群API服务器时，它使用Service Account的私钥来生成一个签名（signature），该签名与Service Account的公钥一起发送给集群API服务器。集群API服务器验证签名后，如果签名有效，则允许Pod或服务访问集群API服务器。
Most common short names for Kubernetes resources which was used in command kubectl get:
po or pod: Pods
deploy or deployment: Deployments
svc or service: Services
cm or configmap: ConfigMaps
secret: Secrets
pv or persistentvolume: Persistent Volumes
pvc or persistentvolumeclaim: Persistent Volume Claims
sts or statefulset: StatefulSets
job: Jobs
cronjob: CronJobs
k8s内pod由scheduler调度，scheduler的任务是把pod分配到合适的node节点上。scheduler调度时会考虑到node节点的资源使用情况、port使用情况、volume使用情况等等...在此基础之上，我们也可以控制pod的调度。
service是pod的一个逻辑分组，是pod服务的对外入口抽象。service同样也通过pod的标签来选择pod，与控制器一致。
k8s中所有的内容都抽象成了资源，资源实例化后，称为对象。所有对象可以通过 get delete edit apply进行增删改查。通常分类以下三类资源
namespace为资源提供了集群内的逻辑隔离，需要注意的是，这只是逻辑隔离，不同namespace的pod有可能运行在同一个节点node上。
使用 nginx 的官方容器镜像。
镜像有了，我们如何将其提交给 K8S 运行呢，有两种方式：
这里使用官方推荐的第二种方式，即通过将容器的各种信息写入配置文件提交给 K8S。
找了段解释如下：
Kubernetes Service vs Deployment What's the difference between a
Service and a Deployment in Kubernetes?A deployment is responsible for keeping a set of pods running.
A service is responsible for enabling network access to a set of pods.
We could use a deployment without a service to keep a set of identical
pods running in the Kubernetes cluster. The deployment could be scaled
up and down and pods could be replicated. Each pod could be accessed
individually via direct network requests (rather than abstracting them
behind a service), but keeping track of this for a lot of pods is
difficult.We could also use a service without a deployment. We'd need to create
each pod individually (rather than "all-at-once" like a deployment).
Then our service could route network requests to those pods via
selecting them based on their labels.
直接翻译下就是：
depoyment负责保持一组Pod运行。
service负责启用对一组Pod的网络访问。
我们可以使用没有服务的部署来保持一组相同的Pod在Kubernetes集群中运行。 可以按比例放大和缩小部署，还可以复制Pod。 可以通过直接的网络请求（而不是将它们抽象到服务之后）分别访问每个Pod，但是要跟踪很多Pod很难。
我们也可以在没有部署的情况下使用服务。 我们需要分别创建每个Pod（而不是像部署那样“一次全部”创建）。 然后，我们的服务便可以根据标签的标签选择网络请求，将网络请求路由到这些Pod。
服务和部署是不同的，但是它们可以很好地协同工作。
换个方式理解就是：depoyment就是用容器镜像创的实例， service负责访问这些实例，可以将deployment的端口通过端口暴露给其它服务或外界网络。
in10环境，安装的VMware Workstation Pro，创建了一台Centos7.x的虚拟机。并启用虚拟化。
// v1.16.0版本可以从这里查 https://storage.googleapis.com/kubernetes-release/release/stable.txt
curl -LO https://storage.googleapis.com/kubernetes-release/release/v1.16.0/bin/linux/amd64/kubectl
chmod +x ./kubectl
sudo mv ./kubectl /usr/local/bin/kubectl
kubectl version
上述如果在墙内，需要http代理可以，先将代理设为环境变量 export http_proxy=http://ip:port
也可以从github上下载
https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md#client-binaries-1
找到Current release如 https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.16.md
再找到Client Binaries如v1.16.0下的 https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.16.md#client-binaries
再找到合适的tar包如 https://dl.k8s.io/v1.16.0/kubernetes-client-linux-amd64.tar.gz
wget https://dl.k8s.io/v1.16.0/kubernetes-client-linux-amd64.tar.gz
tar -zxvf kubernetes-client-linux-amd64.tar.gz
cd kubernetes/client/bin
chmod +x ./kubectl
sudo mv ./kubectl /usr/local/bin/kubectl
kubectl version
inikube start时minikube logs中报
Error loading config file "/var/lib/minikube/kubeconfig": open
/var/lib/minikube/kubeconfig: permission denied
解决方法：
sudo setenforce 0
再次执行minikube start即可
注意 这个setenforce重启会失败，需要修改/etc/selinux/config 将SELINUX=enforcing改为 SELINUX=disabled
然后重启即可。