У цій темі розглянуто кілька способів взаємодії з кластерами.
Під час першого доступу до Kubernetes API радимо використовувати Kubernetes CLI — kubectl.
Щоб отримати доступ до кластера, потрібно знати його розташування й мати облікові дані для доступу. Зазвичай це налаштовується автоматично, коли ви проходите посібник «Початок роботи», або хтось інший налаштував кластер і надав вам облікові дані та розташування.
Перевірте розташування та облікові дані, про які знає kubectl, за допомогою цієї команди:
kubectl config view
Багато прикладів знайомлять із використанням kubectl, а повну документацію наведено в довіднику kubectl.
kubectl сам знаходить API-сервер і автентифікується на ньому. Якщо ви хочете звертатися до REST API безпосередньо за допомогою http-клієнта, як-от curl або wget, чи браузера, є кілька способів знайти API-сервер і автентифікуватися:
Наведена нижче команда запускає kubectl у режимі, у якому він працює як зворотний проксі. Він сам знаходить API-сервер і автентифікується. Запустіть її так:
kubectl proxy --port=8080
Докладніше дивіться в описі kubectl proxy.
Після цього можна досліджувати API за допомогою curl, wget або браузера, замінивши localhost на [::1] для IPv6, ось так:
curl http://localhost:8080/api/
Вивід подібний до такого:
{
"kind": "APIVersions",
"versions": [
"v1"
],
"serverAddressByClientCIDRs": [
{
"clientCIDR": "0.0.0.0/0",
"serverAddress": "10.0.1.149:443"
}
]
}
Використайте kubectl apply і kubectl describe secret..., щоб створити токен для стандартного ServiceAccount за допомогою grep/cut:
Спочатку створіть Secret, запитавши токен для стандартного ServiceAccount:
kubectl apply -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
name: default-token
annotations:
kubernetes.io/service-account.name: default
type: kubernetes.io/service-account-token
EOF
Далі зачекайте, поки контролер токенів заповнить Secret токеном:
while ! kubectl describe secret default-token | grep -E '^token' >/dev/null; do
echo "waiting for token..." >&2
sleep 1
done
Отримайте й використайте згенерований токен:
APISERVER=$(kubectl config view --minify | grep server | cut -f 2- -d ":" | tr -d " ")
TOKEN=$(kubectl describe secret default-token | grep -E '^token' | cut -f2 -d':' | tr -d " ")
curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
Вивід подібний до такого:
{
"kind": "APIVersions",
"versions": [
"v1"
],
"serverAddressByClientCIDRs": [
{
"clientCIDR": "0.0.0.0/0",
"serverAddress": "10.0.1.149:443"
}
]
}
За допомогою jsonpath:
APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')
TOKEN=$(kubectl get secret default-token -o jsonpath='{.data.token}' | base64 --decode)
curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
Вивід подібний до такого:
{
"kind": "APIVersions",
"versions": [
"v1"
],
"serverAddressByClientCIDRs": [
{
"clientCIDR": "0.0.0.0/0",
"serverAddress": "10.0.1.149:443"
}
]
}
У наведених вище прикладах використано прапорець --insecure. Через це запит вразливий до атак MITM. Коли kubectl звертається до кластера, він використовує збережений кореневий сертифікат і клієнтські сертифікати для доступу до сервера. (Вони встановлені в теці ~/.kube.) Оскільки сертифікати кластера зазвичай самопідписані, щоб http-клієнт використовував кореневий сертифікат, може знадобитися спеціальне налаштування.
У деяких кластерах API-сервер не вимагає автентифікації: він може обслуговувати запити на localhost або бути захищеним фаєрволом. Стандарту для цього немає. У розділі Контроль доступу до API описано, як адміністратор кластера може це налаштувати.
Kubernetes офіційно підтримує клієнтські бібліотеки для Go та Python.
go get k8s.io/client-go@kubernetes-<kubernetes-version-number>, докладні інструкції зі встановлення дивіться в INSTALL.md. Підтримувані версії дивіться на https://github.com/kubernetes/client-go.import "k8s.io/client-go/kubernetes".Клієнт Go може використовувати той самий файл kubeconfig, що й CLI kubectl, щоб знайти API-сервер і автентифікуватися на ньому. Дивіться цей приклад.
Якщо застосунок розгорнуто як Pod у кластері, зверніться до наступного розділу.
Щоб використовувати клієнт Python, виконайте таку команду: pip install kubernetes. Інші варіанти встановлення дивіться на сторінці Python Client Library.
Клієнт Python може використовувати той самий файл kubeconfig, що й CLI kubectl, щоб знайти API-сервер і автентифікуватися на ньому. Дивіться цей приклад.
Для доступу до API з інших мов існують клієнтські бібліотеки. Про те, як вони автентифікуються, дивіться документацію цих бібліотек.
Під час доступу до API з Podʼа пошук API-сервера й автентифікація на ньому дещо відрізняються.
Докладніше дивіться в розділі Доступ до API зсередини Podʼа.
У попередньому розділі описано, як підʼєднатися до API-сервера Kubernetes. Про підʼєднання до інших сервісів, що працюють у кластері Kubernetes, дивіться Доступ до сервісів кластера.
Можливості перенаправлення визнано застарілими й вилучено. Натомість використовуйте проксі (дивіться нижче).
Під час роботи з Kubernetes можна зустріти кілька різних проксі:
Проксі або балансувальник навантаження перед API-сервером (або кількома):
Хмарні балансувальники навантаження для зовнішніх сервісів:
LoadBalancerКористувачам Kubernetes зазвичай не потрібно перейматися нічим, крім перших двох типів. За правильне налаштування решти типів зазвичай відповідає адміністратор кластера.