centos7.5 k 8 s 1を構築する.11.2マルチマスターマルチノードの高可用性クラスタ

20926 ワード

実験環境の説明
じっけんアーキテクチャ図

lab1: etcd master haproxy keepalived 11.11.11.111
lab2: etcd master haproxy keepalived 11.11.11.112
lab3: etcd master haproxy keepalived 11.11.11.113
lab4: node  11.11.11.114
lab5: node  11.11.11.115
lab6: node  11.11.11.116

vip(loadblancer ip): 11.11.11.110

実験で使用したVagrantfile

# -*- mode: ruby -*-
# vi: set ft=ruby :

ENV["LC_ALL"] = "en_US.UTF-8"

Vagrant.configure("2") do |config|
    (1..6).each do |i|
      config.vm.define "lab#{i}" do |node|
        node.vm.box = "centos-7.4-docker-17"
        node.ssh.insert_key = false
        node.vm.hostname = "lab#{i}"
        node.vm.network "private_network", ip: "11.11.11.11#{i}"
        node.vm.provision "shell",
          inline: "echo hello from node #{i}"
        node.vm.provider "virtualbox" do |v|
          v.cpus = 2
          v.customize ["modifyvm", :id, "--name", "lab#{i}", "--memory", "2048"]
        end
      end
    end
end

インストール構成docker
v1.11.0バージョンではdocker v 17の使用を推奨する.03, v1.11,v1.12,v1.13、使用することもできますが、いくらバージョンのdockerでも正常に使用できない可能性があります.テストでは17.09が正常に使用できず、リソース制限(メモリCPU)が使用できないことが判明しました.
すべてのノードで次の操作を行います.
dockerのインストール

#         docker-ce
yum remove -y docker-ce docker-ce-selinux container-selinux
yum install -y --setopt=obsoletes=0 \
docker-ce-17.03.1.ce-1.el7.centos \
docker-ce-selinux-17.03.1.ce-1.el7.centos

dockerの起動

systemctl enable docker && systemctl restart docker

クbeadm、クbelet、クbectlのインストール
すべてのノードで次の操作を行います.
アリミラーを使用したインストール

#    
cat < /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg https://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg
EOF

yum install -y kubelet kubeadm kubectl ipvsadm

システム関連パラメータの設定

#     selinux
#        /etc/sysconfig/selinux    
sed -i 's/SELINUX=permissive/SELINUX=disabled/' /etc/sysconfig/selinux
setenforce 0

#     swap
#        /etc/fstab   swap    
swapoff -a

#   forward
# Docker 1.13               
#    iptables filter  FOWARD 
#      Kubernetes    Node Pod    

iptables -P FORWARD ACCEPT

#         ，       
cat <  /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
vm.swappiness=0
EOF
sysctl --system

#   ipvs      
#       ，      
modprobe ip_vs
modprobe ip_vs_rr
modprobe ip_vs_wrr
modprobe ip_vs_sh
modprobe nf_conntrack_ipv4
lsmod | grep ip_vs

ホスト解析の構成
すべてのノードで次の操作を行います.

cat >>/etc/hosts<

haproxyエージェントとkeepalivedの構成
ノードlab1,lab2,lab3で次のように動作する

#   haproxy  
docker pull haproxy:1.7.8-alpine
mkdir /etc/haproxy
cat >/etc/haproxy/haproxy.cfg<

docker logs my-haproxy

http://11.11.11.111:1080/haproxy-status
http://11.11.11.112:1080/haproxy-status

#   keepalived

docker pull osixia/keepalived:1.4.4

#   
#

lsmod | grep ip_vs
modprobe ip_vs

#   keepalived
# eth1     11.11.11.0/24

docker run --net=host --cap-add=NET_ADMIN \
-e KEEPALIVED_INTERFACE=eth1 \
-e KEEPALIVED_VIRTUAL_IPS="#PYTHON2BASH:['11.11.11.110']" \
-e KEEPALIVED_UNICAST_PEERS="#PYTHON2BASH:['11.11.11.111','11.11.11.112','11.11.11.113']" \
-e KEEPALIVED_PASSWORD=hello \
--name k8s-keepalived \
--restart always \
-d osixia/keepalived:1.4.4

#     
#        backup     master

docker logs k8s-keepalived

#       11.11.11.110        
# ping

ping -c4 11.11.11.110

#         ，

docker rm -f k8s-keepalived
ip a del 11.11.11.110/32 dev eth1

起動クbeletの設定
すべてのノードで次の操作を行います.

#   kubelet    pause  
#   kubelet cgroups
#   docker cgroups
DOCKER_CGROUPS=$(docker info | grep 'Cgroup' | cut -d' ' -f3)
echo $DOCKER_CGROUPS
cat >/etc/sysconfig/kubelet<

systemctl daemon-reload
systemctl enable kubelet && systemctl restart kubelet

マスターの設定
最初のmasterノードの構成lab1ノードで次の操作を行います.

# 1.11    centos     ipvs       
#    https://github.com/kubernetes/kubernetes/issues/65461

#       
CP0_IP="11.11.11.111"
CP0_HOSTNAME="lab1"
cat >kubeadm-master.config<

2番目のmasterノードの構成lab2ノードで次の操作を行います.

# 1.11    centos     ipvs       
#    https://github.com/kubernetes/kubernetes/issues/65461

#       
CP0_IP="11.11.11.111"
CP0_HOSTNAME="lab1"
CP1_IP="11.11.11.112"
CP1_HOSTNAME="lab2"
cat >kubeadm-master.config<

3番目のmasterノードの構成lab3ノードで次の操作を行います.

# 1.11    centos     ipvs       
#    https://github.com/kubernetes/kubernetes/issues/65461

#       
CP0_IP="11.11.11.111"
CP0_HOSTNAME="lab1"
CP1_IP="11.11.11.112"
CP1_HOSTNAME="lab2"
CP2_IP="11.11.11.113"
CP2_HOSTNAME="lab3"
cat >kubeadm-master.config<

構成kubectlの使用
任意のmasterノードで以下のように動作する

rm -rf $HOME/.kube
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

#   node  
kubectl get nodes

#                ，      ready  
#   master      pod，      ，            
#   dashboard, heapster, efk 
kubectl taint nodes --all node-role.kubernetes.io/master-

ネットワークプラグインの使用の構成
任意のmasterノードで以下のように動作する

#     
mkdir flannel && cd flannel
wget https://raw.githubusercontent.com/coreos/flannel/v0.10.0/Documentation/kube-flannel.yml

#     
#    ip      kubeadm pod-network  
  net-conf.json: |
    {
      "Network": "10.244.0.0/16",
      "Backend": {
        "Type": "vxlan"
      }
    }

#     
image: registry.cn-shanghai.aliyuncs.com/gcr-k8s/flannel:v0.10.0-amd64

#   Node       ，  flannel issues 39701，
# https://github.com/kubernetes/kubernetes/issues/39701
#      kube-flannel.yml   --iface               ，
#        dns    。         ，   kube-flannel.yml     ，
# flanneld      --iface=
    containers:
      - name: kube-flannel
        image: registry.cn-shanghai.aliyuncs.com/gcr-k8s/flannel:v0.10.0-amd64
        command:
        - /opt/bin/flanneld
        args:
        - --ip-masq
        - --kube-subnet-mgr
        - --iface=eth1

#   
kubectl apply -f kube-flannel.yml

#   
kubectl get pods --namespace kube-system
kubectl get svc --namespace kube-system

ノードのクラスタへの参加を構成する
すべてのnodeノードで次のように動作します.

#        master        
kubeadm join 11.11.11.110:8443 --token yzb7v7.dy40mhlljt1d48i9 --discovery-token-ca-cert-hash sha256:61ec309e6f942305006e6622dcadedcc64420e361231eff23cb535a183c0e77a

基礎テスト
コンテナ間の通信とDNSのテスト
ネットワークを構成すると、kubeadmはcorednsを自動的に配置します.
次のテストはkubectlを構成するノードで操作できます.
開始

kubectl run nginx --replicas=2 --image=nginx:alpine --port=80
kubectl expose deployment nginx --type=NodePort --name=example-service-nodeport
kubectl expose deployment nginx --name=example-service

ステータスの表示

kubectl get deploy
kubectl get pods
kubectl get svc
kubectl describe svc example-service

DNS解析

kubectl run curl --image=radial/busyboxplus:curl -i --tty
nslookup kubernetes
nslookup example-service
curl example-service

アクセステスト

# 10.96.59.56    svc     clusterip
curl "10.96.59.56:80"

# 32223    svc      nodeport
http://11.11.11.112:32223/
http://11.11.11.113:32223/

削除のクリーンアップ

kubectl delete svc example-service example-service-nodeport
kubectl delete deploy nginx curl

高可用性テスト
いずれかのmasterノードを閉じてクラスタが正常に実行されるかどうかをテストするは、関連情報を表示します.2つのノードを同時に閉じることはできません.3つのノードからなるetcdクラスタは、最大1つのタイミングしかありません.

#       
kubectl get pod --all-namespaces -o wide
kubectl get pod --all-namespaces -o wide | grep lab1
kubectl get pod --all-namespaces -o wide | grep lab2
kubectl get pod --all-namespaces -o wide | grep lab3
kubectl get nodes -o wide
kubectl get deploy
kubectl get pods
kubectl get svc

#     
CURL_POD=$(kubectl get pods | grep curl | grep Running | cut -d ' ' -f1)
kubectl exec -ti $CURL_POD -- sh --tty
nslookup kubernetes
nslookup example-service
curl example-service

テクニック
初期マスターノードを忘れたときのnodeノードにクラスタコマンドを追加するにはどうすればいいですか?

kubeadm token create --print-join-command

token=$(kubeadm token generate)
kubeadm token create $token --print-join-command --ttl=0

Kubernetes Dashboard
Kubernetes Dashboardは、Kubernetesクラスタを管理する全機能Webインタフェースであり、コマンドラインツール(kubectlなど)をUIで完全に代替することを目的としています.
配置
Dashboardはk8s.gcr.io/kubernetes-dashboardのミラーを使用する必要があります.ネットワークの理由で、Tagを事前に引き出して打つか、yamlファイルのミラーアドレスを変更することができます.本稿では後者を使用します.

kubectl apply -f http://mirror.faasx.com/kubernetes/dashboard/master/src/deploy/recommended/kubernetes-dashboard.yaml

上で使用したyamlはhttps://raw.githubusercontent.com/kubernetes/dashboard/master/src/deploy/recommended/kubernetes-dashboard.yamlのk 8 s.gcr.ioをregに置き換える.qiniu.com/k8s.
次に、kubectl get podsコマンドを使用して配置ステータスを表示できます.

kubectl get pods --all-namespaces

dashboardにローカルでアクセスするには、次のコマンドを実行するために安全なチャネルを作成する必要があります.

kubectl proxy

今すぐhttp://localhost:8001/api/v1/namespaces/kube-system/services/http:kubernetes-dashboard:/proxy/Dashborad UIにアクセスしました.
ユーザーの作成
ログインページに移動すると、まずユーザーを作成します.
1.サービスアカウントの作成
まず、admin-userというサービスアカウントを作成し、kube-systemの名前空間の下に置きます.

# admin-user.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: admin-user
  namespace: kube-system

kubectl createコマンドを実行します.

kubectl create -f admin-user.yaml

2.ロールのバインド
デフォルトでは、kubeadmがクラスタを作成するときにadminロールが作成されています.直接バインドすればいいです.

# admin-user-role-binding.yaml
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: admin-user
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: admin-user
  namespace: kube-system

kubectl createコマンドを実行します.

kubectl create -f  admin-user-role-binding.yaml

3.Tokenの取得
dashboardにログインするには、新しく作成されたユーザーのTokenを見つける必要があります.

kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep admin-user | awk '{print $1}')

そしてTokenをログイン画面のToken入力ボックスにコピーし、ログインしてページを表示します.
統合Heapster
Heapsterはコンテナクラスタモニタリングと性能分析ツールであり、KubernetesとCoreOSを天然にサポートしています.
Heapsterは様々なストレージ方式をサポートしています.この例ではinfluxdbを使用して、以下のコマンドを直接実行すればいいです.

kubectl create -f http://mirror.faasx.com/kubernetes/heapster/deploy/kube-config/influxdb/influxdb.yaml
kubectl create -f http://mirror.faasx.com/kubernetes/heapster/deploy/kube-config/influxdb/grafana.yaml
kubectl create -f http://mirror.faasx.com/kubernetes/heapster/deploy/kube-config/influxdb/heapster.yaml
kubectl create -f http://mirror.faasx.com/kubernetes/heapster/deploy/kube-config/rbac/heapster-rbac.yaml

上のコマンドで使用したyamlはhttps://github.com/kubernetes/heapster/tree/master/deploy/kube-config/influxdbコピーし、k8s.gcr.ioを国内ミラーに変更します.

#   yaml   
# heapster.yaml   

####        #####

#   kubelet     https            https   

        - --source=kubernetes:https://kubernetes.default

#   

        - --source=kubernetes:https://kubernetes.default?kubeletHttps=true&kubeletPort=10250&insecure=true

# heapster-rbac.yaml    

####       #####

#  serviceAccount kube-system:heapster   ClusterRole system:kubelet-api-admin   ，  #    kubelet API    ；


kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: heapster
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:heapster
subjects:
- kind: ServiceAccount
  name: heapster
  namespace: kube-system
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: heapster-kubelet-api
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:kubelet-api-admin
subjects:
- kind: ServiceAccount
  name: heapster
  namespace: kube-system

そして、Podの状態を確認します.

kubectl get pods --namespace=kube-system

アクセス
Kubernetesは、次の4つのアクセスサービスを提供します.
kubectl proxy
上記の例では、マシンとKubernetes APIの間にエージェントを作成するkubectl proxyを使用しています.デフォルトでは、ローカルからのみアクセスできます(マシンを起動します).kubectl cluster-infoコマンドを使用して、構成が正しいかどうか、クラスタがアクセスできるかどうかなどを確認できます.

kubectl cluster-info

エージェントを起動するには、次のコマンドを実行します.

kubectl proxy

また、--addressパラメータと--accept-hostsパラメータを使用して、外部アクセスを許可することもできます.

kubectl proxy --address='0.0.0.0'  --accept-hosts='^*$'

その後、Dashboardはhttp://:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/とlocalhostにHTTP接続を使用してアクセスすることを許可し、他のアドレスはHTTPSのみを使用することを許可するため、127.0.0.1にアクセスできますが、ログインできません.したがって、Dashboardへの非ネイティブアクセスが必要な場合は、他のアクセス方法しか選択できません.
NodePort
NodePortはノードを直接外部ネットワークに露出させる方式であり,開発環境,単一ノードの実装方式でのみ使用することを推奨する.
NodePortを有効にするのは簡単で、kubectl editコマンドを実行して編集するだけです.

kubectl -n kube-system edit service kubernetes-dashboard

次に、上記のtype: ClusterIPをtype: NodePortに変更し、保存後、kubectl get serviceコマンドを使用して自動生産ポートを表示します.

kubectl -n kube-system get service kubernetes-dashboard

以上のように、Dashboardは31795ポートに公開されており、https://:31795を外部で使用してアクセスできるようになりました.マルチノードのクラスタでは、MasterノードのIPではなくDashboardノードを実行するIPを見つけてアクセスする必要があることに注意してください.
しかし、最後にページにアクセスできませんでした.
残念ながら、証明書の問題でアクセスできません.Dashboardの導入時に有効な証明書を指定する必要があります.正式な環境では、NodePortを使用してDashboardにアクセスすることは推奨されていないため、Dashboardの証明書の構成方法については、Certificate Managementを参照してください.
API Server
Kubernetes APIサーバが公開されており、外部からアクセスできる場合は、APIサーバを直接使用してアクセスすることも推奨されます.
Dashboardのアクセスアドレスはhttps://:/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/ですが、返される結果は次のようになります.

{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {
    
  },
  "status": "Failure",
  "message": "services \"https:kubernetes-dashboard:\" is forbidden: User \"system:anonymous\" cannot get services/proxy in the namespace \"kube-system\"",
  "reason": "Forbidden",
  "details": {
    "name": "https:kubernetes-dashboard:",
    "kind": "services"
  },
  "code": 403
}

これは、最新版のk 8 sのデフォルトがRBACを有効にし、認証されていないユーザーにデフォルトのアイデンティティを与えたためです:anonymous.
APIサーバでは、証明書を使用して認証されます.証明書を作成する必要があります.
1.まず、kubectlコマンドのプロファイルを見つけます.デフォルトは/etc/kubernetes/admin.confです.前編では、$HOME/.kube/configにコピーしました.
2.次に、client-certificate-dataおよびclient-key-dataを使用してp 12ファイルを生成し、次のコマンドを使用します.

#   client-certificate-data
grep 'client-certificate-data' ~/.kube/config | head -n 1 | awk '{print $2}' | base64 -d >> kubecfg.crt

#   client-key-data
grep 'client-key-data' ~/.kube/config | head -n 1 | awk '{print $2}' | base64 -d >> kubecfg.key

#   p12
openssl pkcs12 -export -clcerts -inkey kubecfg.key -in kubecfg.crt -out kubecfg.p12 -name "kubernetes-client"

3.最後にブラウザの証明書欄に上記で生成したp 12ファイルをインポートし、再度ブラウザを開くとselect a certificateのポップアップボックスが表示されます
[OK]をクリックすると、おなじみのログイン画面が表示されます.

最初に作成したadmin-userユーザーのtokenを使用してログインすることができ、ログイン後にページが表示されます.

kubernetes:canal導入

Kubeletソースコード分析(二):DockerClient