debian-mirror-gitlab/doc/user/clusters/agent/repository.md

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

211 lines
8.1 KiB
Markdown
Raw Normal View History

2021-02-22 17:27:13 +05:30
---
stage: Configure
group: Configure
2022-05-07 20:08:51 +05:30
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
2021-02-22 17:27:13 +05:30
---
2022-05-07 20:08:51 +05:30
# Working with the agent for Kubernetes **(FREE)**
2021-02-22 17:27:13 +05:30
2022-06-21 17:19:12 +05:30
Use the following tasks when working with the agent for Kubernetes.
2021-02-22 17:27:13 +05:30
2022-05-07 20:08:51 +05:30
## View your agents
2021-02-22 17:27:13 +05:30
2022-05-07 20:08:51 +05:30
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/340882) in GitLab 14.8, the installed `agentk` version is displayed on the **Agent** tab.
2021-02-22 17:27:13 +05:30
2022-05-07 20:08:51 +05:30
Prerequisite:
2021-02-22 17:27:13 +05:30
2022-05-07 20:08:51 +05:30
- You must have at least the Developer role.
2021-12-11 22:18:48 +05:30
2022-05-07 20:08:51 +05:30
To view the list of agents:
2021-02-22 17:27:13 +05:30
2022-05-07 20:08:51 +05:30
1. On the top bar, select **Menu > Projects** and find the project that contains your agent configuration file.
1. On the left sidebar, select **Infrastructure > Kubernetes clusters**.
1. Select **Agent** tab to view clusters connected to GitLab through the agent.
2021-02-22 17:27:13 +05:30
2022-05-07 20:08:51 +05:30
On this page, you can view:
2022-04-04 11:22:00 +05:30
2022-05-07 20:08:51 +05:30
- All the registered agents for the current project.
- The connection status.
- The version of `agentk` installed on your cluster.
- The path to each agent configuration file.
2021-02-22 17:27:13 +05:30
2022-05-07 20:08:51 +05:30
## View an agent's activity information
2021-09-04 01:27:46 +05:30
2022-05-07 20:08:51 +05:30
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/277323) in GitLab 14.6.
2021-09-04 01:27:46 +05:30
2022-05-07 20:08:51 +05:30
The activity logs help you to identify problems and get the information
you need for troubleshooting. You can see events from a week before the
current date. To view an agent's activity:
2021-09-04 01:27:46 +05:30
2022-05-07 20:08:51 +05:30
1. On the top bar, select **Menu > Projects** and find the project that contains your agent configuration file.
1. On the left sidebar, select **Infrastructure > Kubernetes clusters**.
1. Select the agent you want to see activity for.
2021-09-04 01:27:46 +05:30
2022-05-07 20:08:51 +05:30
The activity list includes:
2021-09-04 01:27:46 +05:30
2022-05-07 20:08:51 +05:30
- Agent registration events: When a new token is **created**.
- Connection events: When an agent is successfully **connected** to a cluster.
2021-09-04 01:27:46 +05:30
2022-05-07 20:08:51 +05:30
The connection status is logged when you connect an agent for
the first time or after more than an hour of inactivity.
2021-09-04 01:27:46 +05:30
2022-05-07 20:08:51 +05:30
View and provide feedback about the UI in [this epic](https://gitlab.com/groups/gitlab-org/-/epics/4739).
2021-09-04 01:27:46 +05:30
2022-05-07 20:08:51 +05:30
## Debug the agent
2021-09-04 01:27:46 +05:30
2022-05-07 20:08:51 +05:30
To debug the cluster-side component (`agentk`) of the agent, set the log
level according to the available options:
2021-09-04 01:27:46 +05:30
2022-05-07 20:08:51 +05:30
- `off`
- `warning`
- `error`
- `info`
- `debug`
2021-09-04 01:27:46 +05:30
2022-05-07 20:08:51 +05:30
The log level defaults to `info`. You can change it by using a top-level `observability`
section in the configuration file, for example:
2021-09-04 01:27:46 +05:30
```yaml
2022-05-07 20:08:51 +05:30
observability:
logging:
level: debug
2021-02-22 17:27:13 +05:30
```
2021-06-08 01:23:25 +05:30
2022-05-07 20:08:51 +05:30
## Reset the agent token
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/327152) in GitLab 14.9.
To reset the agent token without downtime:
1. Create a new token:
1. On the top bar, select **Menu > Projects** and find your project.
1. On the left sidebar, select **Infrastructure > Kubernetes clusters**.
1. Select the agent you want to create a token for.
1. On the **Tokens** tab, select **Create token**.
1. Enter token's name and description (optional) and select **Create token**.
1. Securely store the generated token.
1. Use the token to [install the agent in your cluster](install/index.md#install-the-agent-in-the-cluster) and to [update the agent](install/index.md#update-the-agent-version) to another version.
1. Delete the token you're no longer using.
## Remove an agent
You can remove an agent by using the [GitLab UI](#remove-an-agent-through-the-gitlab-ui) or the
[GraphQL API](#remove-an-agent-with-the-gitlab-graphql-api). The agent and any associated tokens
are removed from GitLab, but no changes are made in your Kubernetes cluster. You must
clean up those resources manually.
### Remove an agent through the GitLab UI
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/323055) in GitLab 14.7.
To remove an agent from the UI:
1. On the top bar, select **Menu > Projects** and find the project that contains the agent configuration file.
1. From the left sidebar, select **Infrastructure > Kubernetes clusters**.
1. In the table, in the row for your agent, in the **Options** column, select the vertical ellipsis (**{ellipsis_v}**).
1. Select **Delete agent**.
### Remove an agent with the GitLab GraphQL API
1. Get the `<cluster-agent-token-id>` from a query in the interactive GraphQL explorer.
- For GitLab.com, go to <https://gitlab.com/-/graphql-explorer> to open GraphQL Explorer.
- For self-managed GitLab, go to `https://gitlab.example.com/-/graphql-explorer`, replacing `gitlab.example.com` with your instance's URL.
```graphql
query{
project(fullPath: "<full-path-to-agent-configuration-project>") {
clusterAgent(name: "<agent-name>") {
id
tokens {
edges {
node {
id
}
}
}
}
}
}
2021-12-11 22:18:48 +05:30
```
2021-11-11 11:23:49 +05:30
2022-05-07 20:08:51 +05:30
1. Remove an agent record with GraphQL by deleting the `clusterAgentToken`.
2021-11-11 11:23:49 +05:30
2022-05-07 20:08:51 +05:30
```graphql
mutation deleteAgent {
clusterAgentDelete(input: { id: "<cluster-agent-id>" } ) {
errors
}
}
2022-04-04 11:22:00 +05:30
2022-05-07 20:08:51 +05:30
mutation deleteToken {
clusterAgentTokenDelete(input: { id: "<cluster-agent-token-id>" }) {
errors
}
}
2021-12-11 22:18:48 +05:30
```
2022-05-07 20:08:51 +05:30
1. Verify whether the removal occurred successfully. If the output in the Pod logs includes `unauthenticated`, it means that the agent was successfully removed:
2021-12-11 22:18:48 +05:30
2022-05-07 20:08:51 +05:30
```json
{
"level": "warn",
"time": "2021-04-29T23:44:07.598Z",
"msg": "GetConfiguration.Recv failed",
"error": "rpc error: code = Unauthenticated desc = unauthenticated"
}
```
2021-12-11 22:18:48 +05:30
2022-05-07 20:08:51 +05:30
1. Delete the agent in your cluster:
2021-12-11 22:18:48 +05:30
2022-05-07 20:08:51 +05:30
```shell
kubectl delete -n gitlab-kubernetes-agent -f ./resources.yml
```
2021-12-11 22:18:48 +05:30
## Surface network security alerts from cluster to GitLab **(ULTIMATE)**
2021-06-08 01:23:25 +05:30
2022-04-04 11:22:00 +05:30
> [Deprecated](https://gitlab.com/groups/gitlab-org/-/epics/7476) in GitLab 14.8, and planned for [removal](https://gitlab.com/groups/gitlab-org/-/epics/7477) in GitLab 15.0.
WARNING:
Cilium integration is in its end-of-life process. It's [deprecated](https://gitlab.com/groups/gitlab-org/-/epics/7476)
2022-06-21 17:19:12 +05:30
in GitLab 14.8, and planned for [removal](https://gitlab.com/groups/gitlab-org/-/epics/7477)
2022-04-04 11:22:00 +05:30
in GitLab 15.0.
2022-05-07 20:08:51 +05:30
The agent for Kubernetes also provides an integration with Cilium. This integration provides a simple way to
generate network policy-related alerts and to surface those alerts in GitLab.
Several components work in concert for the agent to generate the alerts:
- A working Kubernetes cluster.
- Cilium integration through either of these options:
- Installation through [cluster management template](../../project/clusters/protect/container_network_security/quick_start_guide.md#use-the-cluster-management-template-to-install-cilium).
- Enablement of [hubble-relay](https://docs.cilium.io/en/v1.8/concepts/overview/#hubble) on an
existing installation.
- One or more network policies through any of these options:
- Use the [Container Network Policy editor](../../application_security/policies/index.md#container-network-policy-editor) to create and manage policies.
- Use an [AutoDevOps](../../application_security/policies/index.md#container-network-policy) configuration.
- Add the required labels and annotations to existing network policies.
- A configuration repository with [Cilium configured in `config.yaml`](repository.md#surface-network-security-alerts-from-cluster-to-gitlab)
The setup process follows the same [agent's installation steps](install/index.md),
with the following differences:
- When you define a configuration repository, you must do so with [Cilium settings](repository.md#surface-network-security-alerts-from-cluster-to-gitlab).
- You do not need to specify the `gitops` configuration section.
2021-06-08 01:23:25 +05:30
To integrate, add a top-level `cilium` section to your `config.yml` file. Currently, the
only configuration option is the Hubble relay address:
```yaml
cilium:
hubble_relay_address: "<hubble-relay-host>:<hubble-relay-port>"
```
2021-09-30 23:02:18 +05:30
If your Cilium integration was performed through [GitLab Managed Apps](../applications.md#install-cilium-using-gitlab-cicd) or the
[cluster management template](../../project/clusters/protect/container_network_security/quick_start_guide.md#use-the-cluster-management-template-to-install-cilium),
you can use `hubble-relay.gitlab-managed-apps.svc.cluster.local:80` as the address:
2021-06-08 01:23:25 +05:30
```yaml
cilium:
hubble_relay_address: "hubble-relay.gitlab-managed-apps.svc.cluster.local:80"
```