Ваши предположения могут быть правильными, я имею в виду, что ваша проблема может действительно иметь отношение к тому, как api-сервер запускается в EKS, и когда отсутствует опция - client-ca-file , согласно исходный код apiserver:
Кластер не предоставляет клиентский ca-файл в configmap /% s в% s, поэтому аутентификация клиентского сертификата на api-сервере расширения не будет работать.
blockquote>Мне интересно, не могли бы вы создать клиент-CA самостоятельно и впоследствии обновить ConfigMap с расширением-apiserver-аутентификацией. В конце концов, в EKS у нас есть доступ к CA (способ получить его здесь ), который может послужить нам для подписи клиентских сертификатов, как описано на странице GitHub с примером api-сервера .
В качестве дополнительного комментария:
Я заметил, что на EKS такие компоненты, как kubelet, используют
aws-iam-authenticator
(содержимое/var/lib/kubelet/kubeconfig
на узле кластера):apiVersion: v1 kind: Config users: - name: kubelet user: exec: apiVersion: client.authentication.k8s.io/v1alpha1 args: - token - -i - eks-api-eval command: /usr/bin/aws-iam-authenticator env: null
в противоположность GKE, где client-ca используется как способ аутентификации клиентов:
apiVersion: v1 kind: Config users: - name: kubelet user: client-certificate: /etc/srv/kubernetes/pki/kubelet.crt client-key: /etc/srv/kubernetes/pki/kubelet.key
Cookie JSESSIONID создается/отправляется, когда сессия создается. Сессия создается, когда Ваш код звонит request.getSession()
или request.getSession(true)
впервые. Если Вы просто захотите получить сессию, но не создать ее, если это не существует, используйте request.getSession(false)
то - это возвратит Вас сессия или null
. В этом случае новая сессия не создается, и cookie JSESSIONID не отправляется. (Это также означает, что сессия не обязательно создается по первому запросу ... Вы и Ваш код сознаете ситуацию , когда сессия создается)
, Сессии на контекст:
Объем Сессии SRV.7.3
объекты HttpSession должны быть ограничены по объему в приложении (или контекст сервлета) уровень. Базовый механизм, такой как cookie, используемый для установления сессии, может быть тем же для различных контекстов, но объект, на который ссылаются, включая атрибуты в том объекте, никогда не должен совместно использоваться контекстами контейнером.
Обновление: Каждый вызов к странице JSP неявно создает новую сессию, если еще нет никакой сессии. Это может быть выключено с session='false'
директива страницы, в этом случае переменная сеанса не доступна на странице JSP вообще.
ИСПРАВЛЕНИЕ: голосуйте за ответ tibranГЅ Peter Е - это более корректно и завершено!
А "JSESSIONID" является уникальным идентификатором сеанса HTTP - , посмотрите javadoc здесь . Там, Вы найдете следующее предложение
, информация о Сессии ограничена по объему только к текущему веб-приложению (ServletContext), таким образом, информация, хранившая в одном контексте, не будет непосредственно видима в другом.
Поэтому, когда Вы первый хит сайт, новая сессия создается и связывается с SevletContext. При развертывании нескольких приложений сессия не совместно используется.
можно также делать недействительным текущую сессию и поэтому создать новую. например, при переключении от http до https (после того, как вход в систему), это - очень хорошая идея, для создания новой сессии.
Hope, это отвечает на Ваш вопрос.
Here is some information about one more source of the JSESSIONID
cookie:
I was just debugging some Java code that runs on a tomcat server. I was not calling request.getSession()
explicitly anywhere in my code but I noticed that a JSESSIONID
cookie was still being set.
I finally took a look at the generated Java code corresponding to a JSP in the work directory under Tomcat.
It appears that, whether you like it or not, if you invoke a JSP from a servlet, JSESSIONID
will get created!
Added: I just found that by adding the following JSP directive:
<%@ page session="false" %>
you can disable the setting of JSESSIONID
by a JSP.
Для ссылок, созданных в JSP с пользовательскими тегами, мне пришлось использовать
<%@ page session="false" %>
в JSP
И
request.getSession().invalidate();
в действии Struts