接続2：
また、他の人に役立つことを期待して、いくつかの使用の問題を記録しkubesphereを使用した後、経験は、コンテナ管理プラットフォームを滑らかシルキー。
フォーティーン削除異常な血管
舵展開領事を使用する前に、削除領事の背後
[root@master ~]# helm delete consul --purge状態別に表示領事は、ポッドにされていますTerminating
[root@master ~]# kubectl get pods -n common-service
NAME READY STATUS RESTARTS AGE
consul-1 1/2 Terminating 1 24d
redis-master-0 1/1 Running 1 17d
redis-slave-0 1/1 Running 1 8d
redis-slave-1 1/1 Running 1 17dビューステータス
[root@master ~]# kubectl describe pods consul-1 -n common-service
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedSync 3m41s (x4861 over 22h) kubelet, node02 error determining status: rpc error: code = DeadlineExceeded desc = context deadline exceeded廃棄上のアドバイス：
- このバージョンでは、新しいcontainerdを使用してドッキングウィンドウ18にアップグレードし、それはバグの多くのために修正されました。
- 終了条件が発生した場合、あなたが専門家の調査に容器を提供することができ、我々は強制的に削除直接お勧めしませんが、いくつかのビジネス上の問題を引き起こす可能性があります。
17は、BUGのdockerdバージョンを疑いました。kubectl -n cn-staging delete pod apigateway-6dc48bf8b6-clcwk --force --grace-period=0強制的にポッドを削除しますが、docker psそれでもこのコンテナを参照してください
[root@master ~]# kubectl -n common-service delete pod consul-1 --force --grace-period=0
warning: Immediate deletion does not wait for confirmation that the running resource has been terminated. The resource may continue to run on the cluster indefinitely.
pod "consul-1" force deleted
[root@master ~]# kubectl get pods -n common-service
NAME READY STATUS RESTARTS AGE
redis-master-0 1/1 Running 1 17d
redis-slave-0 1/1 Running 1 8d
redis-slave-1 1/1 Running 1 17dnode2で見ます
[root@node02 ~]# docker ps -a |grep consul
b5ea9ace7779 fc6c0a74553d "/entrypoint.sh /run…" 3 weeks ago Up 3 weeks k8s_consul_consul-1_common-service_5eb39c90-8503-4125-a2f0-63f177e36293_1
13192855eb6f mirrorgooglecontainers/pause-amd64:3.1 "/pause" 3 weeks ago Exited (0) 23 hours ago k8s_POD_consul-1_common-service_5eb39c90-8503-4125-a2f0-63f177e36293_0解放するために使用状態のリソースに簡単には、そこにされている場合ファイナライザ、メタデータK8Sのリソースがありfinalizers、その後、リソースは、一般的にプログラムによって作成され、彼らが作成したメタデータリソースにおけるfinalizers手段というそのロゴの1のほか、リソースが削除前リソースをクリーンアップするために作成されたプログラムによって削除されたときに実行する必要が、それはリソースから完成クリーニングを識別するために必要finalizers除去した後、最終的には完全にリソースを削除します。例えば、いくつかのリソースは、ランチャーが作成、書き込みますfinalizersアイデンティティを。
解決策：kubectl editリソース定義は、削除手動で編集finalizersし、リソースを見て、あなたが削除されているでしょう。
フィフティーンK8Sログが異常除外します
V2.0からV2.1の背後にアップグレードした後にログが表示されないkubesphere後
最初のルールは、関連するログ収集ポッドが正常で、流暢ビット+ ElasticSearchする責任があります
[root@master ~]# kubectl get po -n kubesphere-logging-system
NAME READY STATUS RESTARTS AGE
elasticsearch-logging-curator-elasticsearch-curator-158086m9zv5 0/1 Completed 0 2d13h
elasticsearch-logging-curator-elasticsearch-curator-158095fmdlz 0/1 Completed 0 37h
elasticsearch-logging-curator-elasticsearch-curator-158103bwf8f 0/1 Completed 0 13h
elasticsearch-logging-data-0 1/1 Running 1 8d
elasticsearch-logging-data-1 1/1 Running 774 69d
elasticsearch-logging-discovery-0 1/1 Running 478 56d
elasticsearch-logging-kibana-94594c5f-q7sht 1/1 Running 1 22d
fluent-bit-2b9kj 2/2 Running 2 23h
fluent-bit-bf52m 2/2 Running 2 23h
fluent-bit-pkb9f 2/2 Running 2 22h
fluent-bit-twd98 2/2 Running 2 23h
logging-fluentbit-operator-56c6b84b94-4nzzn 1/1 Running 1 23h
logsidecar-injector-5cbf7bd868-cr2kh 1/1 Running 1 11d
logsidecar-injector-5cbf7bd868-mp46g 1/1 Running 1 22dログESを格納する前に知って、kubesphere-ロギングシステムがなり、サービスモードのNodePortのESにマッピングされたインデックスを表示し、のみイエガーことを発見されます
curl elasticsearch-logging-data.kubesphere-logging-system.svc:9200/_cat/indices通常のインデックスを表示した後
流暢ビットログをチェックしてください
[root@master ~]# kubectl -n kubesphere-logging-system logs -f fluent-bit-2b9kj -c fluent-bit
I0207 13:53:25.667667 1 fluentbitdaemon.go:135] Start Fluent-Bit daemon...
Fluent Bit v1.0.5
Copyright (C) Treasure Data
[2020/02/07 13:53:26] [ info] [storage] initializing...
[2020/02/07 13:53:26] [ info] [storage] in-memory
[2020/02/07 13:53:26] [ info] [storage] normal synchronization mode, checksum disabled
[2020/02/07 13:53:26] [ info] [engine] started (pid=15)
[2020/02/07 13:53:26] [ info] [filter_kube] https=1 host=kubernetes.default.svc port=443
[2020/02/07 13:53:26] [ info] [filter_kube] local POD info OK
[2020/02/07 13:53:26] [ info] [filter_kube] testing connectivity with API server...
[2020/02/07 13:53:36] [ warn] net_tcp_fd_connect: getaddrinfo(host='kubernetes.default.svc'): Name or service not known
[2020/02/07 13:53:36] [error] [filter_kube] upstream connection error
[2020/02/07 13:53:36] [ warn] [filter_kube] could not get meta for POD fluent-bit-2b9kjそれはリンクの形であるため、ディスク理由の前にシステムディスクので、ドッキングウィンドウコンテナは、収集ログ例外につながる、データディスクにデータを移行します。
ConfigMapのKS-インストーラへのステップ1.追加containersLogMountedPath。満たされた実際の環境に応じて、特定のパス
[root@master docker]# docker info -f '{{.DockerRootDir}}'
/data/docker
[root@master docker]# ll /var/lib/docker
lrwxrwxrwx. 1 root root 12 Oct 10 19:01 /var/lib/docker -> /data/dockerインストーラ自動的に更新流暢ビット演算子のConfigMapステップ2.待ち、おそらく数分。ConfigMapにcontainersLogMountedPath更新までは（ように将来のアップグレードに影響を与えない、直接ConfigMapを変更しないようにしてください）。
ステップ3.再起動Flunetビット
# 删除 fluent-bit Daemonset
[root@master ~]# kubectl scale -n kubesphere-logging-system deployment logging-fluentbit-operator --replicas=0
deployment.extensions/logging-fluentbit-operator scaled
[root@master ~]# kubectl delete -n kubesphere-logging-system daemonsets fluent-bit
daemonset.extensions "fluent-bit" deleted
# 重启 Fluent-bit Operator Deployment
[root@master ~]# kubectl scale -n kubesphere-logging-system deployment logging-fluentbit-operator --replicas=1
deployment.extensions/logging-fluentbit-operator scaled
# 检查 fluent-bit 是否起来
[root@master ~]# kubectl get po -n kubesphere-logging-system
NAME READY STATUS RESTARTS AGE
elasticsearch-logging-curator-elasticsearch-curator-158086m9zv5 0/1 Completed 0 2d13h
elasticsearch-logging-curator-elasticsearch-curator-158095fmdlz 0/1 Completed 0 37h
elasticsearch-logging-curator-elasticsearch-curator-158103bwf8f 0/1 Completed 0 13h
elasticsearch-logging-data-0 1/1 Running 1 8d
elasticsearch-logging-data-1 1/1 Running 774 69d
elasticsearch-logging-discovery-0 1/1 Running 478 56d
elasticsearch-logging-kibana-94594c5f-q7sht 1/1 Running 1 22d
fluent-bit-5rzpv 0/2 ContainerCreating 0 3s
fluent-bit-nkzdv 0/2 ContainerCreating 0 3s
fluent-bit-pwhw7 0/2 ContainerCreating 0 3s
fluent-bit-w5t8k 0/2 ContainerCreating 0 3s
logging-fluentbit-operator-56c6b84b94-d7vgn 1/1 Running 0 5s
logsidecar-injector-5cbf7bd868-cr2kh 1/1 Running 1 11d
logsidecar-injector-5cbf7bd868-mp46g 1/1 Running 1 22d流暢ビットのすべてのノードが起動すると、ログが復元された見ることができます
参考：https://github.com/kubesphere/kubesphere/issues/1476
参考：https://github.com/kubesphere/kubesphere/issues/680
シックスティーンK8Sストレージ
そこでは、異常動作をポッド格納例外としてイベントを表示、CEPH異常状態を参照してください
[root@master test]# ceph -s
cluster 774df8bf-d591-4824-949c-b53826d1b24a
health HEALTH_WARN
mon.master low disk space
monmap e1: 1 mons at {master=10.234.2.204:6789/0}
election epoch 14, quorum 0 master
osdmap e3064: 3 osds: 3 up, 3 in
flags sortbitwise,require_jewel_osds
pgmap v9076023: 192 pgs, 2 pools, 26341 MB data, 8231 objects
64888 MB used, 127 GB / 190 GB avail
192 active+clean
client io 17245 B/s wr, 0 op/s rd, 4 op/s wr
kubeletデフォルトのGCを持って、手動でドッキングウィンドウでファイルをクリーンアップ
# 查看文件
[root@master overlay2]# docker system df
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 34 12 8.463GB 5.225GB (61%)
Containers 46 21 836.6kB 836.5kB (99%)
Local Volumes 4 0 59.03MB 59.03MB (100%)
Build Cache 0 0 0B
# 清理文件
[root@master overlay2]# docker system prune
WARNING! This will remove:
- all stopped containers
- all networks not used by at least one container
- all dangling images
- all dangling build cache
Are you sure you want to continue? [y/N] y iptablesのを修正するセブンティーンKUBE-プロキシモードはIPVSです
- 各ノード間modeprobe
modprobe -- ip_vs
modprobe -- ip_vs_rr
modprobe -- ip_vs_wrr
modprobe -- ip_vs_sh
modprobe -- nf_conntrack_ipv4
lsmod | grep -e ip_vs -e nf_conntrack_ipv4
yum install -y ipset ipvsadm
kubectl get configmap kube-proxy -n kube-system -oyaml現在、ルールがipvsadmのない見ます
[root@master ~]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn- IPVSモードに変更configmap KUBEプロキシは、マスタノードIPVSであります
のKUBE-プロキシポッドを削除する前に
[root@master ~]# kubectl get pod -n kube-system|grep kube-proxy|awk '{print "kubectl delete po "$1" -n kube-system"}'|sh
pod "kube-proxy-2wnst" deleted
pod "kube-proxy-bfrk9" deleted
pod "kube-proxy-kvslw" deletedipvsadmのビューによって切り替えされています。
十八個のアプリケーションがインストールされ
再び記録の動作ステップの下で、アプリケーションをデバッグする実際の2つのアプリケーションがスペースが追加されたビュービジネスにインストールされるアプリケーションリポジトリkubesphere2.1 Webインターフェイスで利用することができるインストールする端末を使用して記録
- 企業の倉庫スペースのアプリケーションにレポを追加
- アプリケーションテンプレートから特定のプロジェクトでのアプリケーションのインストールオプション
- 必要にレポソースパッケージ検索チャートを選択
十九サービス管理
サービスグリッドカナリアリリース、負荷分散、トラフィック検出制御、電流制限ヒューズ降格のシリーズを実装するための注射特使のistio sidercarモードを使用してサービス管理機能を有効にするKubeSphere非常に独自のアプリケーションによって。現在、独自のマイクロガバナンスアプリケーションのテストサービスは、私は非常に使いやすいと感じ、後者はプロセスを記録する機会を持っています。
：K8Sに自身の研究ノートを仕上げ、為替の上昇の迅速な調査があるかもしれませんhttps://github.com/redhatxl/awesome-kubernetes-notes
そのビットを行うには、コミュニティのために、国内のコンテナ管理プラットフォームKubeSphereをサポートしています。