クラウドコンピューティングへのI.はじめに
1、仮想化技術やクラウドコンピューティングのリンク
クラウドコンピューティングのコンセプト：
- クラウドコンピューティングは、最終的にテナントがそれらのリソースをリースすることを可能にするリソース・プールと動的資源プールの概念は無制限の拡張、ボリュームの減少、およびできることが強調され、ネットワーク、ストレージ、ハードウェア、ソフトウェア、統合技術です。
- クラウドコンピューティングは、リソースプールを適用するために、リソースプールは、クラウドプラットフォームと呼ばれるプラットフォームを提供し、彼らのニーズに応じてテナント、テナントにサービスを提供するために、最終的です。
仮想化の概念：
- 論理リソースへの物理リソースへの仮想化技術は、サービスを仮想的に仮想マシンで実行されているのではなく、物理リソース上で直接実行され、その結果、物理的障壁のリソース構造を壊すために管理することができます。
連絡先：仮想化技術は、クラウド内のモジュールであり、不可欠なモジュールです。申し出に、リソースプーリングの多種多様なクラウドコンピューティング、仮想化技術は、仮想マシンにリソースプールにこれらの資源の合理的な配分です。その後、テナントが異なる構成で異なる価格でレンタルされた個々の中小企業への販売のための仮想マシンを置きます。
図2に示すように、クラウドコンピューティングの分類
（1）サービスタイプ分類
- IaaSの（サーバなどのインフラストラクチャ）
- PaaSの（サーバとしてのプラットフォーム）
- SaaSの（サーバとしてのソフトウェア）
のパターン分析： - 雲がなければ、私たちは何をする必要がある一番左の緑の部分（つまり、すべてのもの）であります
- 我々はIaaSのを導入した場合、クラウドプラットフォームの次の部分への茶色のものは、自分自身との契約上の緑色の部分は、（などのネットワーク、ストレージ、などのハードウェアを提供します）
- 私たちが繧、図が示すを導入したとき、私たちは自分自身のソフトウェア展開サービスを使用しています。
- 私たちはSaaSのを導入したとき、私たちは、クラウド・プロバイダーによって開発されたソフトウェアを使用することができ、これらは、より高いパフォーマンス、より大きな支援と最適化で、二次開発のための一般的な、フリーソフトウェアの既存のオープンソースソフトウェアです。SaaSのと同じように、私たちは基本的にのみ、ウェブサイトのコードを提供します。他に何がそれを自分で維持する必要はありません。
その他の画像説明はブログで提供されています： https://blog.csdn.net/weixin_44571270/article/details/89737883
（2）オブジェクトの分類を提供します
- パブリッククラウド
- プライベートクラウド
- ハイブリッドクラウド
3、Kubernetesエントリー
1、Kubernetesをしているのですか？
8つの文字やミドルネームがあるのでKubernetesも、K8Sを知られています。これは、コンテナ管理プラットフォームの自動化です。生まれドッキングウィンドウコンテナを管理するために生まれました。使用Kubernetesは、以下の機能を実現することができます。
- 展開と自動化されたレプリケーションの容器と、
- コンテナのサイズを拡大または縮小して自由に感じます。
- 容器はグループに編成され、そしてコンテナ間の負荷分散を提供します。
- 簡単にアプリケーションコンテナの新しいバージョンをアップグレードしました。
- それはのように置き換えられた場合に弾性の容器を提供することで、コンテナが失敗します。
図2は、Kubernetesプラットフォームコンポーネント
ドッカーがノード上で実行されているとの相互作用の原因である、プロキシ機能を提供する、ドッカーコンテナを実行しているノードにマスター、手先ノード、ミニオンノード：Kubernetesは、2つの主要なノードのタイプが存在するクラスタ。主マスタは、手先の分散多数のノードを管理しています。
- Kubelectマスターは：外部APIインターフェースを担当するマスターノードが相互に作用し、管理クラスタとノードの範囲を提供し、ミニオンは、クラスタの管理を動作させることによって達成されます。
- Apiserver：入口クラスタのユーザ対話及びkubernetes、欠失コアオブジェクトカプセル化を変更して再検索操作、提供安らかスタイルAPIインタフェース、持続性etcdによって達成されたオブジェクトの一貫性を維持します。
- スケジューラ：スケジュールの責任と、そのようなポッドは、予想外に、最も適切なノードを見つけるために、特定のスケジューリングアルゴリズムによって再分配機、スケジューラに必要な終了時のようにクラスタリソースを、管理します。
- コントローラマネージャは：主にコピーの一貫ポッド数を確保するために使用し、複製コントローラーの実際の動作は定義されており、また、ポッドへのサービスのマッピングが常に最新であることを保証します。
- Kubelet：ドッカーは子分のノード上で対話的に実行し、ノードは責任がある、などの開始などとコンテナを停止し、動作状態を監視します。
- プロキシは：ミニオンノードを実行し、定期的にetcdからサービス情報を取得し、情報に応じてiptablesサービスを変更することにより、トラフィックを転送するために、ポッドのプロキシ機能を提供する責任がある（元のバージョンは、より効率的なプログラムにより直接転送提供することです。）ノード、およびあなたがアクセスポッドアップしたい場所にトラフィックを転送。
- Etcd：etcd整合性KVは、分散ストレージ・システム・データベースであり、サービス登録および発見のために使用することができるストレージ構成データベースが格納情報kubernetesに使用される共有、高可用性、強い一貫リポジトリサービス発見としてETCD成分、徐々に開発者にとっての関心事。クラウドコンピューティング時代に、どのように共有に構成情報がすぐにクラスタ内のすべてのマシンを発見されたどのように迅速なサービスやコンピューティングクラスタへの透過的なアクセスを行うために、より重要なのは、どのような高可用性、セキュリティ、導入のしやすさを構築しますそして、迅速な対応サービスクラスタ、生まれetcdは、問題を解決することです。
- フランネル：フランネルカバーネットKubernetesデザイン（オーバーレイ用CoreOSチームである
ネットワーク）ツール、フランネルの目的は、異なるノード上のコンテナがネットワークに属して取得することができるように、IPアドレスの規則を使用することを計画再クラスタ内のすべてのノードのためのものであり、ユニークなIPアドレス、およびコンテナが直接通信を介してIPネットワーク上の異なるノードに属することができますように。
二、ビルドにKubernetesクラウドプラットフォーム
一般的なビジネスは、その後、etcd分散クラスタがあるだろう、高可用性が通常行う、複数のマスター・ノードが存在します。私たちは技術を学ぶときしかし、それはそう複雑になることはありません。最もシンプルなアーキテクチャシステム、少なくとも二、三の物理サーバーを必要としています。
内蔵環境
私はここで2台の物理マシンを使用しています。K8Sマスターノード201、手先、一つETCDを行うことができ、ノード200。マスターノード上の物理サーバーを共有します。
ビルドプロセス
1、インストールプレリュード
#两个服务器都要执行以下命令：
setenforce 0
或者 sed -i '/SELINUX/s/enforcing/disabled/g' /etc/selinux/config
systemctl stop firewalld
#ntp时间同步，master节点和million节点需要时间一致
yum install ntp -y
ntpdate pool.ntp.org
systemctl start ntpd
2、マスターノードのインストール
yum install kubernetes-master etcd -y
3、設定etcd
vim /etc/etcd/etcd.conf
注意：2380ポートは、サーバと、分散クラスタ通信ポートとして知らetcd etcdサーバとの間の通信のためのポートです。
2379ポート、即ちポートポートを介してクライアントにサービスを提供するために、マスターノード手先にサービスを提供するために、HTTP APサービスを提供します。
リモート接続のための2379：ローカルetcd接続、172.16.193.201を実行する27.0.0.1:2379コマンド。
mkdir -pv /data/etcd
chown -R etcd.etcd /data/etcd
図4に示すように、構成K8S
cd /etc/kubernetes/
ll
K8Sは、3つのサービスを生産するために設置されて：
- apiserver：統合コマンド（オペレーション）入り口
- コントローラマネージャ：コンテナが失敗した場合は、コンテナの総数が変わらないことを確認するために、すぐに新しいコンテナを作成します。
- スケジューラ：スケジュールコントローラとコンテナリソースが一杯であることが判明し、それが自動的に他のコンテナに派遣されます。
修正K8Sコンフィグ設定：
スタート3つのサービス：
5、手先ノードのインストール
yum install kubernetes-node docker *rhsm* -y
6、構成K8S
K8S手先ノードをインストールした後、2つのサービスを生成します。
- kubelet：ドッキングウィンドウと相互作用することにより、発注作業を発行しました。これは、将来なりませんドッキングウィンドウの実行、ドッキングウィンドウのPSそうです。あなたは、この再kubelet使用することができます。また、コンテナ内で実行するためのWebインターフェイスを作成することができます。
- プロキシ：SNAT、DNATはここで行うことです。フォワードトラフィックは、特定のプロセスは不明です！
K8S手先の編集設定ファイル：
vim config
2つのサービスを開始します。
図7に示すように、マスタ側ノードビュー手先
再生回数：
削除子分ノード：
追加ノードの手先：
K8S子分ノード上の2つのだけ再起動サービス。
8、インストールフランネル
注：このサービスは、ドッキングウィンドウのコンテナに割り当てられたIPを統一することです。
#这个flannel所有节点都要安装，无论master还是minion。
yum install flannel -y
vim /etc/sysconfig/flanneld
etcdctl mk /atomic.io/network/config '{"network":"172.17.0.0/16"}'
# 这个是key 这个是value
systemctl start flanneld
ホストのインストールフランネルサービス：
ドッカーコンテナ：
第三に、ビルドK8SダッシュボードUIインターフェース
操作を行うための1、マスタノード
（1）は、ダッシュボード-controller.yaml、Dashborad-service.yamlファイルを作成します。
touch Dashboard-controller.yaml
ファイルに書き込まれ、次のコンテンツ：
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: kubernetes-dashboard
namespace: kube-system
labels:
k8s-app: kubernetes-dashboard
kubernetes.io/cluster-service: "true"
spec:
selector:
matchLabels:
k8s-app: kubernetes-dashboard
template:
metadata:
labels:
k8s-app: kubernetes-dashboard
annotations:
scheduler.alpha.kubernetes.io/critical-pod: ''
scheduler.alpha.kubernetes.io/tolerations: '[{"key":"CriticalAddonsOnly", "operator":"Exists"}]'
spec:
containers:
- name: kubernetes-dashboard
image: bestwu/kubernetes-dashboard-amd64:v1.6.3
resources:
limits:
cpu: 100m
memory: 50Mi
requests:
cpu: 100m
memory: 50Mi
ports:
- containerPort: 9090
args:
- --apiserver-host=http://172.16.193.201:8080 #此处需要修改ip
livenessProbe:
httpGet:
path: /
port: 9090
initialDelaySeconds: 30
timeoutSeconds: 30
touch Dashboard-service.yaml
ファイルに書き込まれ、次のコンテンツ：
apiVersion: v1
kind: Service
metadata:
name: kubernetes-dashboard
namespace: kube-system
labels:
k8s-app: kubernetes-dashboard
kubernetes.io/cluster-service: "true"
spec:
selector:
k8s-app: kubernetes-dashboard
ports:
- port: 80
targetPort: 9090
（2）設定ファイルapiserverを変更
注：あなたは、APIは、UIインターフェイスへのアクセスを拒否します、ServiceAccountパラメータを削除しない場合。
#KUBE_ADMISSION_CONTROL="--admission-control=NamespaceLifecycle,NamespaceExists,LimitRanger,SecurityContextDeny,ServiceAccount,ResourceQuota"
KUBE_ADMISSION_CONTROL="--admission-control=NamespaceLifecycle,NamespaceExists,LimitRanger,SecurityContextDeny,ResourceQuota"
この手順を行うための単語を見つけることが最後にしている場合。あなたが修正する必要があり、再起動apiserver、その後、実行します。
kubectl delete -f Dashboard-controller.yaml
kubectl delete -f Dashboard-service.yaml
2、手先ノード演算を行う（このステップは省略することができません）
注：この手順は、次のステップは、自分のイメージをダウンロードすることであろうことはできません。そのあまりの違いにはできませんライン、K8Sバージョンとダッシュボードのバージョンに商号変更理由を理解の下で、私自身が鏡を引くドッキングウィンドウはお勧めしませんので！
ダウンロードポッド・インフラ、kubernetes・ダッシュボードの画像：
docker pull docker.io/tianyebj/pod-infrastructure
docker pull docker.io/mirrorgooglecontainers/kubernetes-dashboard-amd64
#这个改名是因为Dashboard-controller.yaml文件中调用过这个镜像
docker tag docker.io/siriuszg/kubernetes-dashboard-amd64 bestwu/kubernetes-dashboard-amd64:v1.6.3
#这个改名是因为minion节点中的/etc/kubernetes/kubelet文件中调用过它
docker tag docker.io/tianyebj/pod-infrastructure registry.access.redhat.com/rhel7/pod-infrastructure
3、ミラーを作成して実行
kubectl create -f Dashboard-controller.yaml
kubectl create -f Dashboard-service.yaml
iptables -P FORWARD ACCEPT (全部节点都要配置)
エラー：エラー：YAML：行38：
期待キー見つけることができませんでした。この全体の間違いには私に長い、長い時間を引き起こしました。
これらのファイルのソリューションは、スペースが右再生できませんでした持っています。間違ったフォーマット。再コピー以下です。フォーマットの厳しい要件の.jsonファイル形式、ないより多くのスペース、NOが少ないです。
4、アクセスK8S UIインターフェース
成功したビルドのダッシュボードインターフェイスかどうかを確認します。
kubectl get pods -namespace kube-system
これは失敗です：
エラーが発生し、ログを見ることができます：
kubectl logs kubernetes-dashboard-3584070908-vp0gl -n kube-system
これは成功です：
成功！
